For most Shopify stores, the majority of product page traffic now arrives on a phone, yet most themes, mockups and test ideas are still designed on a 27-inch monitor. If your visitors are mostly on mobile, your A/B testing programme should be too. This article covers the mobile-specific tests worth running on your product pages, and the one analysis habit that stops mobile wins being invisible: segmenting your results by device.

Why mobile-first testing, not mobile-also

Open your Shopify analytics and check your device split. For most consumer stores it’s weighted heavily toward mobile sessions, while desktop often converts at a higher rate, larger screens, easier typing, more deliberate sessions. That gap is partly audience (mobile catches more casual browsers) but partly experience: pinch-zooming, mis-taps, buried buttons, and slow loads on cellular connections.

That experience gap is your opportunity. The friction is fixable, the traffic is already there, and every fix compounds across your biggest segment. The tests below are ordered roughly by how often they’re worth running first.

Thumb-zone CTAs: design for where thumbs actually are

Most people hold their phone one-handed and tap with a thumb. The comfortable reach zone is the bottom half of the screen; the hardest-to-reach areas are the top corners. Yet the classic product page puts the add-to-cart button somewhere in the middle of a long scroll, reachable only after the visitor has swiped past a gallery, a title block and a variant picker.

Tests worth running:

  • Sticky add-to-cart bar. A slim bar pinned to the bottom of the viewport with price and an add-to-cart button. This is the canonical thumb-zone fix and, for most stores, the highest-probability mobile test available. The details that make or break it, bar height, variant handling, not covering other UI, are covered in our CTA button testing guide.
  • CTA on the first screen. Test a compressed above-the-fold layout (tighter title block, shorter gallery) so the button is visible without scrolling on a typical phone.
  • Tap target sizes. Variant swatches, quantity steppers and accordion headers all need to be comfortably tappable. If your size swatches are 24-pixel squares, a variant with generous tap targets is a legitimate test.

Gallery swiping: the mobile gallery is the product page

On a phone, the image gallery is often 60–70% of the first screen. How it behaves matters as much as what’s in it.

  • Swipe affordance. Visitors need to know there are more images. Test explicit signals: dots or a “1/7” counter, or a peek layout where the edge of the next image is visible at the side of the screen. A gallery that looks like a single static image is a gallery nobody swipes.
  • Gallery height. A full-bleed square (or taller) image showcases the product but pushes everything else down. Test a slightly shorter gallery that lets the title, price and rating share the first screen.
  • Image order for a swiping audience. Desktop users see thumbnails and choose; mobile users swipe linearly and many stop after two or three images. Your second and third images carry far more weight on mobile, test leading with the scale/context shot or the benefit-explaining image rather than another studio angle. More on this in product image A/B tests.
  • Video in the gallery. Test a short autoplay-muted clip as the second slide. It can be the most persuasive slot on the page, or a load-time liability (see speed, below). Measure both.

Collapsed sections: accordions cut both ways

Accordions (collapsible sections for description, ingredients, shipping, size guides) are how mobile pages stay tidy. They’re also how information dies unread: content behind a closed accordion is only seen by visitors motivated enough to hunt for it.

Tests worth running:

  • First accordion open by default vs all closed. A middle path between a wall of text and a wall of hidden answers.
  • What’s inside vs outside. Test pulling your two or three highest-impact selling points out of the accordion into a short always-visible bullet list, with the accordion holding the long-form detail. Which points make the cut is itself a worthwhile description test.
  • Shipping and returns visibility. Objection-answering content (delivery time, returns) is the worst thing to hide. Test an always-visible one-liner near the CTA versus accordion-only.
  • Section order. Accordions make reordering cheap. Description → reviews → shipping vs reviews-first is a real question for stores where social proof is the main persuader.

Sticky ATC bars: worth its own checklist

The sticky add-to-cart bar deserves special attention because it’s both the most promising mobile test and the easiest to implement badly. Before you launch the variant, check:

  1. Variant selection. If a shopper taps “Add to cart” on the bar without picking a size, the bar should scroll them to the selector or open a picker, never silently add a default.
  2. Height discipline. The bar is renting your scarcest real estate. Price plus button; resist stuffing in a rating, a badge and a countdown timer.
  3. No UI collisions. Check it doesn’t sit over cookie banners, chat widgets or the browser’s own bottom bar.
  4. Appear-on-scroll vs always-visible. Test showing the bar only after the visitor scrolls past the main CTA, versus pinned from load.

Many Shopify themes include a sticky bar as a theme setting, which makes this a clean template test: one template with the setting on, one with it off.

Mobile speed: the test that runs before your page does

Speed belongs in a mobile optimization article because mobile is where slowness lives, mid-range phones on cellular connections, not fibre-connected desktops. A visually gorgeous variant that ships 4MB of gallery images can lose a test purely by being slow.

Practical points:

  • Weigh your variants. When you build an alternate template, check what it adds: more images, video, an extra app widget. If variant B is heavier than A, you’re testing design plus slowdown, not design alone.
  • Compress and size images properly. Shopify serves responsive image sizes if your theme requests them; enormous source images with no srcset sizing are the most common self-inflicted wound.
  • Audit app scripts. Every app embed you’ve ever installed potentially loads JavaScript on your product page. Remove the dead ones.
  • Testing tools themselves affect speed. Any A/B testing tool has to decide what a visitor sees before showing the page, which is why cheap implementations cause flicker (the original page flashing before the variant loads) or slow everything down. We’ve written a full piece on A/B testing, page speed and flicker. For what it’s worth, this is a design constraint we took seriously with Atchoo!: variant assignment uses Shopify’s native template mechanism with a first-party cookie, anti-flicker is scoped only to product pages with an active test, and there’s a hard failsafe so it can never hide the rest of your storefront.

Why you must segment results by device

Here’s the analysis habit that makes or breaks mobile testing: read your results split by mobile and desktop, not blended.

The reason is simple arithmetic. Suppose a sticky-bar variant improves mobile add-to-cart rate meaningfully but does nothing on desktop (where there’s no bar). Blend the two segments and the effect gets diluted toward zero; depending on your traffic mix and desktop noise, the combined result can look like “no clear winner” while a real mobile win sits underneath.

The reverse failure is worse: a variant that helps desktop but hurts mobile can blend to a small overall “win”, and you ship a change that damages your largest segment.

Practical guidance:

  • Decide the segmentation before the test. “We’ll call it based on mobile add-to-cart rate; desktop is a guardrail” is a fine plan. Deciding after peeking at ten different slices is how you fool yourself, that’s classic multiple-comparison territory.
  • Check the sample size per segment, not overall. If mobile is 70% of traffic, your mobile segment reaches a usable sample sooner than desktop. The sample size calculator works per-segment; be honest that the desktop read may stay inconclusive.
  • For mobile-only changes, consider a mobile-focused test. If the change literally cannot affect desktop (a sticky bar hidden at desktop widths), the desktop segment is pure noise dilution in a blended read.

The broader statistics, when a lead is real, how Bayesian analysis expresses it as a probability, are covered in the complete guide to Shopify A/B testing.

A mobile-first testing sequence

If you’re starting from a stock theme and typical traffic, a sensible order:

  1. Sticky add-to-cart bar (on vs off)
  2. First-screen layout compression (CTA visible without scrolling)
  3. Gallery swipe affordance and image order
  4. Key selling points outside the accordion vs inside
  5. Shipping/returns line near the CTA
  6. Gallery video slide
  7. Section reordering

Each is a one-change template test: build the variant as a second product template in your existing theme and split traffic. That’s the workflow in how to A/B test Shopify product pages, and it’s what Atchoo automates, deterministic visitor assignment, real-time add-to-cart tracking, and Bayesian results, with a 14-day free trial on the Pro plan if you want to run your first mobile test this week.

Frequently asked questions

Can I run a test that only changes the mobile layout?

Yes. Most theme sections have mobile-specific settings (or CSS that only applies below a width breakpoint), so an alternate template can differ only at mobile sizes. Desktop visitors then see essentially identical pages in both groups, which is exactly why you should judge the test on the mobile segment.

What’s a good mobile add-to-cart rate?

Ranges vary widely by product type, price point and traffic mix, and mobile typically runs below desktop. Treat your own baseline as the number that matters and aim to beat it; see our add-to-cart benchmarks for honest context.

Do sticky add-to-cart bars always win?

No, they’re a strong hypothesis, not a law. Poorly built ones (covering content, adding wrong variants, hiding the footer) can lose. That’s the point of testing rather than assuming.

Why does my testing app need anti-flicker, and is it safe?

Any client-side swap risks briefly showing version A before version B renders; anti-flicker hides content for a moment to prevent that flash. The safety question is scope: it should apply only to pages under test and fail open. Our page speed and flicker article explains what to look for.