Shopify has quietly shipped everything you need for clean A/B testing infrastructure, it just never labelled it that way. The template suffix system and the ?view= URL parameter let a single theme serve multiple versions of the same product page, natively, with no duplicated code. This article explains how that machinery works, why it’s a better foundation for testing than duplicating your whole theme, and where its limits are.

How Shopify decides what a page looks like

Every page on a Shopify storefront is rendered by a template, a file in your theme that determines which sections appear and in what order. Product pages use a product template, collections use a collection template, and so on.

In Online Store 2.0 themes (Dawn and everything built since), templates are JSON files:

templates/
  product.json
  collection.json
  page.json
  ...

A product.json file is essentially a manifest: it lists section instances (main product info, image gallery, recommendations, a rich-text block…), their order, and their settings. The actual rendering logic lives in the theme’s sections/ directory, written in Liquid. The template says what appears where; the sections say how it looks. (If that distinction is fuzzy, sections vs templates untangles it properly.)

Template suffixes: multiple versions of the same page type

Here’s the underused part: a theme can contain more than one template per page type. You distinguish them with a suffix in the filename:

templates/product.json               → the default product template
templates/product.lifestyle.json     → alternate template, suffix "lifestyle"
templates/product.sticky-atc.json    → alternate template, suffix "sticky-atc"

You create these without touching code: in the theme editor, open a product template, click the template dropdown, and choose Create template. Shopify copies the current template’s JSON to a new suffixed file, and from then on the two are edited independently, change the section order or settings in product.sticky-atc and product.json is untouched.

Shopify built this for merchandising: a different layout for gift cards, a special template for made-to-order items, a landing-style page for a hero product. Normally you’d assign a suffixed template to specific products via the “Theme template” dropdown in Shopify admin, and those products would permanently render with it.

But there’s a second way to invoke an alternate template, and it’s the one that matters for testing.

The ?view= parameter

Shopify natively supports rendering any page with an alternate template by appending the view query parameter to the URL:

/products/waxed-jacket                  → renders templates/product.json
/products/waxed-jacket?view=lifestyle   → renders templates/product.lifestyle.json

The parameter value is simply the template suffix. Same product, same URL path, same theme, a different template for this render. This is documented Shopify behaviour, not an exploit; it’s the same mechanism the theme editor uses internally when previewing alternate templates, and you can try it manually on any store right now.

For A/B testing, the recipe practically writes itself:

  1. Build the variant as a suffixed template (product.variant-b) in your live theme.
  2. A testing app assigns each visitor to A or B, deterministically, via a first-party cookie, so the same visitor always gets the same version.
  3. Visitors in group B are shown the alternate template through the view mechanism; group A sees the default template exactly as before.
  4. The app counts product views and add-to-cart events for each group, and the maths does the rest.

This is precisely how Atchoo! works under the hood, assignment cookie, native view rendering, first-party tracking of views and add-to-carts, Bayesian analysis on top. But the mechanism itself is pure Shopify, which is why it’s worth understanding regardless of which tool you use. For the hands-on version, creating the template, building the variant, QA, follow the step-by-step tutorial.

Why template-level testing beats theme duplication

The main alternative in the Shopify app ecosystem is theme splitting: the app duplicates your entire theme, you edit the copy, and traffic is split between the two published-ish themes. It sounds equivalent. In practice, the differences compound badly over time.

The drift problem

The moment your theme exists in two copies, every subsequent change must be made twice. Your team updates an announcement bar, fixes a typo in the footer, adjusts a collection page, installs an app that injects a snippet, into which theme? In practice, changes land in one copy and not the other, and the two themes drift apart. Now your “A/B test” is no longer measuring your intended change; it’s measuring your change plus an accumulating pile of accidental differences. Three weeks in, nobody can say exactly what’s being compared.

Theme updates make it worse: pull a new version of your theme from its developer and you must re-duplicate and rebuild the variant, or run the test across two different theme versions.

With template-level testing there is one theme. The default and variant templates share every section file, every snippet, every global setting. Edit the theme’s CSS or fix the footer and both arms of the test get it simultaneously, the only difference between A and B remains the difference you built on purpose.

Scope and blast radius

A duplicated theme changes the rendering of your entire storefront for half your visitors, homepage, collections, cart, everything, even when you only meant to test one product page. That enlarges the blast radius of anything going wrong, and it muddies attribution: if the variant theme wins, which of its pages did the work?

A template test is scoped to exactly the products you assign. The rest of the storefront is identical for everyone. The same scoping logic should apply to anti-flicker treatment, it should touch only product pages with an active test and carry a failsafe so a script hiccup can never blank pages that aren’t even being tested. (More on the flicker question in A/B testing, page speed, and flicker.)

Operational sanity

  • App embeds, pixels, and integrations are configured once, in one theme.
  • Your team keeps working in the normal theme editor without a “which copy am I in?” ritual.
  • Rolling out a winner is trivial: assign the winning template to the product (or fold its changes into the default), rather than performing theme surgery.

To be fair to theme splitting: it’s the only client-side way to test genuinely global changes, a new header, sitewide typography, a different navigation structure. If that’s truly your question, it’s the tool for the job, drift risks and all. For product page testing, which is where most stores should start anyway (here’s why), it’s the wrong trade.

Limitations, what template testing can’t do

Honesty section. The template mechanism is elegant, but it has edges:

  • It tests templates, not arbitrary elements. Your variant is a different arrangement/configuration of sections and blocks. That covers layout, imagery, copy, CTAs, trust elements, the levers that matter most on product pages, but if you want to test a change inside a section that has no setting for it, someone has to add that setting or block to the section code first.
  • Page-type scope. The approach shines on product pages (and works for other templated pages), but it can’t test global elements that live outside templates, the header, footer, and navigation are shared by both arms by design.
  • No checkout testing. Checkout doesn’t render from theme templates. This is a Shopify platform boundary, not a tooling gap; checkout customisation requires Shopify Plus and lives in a different system entirely.
  • No price testing. Price is a property of the product, not the template, both arms show the same price. Frankly, that’s a feature: price testing carries risks most stores shouldn’t take on.
  • Online Store 2.0 assumed. Very old vintage themes with Liquid-only templates technically support suffixes too, but the no-code create-and-edit workflow described here assumes a JSON-template theme. If your theme predates OS 2.0, upgrading is worth it for many reasons beyond testing.
  • Shared section code is shared. Because both templates use the same underlying section files, a developer editing a section’s Liquid mid-test changes both arms at once. Fair, but worth knowing, schedule theme development around test windows.

None of these bite for the core use case: testing meaningfully different product page experiences against each other on a live store.

What about SEO and the ?view= URLs?

A sensible worry: does serving some visitors ?view=variant-b create duplicate-content problems or confuse Google? In short, no, search engines are explicitly fine with A/B testing, the canonical URL for the product remains the clean product URL, and visitors are never redirected to a different address for the test (variant rendering happens against the same product URL a shopper sees and shares). The rules you do need to follow, no cloaking, don’t run experiments forever, are covered in does A/B testing affect SEO?

Frequently asked questions

Is the ?view= parameter an official Shopify feature?

Yes. Rendering alternate templates via the view query parameter is longstanding, documented Shopify behaviour, available on every store. Template suffixes themselves are a core theme feature, the theme editor’s Create template flow exists precisely to make them.

Can visitors “escape” the test by removing the parameter?

A visitor who manually edits the URL would see the default template for that page load, but real shoppers don’t edit query strings, and a testing app’s deterministic assignment keeps every navigated-to page consistent for that visitor. In measurement terms this is negligible.

How many alternate templates can I have?

Shopify allows a generous number of templates per page type (far more than any testing programme needs, the platform limit is in the hundreds). The practical constraint is housekeeping: name suffixes descriptively and delete templates from concluded tests.

Does an alternate template slow my store down?

No. A suffixed template renders through exactly the same pipeline as the default, it’s the same theme, same sections, same assets. The performance question with any A/B testing setup is the assignment/anti-flicker script, not the template; see page speed and flicker for what to check.

Do I still need an app, then?

For a permanent alternate page, a special layout for one product, no, just assign the suffixed template in admin. For a test you need the parts Shopify doesn’t provide: random deterministic visitor assignment, consistent variant rendering, event tracking per group, and the statistics to call a winner. That’s the layer an app like Atchoo! adds on top of the native template machinery, with a 14-day free trial if you want to see the mechanism in action on your own store.