Strategy Meets Technology: 4 Prime Targets for Conversion Rate Optimization

Conversion rate optimization (CRO) is an exciting yet daunting field. There are lots of opportunities, but knowing where to start, what to test, and how to optimize can be tough. Rocket Code’s CEO and Senior Engineer discuss four components of an ecommerce website that should be scrutinized in order to maximize return on investment in a CRO program.

At Rocket Code, we live and breathe ecommerce. We create web and mobile experiences for our clients to help them sell more products to more customers every day. Often, this means we help our clients separate signal from noise, so they can focus on investing in their ecommerce properties in ways that improve the customer experience (creating more sales), increase customer loyalty (creating higher lifetime value), or improve operational efficiency.

This is the first in a three-part Q&A series, in which we’ll take a look at three high-value services Rocket Code offers to ecommerce brands. We’ll interview experts from our business and technology stacks to bring you the best insight from both worlds.

In this post, Rocket Code’s content specialist Ray Sylvester talks to CEO Jonathan Poma and senior engineer Andrew Mauney about the four components of an ecommerce website that should be scrutinized to maximize return on investment in a conversion rate optimization (CRO) program.

You might also like: How A/B Testing Will Make You a Better Web Designer.

Where should you start with CRO?

Ray Sylvester: CRO is an exciting but daunting field. We all know there are lots of opportunities with CRO, but making decisions about testing and optimization can be tough. Where should brands start?

Jonathan Poma: It’s easy to put the cart before the horse. And quite honestly, we’ve made that mistake before. Where you start, very simply, is where ecommerce brands win or lose; that’s why speed is vital. And it's important for two reasons: first, speed is the most overlooked aspect of user experience — everyone thinks UX means interfaces and interactions. But all that is for naught if it’s not fast. Second, this allows us to find some quick wins, allows our engineering team to autopsy the work that’s been done before we engage, and gives us time to roadmap.

Andrew Mauney: Jonathan is right on the money about speed, and sometimes speed gains can come from unlikely places. “I want hero images that take up 80 per cent of the screen” may look great, but it can murder your site’s speed. When saving your images, just make sure you use the “Save for Web” (or equivalent) option within your photo editor; then, if you have time, run it through tools like ImageOptim and ImageAlpha. We’ve taken product pages from eight-second load times to two-second load times, just from optimizing images. Making sure the images are “web optimized” – it sounds like something from the ‘90s, but it’s still a huge issue today.

Most of what eats at a site’s speed is small and hard to tell with a cursory glance. There may be frameworks or tools under the hood that were abandoned ages ago, but are still being loaded on the page, or that are used but implemented poorly.

These speed vampires bring to mind buying a used sports car; it could look snazzy on the lot, but if you peek under the hood and see a turbocharger bolted-in but not actually linked to the engine, and the gear shifts are rough when you push it a little, you can start to anticipate where problems are going to arise.

Without seeing all of these things, it can be difficult to create a cohesive roadmap of what to tackle and when. Luckily, the problems are easy to spot once you know what kinds of things to look for.

Where we’re going, there are roadmaps

Ray Sylvester: Very cool. And responsible. You guys both mentioned a “roadmap,” though. Can you talk a bit about what that means?

Jonathan Poma: Absolutely. A roadmap should be used to document, prioritize, and act on opportunities. And when it comes to prioritization, we try to evaluate every opportunity on two criteria: effort and impact. The effort here, obviously, is a combination of the development and operational effort — what’s it going to take to make this happen? The impact is the potential business impact. And the impact is largely analytics driven. It’s where we look and ask, “How many potential customers will see this change?” and “What sort of difference can we make?” The lovely thing about ecommerce is that we can quantify that difference as return on investment (ROI) and evaluate whether or not we think the impact is worth the effort.

Andrew Mauney: From a developer’s standpoint, the roadmap is the broad brushstrokes of what we’d be working on and touching. After peeking under the hood a few times, it becomes clear what will and won’t make for quick wins. We’ve been burned in the past when a developer wasn’t able to see what was going on behind the scenes; they estimated some work and then dove in to find a complete Frankenstein of a page that required far more cleanup and refactoring than we anticipated.

Because of situations like these, other optimization opportunities get shifted around and sometimes abandoned, since the ROI seems far too low or the timing is off. Had we been able to estimate and size these changes more accurately, we would have seen that other cleanup and optimization tasks should have been prioritized ahead of the now troublesome work. “Clean up, optimize, clean up, optimize” is kind of our “rinse and repeat” for the first few sprints, but it makes our lives much easier and our path ahead clearer.

What parts of your ecommerce store should you test?

Ray Sylvester: That makes a lot of sense. But now that the autopsy has been performed, speed has been optimized, and the roadmap built, what should you test?

Andrew Mauney: I think there are four main areas that ecommerce sites struggle with, whether they’re a tiny store selling 10 t-shirts a day, or a huge store selling millions. They are:

• Product pages
• Add-to-cart interactions
• Navigation
• Homepages

If I’m being frank, the last two are obvious problems on the web. Also, while product pages apply more to ecommerce sites, the value-proposition pages on a marketing-focused site can be viewed in the exact same way.

Jonathan Poma: I totally agree. All of the items Andrew mentioned are core elements of a visitor’s purchasing journey. And I’ll also state the obvious; the deeper down the funnel you go, the closer you get to revenue. Often, this means that you’ll want to test the checkout. However, as it pertains to Shopify, they have more data and better data, against which they’re optimizing, than we could ever have. That, and there’s not a whole lot that we can do there…Shopify’s checkout is (or at least has been) largely off limits.

With that said, we’ll tackle the four things Andrew mentioned one by one.

Number one is the product page. This is where you’re asking people to make the first real commitment of adding a product to their cart. Three things are critical here:

• The first is trust. People want to trust the site. Testimonials and reviews are great trust signals. Instagram photos, Facebook likes, etc., are great social proof.
• The second is communication. Make sure that visitors know they can reach the brand if they have problems or questions.
• The third is payment assurance. Shopify is beta testing Extended Validation certificates with its Plus customers. This is a great infrastructural addition to any ecommerce site. Beyond that, accepting multiple payment methods and having third-party certifications (Version, Google Trusted Store, etc.) can help build trust. Testing what to display and how to display it can be immensely impactful.

On that note, learn about how to build a customizable related products section for your clients.

Andrew Mauney: Issues with content (having too much or too little), product photos and the interactions with those photos, and social proof are usually the biggest hindrances to a focused, high-converting product page. These items are not necessarily difficult to engineer but difficult to transform into a tight, high-performing experience.

Jonathan Poma: Yes, exactly. 

Number two is add-to-cart interactions. We’ve seen AJAX side carts add immense value with many of our clients. However, these are all clients whose average order value is significantly higher than the price of one of their products. When that happens, our working hypothesis proves true; keeping the customer in the context of the shopping experience makes it easier for them to spend more money.

But sometimes that doesn’t come into play. For example, we have a client who sells arcade machine cabinets for thousands of dollars. It’s very, very rare that a customer wants to buy more than one. So, we take customers on that site directly to a dedicated shopping cart page with (as you might have guessed) a bunch of trust signals about delivery, warranty, and so forth.

Andrew Mauney: Drilling down to the product page for your add-to-cart interaction can also net you some sweet gains. How users select variants (size, color, quantity, etc.) is a huge blocker on some sites. It’s easy to quickly get lost when the page has two dropdowns, size tiles, and a number fields for the quantity. Simplifying the interaction, or even creating a better user flow, like one that reveals options only when needed, can keep the clicks flowing to that Add to Cart button.

And speaking of the cart, while it isn’t strictly part of the product page, it can be a huge part of your add-to-cart interaction. We’ve done tests that run the gamut of cart types: traditional cart pages, dropdowns, side carts, live carts for wholesale pages, and on and on. At the end of the day, you have to look at what kind of experience your users expect when viewing their cart, and how quickly they can get to checkout.

We’ve found that a large percentage of our clients’ users lean toward using some type of side cart, compared to a more traditional cart page or drop-down. Testing multiple cart types can get hairy very quickly, so this is where that cycle of cleanup and optimization really helps. Assuming you’ve been able to clean things up and make them as lean as possible, you could do something like this:

$('form#product-add-to-cart').on('submit', function(){
// do whatever internet magic you need to add items to your cart // ...
// Then run your tests:
if (TESTS.sidecart){
openSideCart();
}else{
// do your old cart interaction
}
});

Now, this is very agnostic of store and user-interaction specifics (for instance, this could be related to a click on a website or a tap on a mobile web app), but you get the idea. If you were to implement something like this before cleaning up your site, your code would be far messier than the above, as you might have to try to override pre-existing functions.

Using a tool like Optimizely can help, by ensuring your tests are executing the way you’d expect, as well as letting you visualize your results. (Full disclosure: Rocket Code is a 1-Star Optimizely Partner). We usually like to build-in our experiment’s code alongside the original/native code. This way  the pages load more or less the same amount of data, but with the visuals and functionality toggled on and off, via CSS classes specific to the test, and any JavaScript variables we may establish for testing (like the TESTS.sidecart you see above). At the end of the day, you want to keep your tests as clean as your original code (if not cleaner) and reuse as much as you can.

Jonathan Poma: Number three is navigation. Navigation is critical. And to be blunt, many websites don’t do it well,on desktop or on mobile. There are some basics/best practices here, like ensuring that you have hover states and active states, and that you optimize interactions for click/hover (desktop) and touch (mobile) — but that’s only optimizing the interaction. Building an intuitive, user-friendly navigation takes both expertise and hard work. In a word, it’s an esoteric task — and too often, it’s a task undertaken by ill-equipped people.

Andrew Mauney: And that is only really establishing a baseline to test against. Navigation, I feel, is truly a twofold problem: one of information architecture (IA) and one of engineering, and a failure in one will cascade quickly into the other. It’s easy to over-engineer a navigation that ends up hurting your IA by not exposing enough information. On the flip side, it’s equally easy to stuff way too many links and information into a navigation that makes it a terror to engineer.

Too much interaction will push a user away, but too little won’t pull them in. Too much information will overload a user, and they won’t find what they’re looking for on the first try, but too little information will just make them even more lost. Once you get the balance just right, that’s when you can start experimenting with adding small conversion points into your navigation without upending all of your users.

And this is all looking through the lens of quantitative testing, rather than qualitative testing. Quantitative testing lets you look at why users interact the way they do, while qualitative testing is about how they interact, in many cases. But talking about qualitative testing could lead us down a deep rabbit hole, so I’ll just say that in very high-touch sections of the page, you have to use both qualitative and quantitative means to get an optimal output.

Jonathan Poma: Number four is the homepage. Please notice that the homepage is the last item on this list. It’s all the way at the top of the funnel, and thus, the furthest from ultimate revenue. That said, we see time and time again that products featured on the homepage, are strongly correlated with products purchased most often. It’s not a stretch to say that this relationship is causal. A homepage is analogous to the front display in a retail store — it’s where brands put their best products and the products they really want to move. We’ve found, perhaps even more on the homepage than anywhere else (though it does hold true almost anywhere in the shopping experience), that simplicity wins, and more choices don’t always mean better.

Andrew Mauney: And again, simplicity can get you those speed gains, which means less time to reach a page with conversion elements, which isn’t always only the product page.

How should you test?

Ray Sylvester: Okay, great. We’ve got the what down. Now, what about the how?

Andrew Mauney: I think one of the biggest things people miss while testing is goal setting. Goals can be viewed as either proximal (short term), or distal (long term). Your distal goals will probably be something to the effect of “increase conversions on the store by X percent, year-over-year” or “lift add-to-carts by X percent, month-over-month.”

These are very important to have, but are hard to achieve with only a few tests. You have to rely on proximal goals to hit your distal goals; improving add-to-carts little-by-little will quickly compound your distal goal, while giving you the flexibility to try many different iterations to achieve the best outcome in a shorter amount of time. The compounding interest of smaller changes keeps you nimble, while growing your bottom line.

For an ecommerce site, your proximal goals are usually closely coupled to your interface. Your product page add-to-cart button needs to see an increase in clicks, or your quick-view modals need to drive incremental conversions. You are more or less testing your individual interactions and interface items for their effectiveness, rather than looking at the larger picture to see only a minor lift. This gives you the power to iterate over more features quickly, since you know the aggregate lift is going to get you closer to your distal goal, and in some cases, will do so more quickly than you realize.

Jonathan Poma: The only way I can think of adding to what Andrew said is to talk about what not to do. In ecommerce, it’s all about revenue. And for this reason, it’s easy to fall into a trap where revenue is paramount, and nothing else matters. The problem with that thinking is that if you’re changing things upstream in the user flow, there are variables outside of your control that can dilute how you track the effectiveness of the improvements you’re trying to make.

(I’ll grant you, I still consider revenue in every experiment. I’ll never throw it out the window, but sometimes it just can’t be the only thing you hope to see through to significance, or you’ll end up waiting forever.)

It’s important to remember that we’re trying to achieve significance — honestly, and as quickly as possible. So, if you’re testing a new hover interaction on a collection page, you should absolutely monitor revenue. But you shouldn’t expect to see it reach significance. Instead, maybe look for significance on product detail page-views. Or on adds-to-cart from collection pages. Or on collection pages viewed-per-visit. See where I’m going with this?

The bottom line is set up lots of goals but make sure the goals you set are important.

Andrew Mauney: Which goals to monitor can be a hotly contested topic, since most people want to track revenue, but revenue lift isn’t always conclusive high in the funnel.

If you’re worried about revenue at the top of the funnel, you’d better be sure you have a solid funnel, and not a sieve with leaks further down. Monitoring goals (or as they’re now called in Google Analytics 4, events) is dead simple in Optimizely and Google Analytics (GA). The most difficult part of tracking a goal is choosing the type of goal, whether it’s revenue, clicks, conversions, views, or something else. Once you’ve nailed that down, Optimizely and GA have very similar flows for setting up the goals, and require you to add a code snippet similar to the one below:

$('.add-to-cart').on('click', function(){
// Whatever actions you might need for adding to your cart
// ...
// Track the event you have tied to a goal in Optimizely
window.optimizely.push(["trackEvent", "addedToCart"]);
// Track your event in GA
ga('send', 'event', "Store", "addedToCart");
});

All you’re doing here is letting Optimizely and Google know that during that click event, someone should also have triggered your event in the respective platforms. Once you’ve tackled several experiments, you may start seeing that you’ve been tracking certain goals over multiple experiments; these are what you want to start using in your toolbox for secondary and monitoring goals. We strongly tend toward monitoring goals to make sure our KPI isn’t skewed by something we don’t have control over in the funnel.

For example, tracking that someone has reached checkout is extremely valuable if you have an experiment that’s doing well in all categories but revenue. It could be a lower-converting time of month or year for your business, or your items might have a wide price range that’s affecting final purchase and payment behaviors. At the end of the day, you just need to work with small, iterative changes and track things consistently to make sure you’re giving your customers the best store experience possible, without rocking the boat too much.

How do you work with CRO? Tell us in the comments section below.

You might also like: 5 Simple Hacks for an Optimized Mobile Ecommerce Design