How to Set Up Your First A/B Test on Shopify Using GTM, Without Third-Party Tools Meta

Running your first A/B test on Shopify doesn't require a paid testing platform. With Google Tag Manager already on your store and GA4 collecting ecommerce events, you have enough infrastructure to build, deliver, and measure a basic experiment on any non-checkout page; product pages, collection pages, homepage sections without adding a third-party tool.

This guide walks through the full setup. But before getting into the steps, two things need to be said upfront that most tutorials skip over.

First: Shopify's Checkout Extensibility update in August 2024 removed support for JavaScript injection on checkout pages for non-Plus merchants. GTM does not load on Shopify's checkout. Any test that involves the checkout flow, cart page behaviour on some themes, or the order confirmation page requires either Shopify Plus or a dedicated app. GTM-based A/B testing is limited to your storefront pages, product pages, collection pages, and your homepage.

Second: A brief note on timing. Shopify launched Rollouts in January 2026 as a native server-side A/B testing feature available on all plan tiers at no additional cost. If your test is a visual or layout change to a theme section, Rollouts is simpler to implement and avoids the flicker problem described below. GTM remains the right approach when you need granular element control, custom event tracking per variant, or logic that Rollouts doesn't yet support (device targeting, multi-condition variant assignment, custom parameter injection into GA4 events).

With those caveats in place, here's the GTM setup.

What You Need Before Starting

  • GTM container installed and firing on all storefront pages (confirm in Preview mode)

  • GA4 property with working ecommerce events; at minimum, purchase firing correctly with transaction_id and value parameters

  • A single, specific hypothesis: one element, one change, one measurable outcome

If you're not confident your GA4 purchase event is firing correctly, validate it before building any test. A/B test results measured against a misconfigured conversion event are not reliable, this is covered in more detail in our GA4 ecommerce tracking audit guide. An unreliable baseline will produce false winners regardless of how well the test itself is set up.

Step 1: Define Your Hypothesis Precisely

Before touching GTM, write your hypothesis in this structure:

If we [change X on page Y], we expect [metric Z] to increase, because [reason based on observed data].

Example: If we change the add-to-cart button copy on the product page from "Add to Cart" to "Get Yours Now", we expect the add-to-cart rate to increase, because GA4 Funnel Exploration shows a 58% drop-off at this step for mobile users and heatmaps show high engagement at the CTA without clicking.

Specificity matters here for two reasons. First, it prevents scope creep, the temptation to change multiple elements once you're in the implementation. One change per test is not a convention; it's what makes results attributable. Second, it defines your success metric upfront, which must be decided before the test runs, not after you see which direction the data moved.

Step 2: Create the Variant Assignment Variable in GTM

The core of a GTM-based A/B test is a Custom JavaScript variable that assigns users to control or variant at random, then persists that assignment in a cookie so the same user always sees the same version across sessions.

In GTM:

  1. Go to Variables → User-Defined Variables → New

  2. Variable type: Custom JavaScript

  3. Name it clearly: e.g. AB Test - Product Page CTA

Paste the following:

javascript

function() {
  var cookieName = 'ab_product_cta_v1';

  // Check for existing assignment
  var cookies = document.cookie.split(';');
  for (var i = 0; i < cookies.length; i++) {
    var c = cookies[i].trim();
    if (c.indexOf(cookieName + '=') === 0) {
      return c.substring(cookieName.length + 1);
    }
  }

  // Assign variant randomly (50/50 split)
  var variant = Math.random() < 0.5 ? 'control' : 'variant_b';

  // Persist in cookie for 30 days
  var expiry = new Date();
  expiry.setDate(expiry.getDate() + 30);
  document.cookie = cookieName + '=' + variant
    + '; expires=' + expiry.toUTCString()
    + '; path=/; SameSite=Lax';

  return variant;
}
function() {
  var cookieName = 'ab_product_cta_v1';

  // Check for existing assignment
  var cookies = document.cookie.split(';');
  for (var i = 0; i < cookies.length; i++) {
    var c = cookies[i].trim();
    if (c.indexOf(cookieName + '=') === 0) {
      return c.substring(cookieName.length + 1);
    }
  }

  // Assign variant randomly (50/50 split)
  var variant = Math.random() < 0.5 ? 'control' : 'variant_b';

  // Persist in cookie for 30 days
  var expiry = new Date();
  expiry.setDate(expiry.getDate() + 30);
  document.cookie = cookieName + '=' + variant
    + '; expires=' + expiry.toUTCString()
    + '; path=/; SameSite=Lax';

  return variant;
}

A few technical notes on this implementation:

  • Cookie-based persistence is essential. Without it, the same user gets randomly re-assigned on every page load — they'll see inconsistent experiences, and your conversion data will be noise.

  • The cookie name should include a version suffix (e.g. _v1). When you end this test and run a new one later, increment to _v2 so returning users aren't assigned by a stale cookie.

  • SameSite=Lax is required on modern browsers. Without it, some browsers will block the cookie in cross-site contexts.

  • 30-day expiry matches a typical test window. Adjust if your purchase cycle is shorter.

Step 3: Create Triggers for Each Variant

Create two triggers that fire based on the variable value:

Trigger 1 : Variant B fires:

  • Trigger type: Page View

  • Fires on: Some Page Views

  • Condition: {{AB Test — Product Page CTA}} equals variant_b

  • Page condition: URL contains your product page path (e.g. /products/)

Trigger 2 : All users (for tracking assignment):

  • Trigger type: Page View

  • Fires on: All product pages

  • This triggers your GA4 variant assignment event for both control and variant B users

Step 4: Build the Variant Modification Tag

Create a Custom HTML tag that applies the variant change when Trigger 1 fires.

html

<script>
(function() {
  function applyVariant() {
    // Target the specific element — update the selector to match your theme
    var ctaBtn = document.querySelector('[name="add"]');
    if (ctaBtn) {
      ctaBtn.value = 'Get Yours Now';
      ctaBtn.style.backgroundColor = '#E85D26';
    }
  }

  // Apply after DOM is ready
  if (document.readyState === 'loading') {
    document.addEventListener('DOMContentLoaded', applyVariant);
  } else {
    applyVariant();
  }
})();
</script>
<script>
(function() {
  function applyVariant() {
    // Target the specific element — update the selector to match your theme
    var ctaBtn = document.querySelector('[name="add"]');
    if (ctaBtn) {
      ctaBtn.value = 'Get Yours Now';
      ctaBtn.style.backgroundColor = '#E85D26';
    }
  }

  // Apply after DOM is ready
  if (document.readyState === 'loading') {
    document.addEventListener('DOMContentLoaded', applyVariant);
  } else {
    applyVariant();
  }
})();
</script>

Important: The CSS selector you use here depends on your specific Shopify theme. Inspect your product page in DevTools to find the exact selector for the element you're testing. Common themes use different class names and input types for the add-to-cart button, there is no universal selector that works across all themes.

Tag settings:

  • Tag type: Custom HTML

  • Firing trigger: Trigger 1 (Variant B, product page)

  • Tag sequencing: Fire this tag before your GA4 Configuration tag if possible, to reduce the time window for flicker

Step 5: The Flicker Problem, Know It Exists

Client-side DOM modification via GTM fires asynchronously, meaning the browser renders the original page first, then GTM fires and changes the element. Users may briefly see the control version before the variant appears. This is called flicker (or flash of original content).

There is no clean solution to flicker in a pure GTM implementation. Common mitigations include hiding the specific element with CSS before GTM fires and revealing it after the variant is applied, but these add implementation complexity and can cause layout shifts that affect your Core Web Vitals scores.

If flicker is unacceptable for your test (for example, if the element being tested is in the visible viewport on load), Shopify Rollouts is the more appropriate tool, it runs server-side, so the variant renders immediately without any flash.

For testing elements below the fold, in modals, or in interactions triggered by user actions (clicks, scroll depth), flicker is typically not a meaningful issue in practice.

Step 6: Send Variant Assignment to GA4

You need GA4 to know which variant each converting user was assigned to. Do this by pushing a custom event to the dataLayer on page load, tagged with the variant value, for all users (control and variant B).

Create a Custom HTML tag:

html


<script>
window.dataLayer = window.dataLayer || [];
window.dataLayer.push({
  'event': 'ab_test_assignment',
  'test_name': 'product_page_cta_v1',
  'test_variant': '{{AB Test — Product Page CTA}}'
});
</script>
<script>
window.dataLayer = window.dataLayer || [];
window.dataLayer.push({
  'event': 'ab_test_assignment',
  'test_name': 'product_page_cta_v1',
  'test_variant': '{{AB Test — Product Page CTA}}'
});
</script>

Firing trigger: Page View on product pages (all users, not just variant B).

Then create a GA4 Event tag in GTM:

  • Event name: ab_test_assignment

  • Event parameter: test_variant → {{DLV - test_variant}}

  • Event parameter: test_name → {{DLV - test_name}}

  • Trigger: Custom event fires when ab_test_assignment is pushed

In GA4, go to Admin → Custom definitions → Custom dimensions and register test_variant as a custom dimension scoped to Event. Without registering it here, the parameter is collected but won't appear in Exploration reports or be available for segment building.

Step 7: Measure Results in GA4

Once the test is live and data is collecting, build a comparison in GA4 Explore:

  1. Go to Explore → Blank exploration

  2. Drag in Dimension: test_variant

  3. Drag in Metrics: Conversions (purchase), Event count (for add_to_cart)

  4. Filter rows by test_name equals product_page_cta_v1

This gives you a conversion count split by control vs. variant B. To get conversion rates, divide purchase events by total users in each variant (use a segment or add the Users metric alongside conversions).

One critical note on significance: GA4 does not calculate statistical significance natively in standard or Exploration reports. You need to calculate it externally. Take your conversion count and user count per variant and run them through a significance calculator, AB Testguide's calculator is free and straightforward to use. Do not call a winner before reaching 95% confidence. Do not end the test early just because one variant is ahead.

For a clear-eyed view of how long it takes to reach valid results and why clean tracking affects that timeline, see our post on CRO testing timelines and GA4 data quality.

QA Checklist Before Going Live

Run through this before publishing your GTM container:

  • Open GTM Preview mode and navigate to a product page — confirm the variant assignment variable returns either control or variant_b, not undefined

  • Clear cookies and reload, confirm the same variant is assigned consistently within a session

  • Open a second browser tab to the same page, confirm the same variant appears (same cookie, same assignment)

  • Confirm the ab_test_assignment event fires in GA4 DebugView with the correct test_variant value

  • Confirm variant B shows the modified element, test in both Chrome and Safari, on desktop and mobile

  • Confirm the purchase event still fires correctly and is not affected by the variant tag

  • Verify revenue in GA4 matches Shopify for a test transaction after the variant tag is live

The last point is non-trivial. Variant tags that target DOM elements can sometimes inadvertently affect other scripts on the page. Confirm your ecommerce tracking is intact after the variant tag fires.

What This Setup Doesn't Give You

To be complete about the limitations of this approach:

  • No checkout testing, Shopify's checkout is off-limits to GTM for non-Plus merchants since August 2024

  • No statistical significance calculation, GA4 doesn't compute it; you calculate externally

  • Potential flicker, client-side DOM manipulation always carries this risk

  • No visual editor, every test requires manual selector targeting and code

  • No built-in test management, you'll need your own documentation to track which tests are running, start dates, and results

For basic storefront element tests on product pages, this setup is functional and free. For anything involving the checkout, pricing, or high-velocity multivariate testing, a dedicated platform or Shopify Rollouts is the more appropriate choice.

Before You Test, Confirm Your Tracking Is Clean

The most common reason GTM-based A/B tests produce results that don't hold after deployment is not the test setup, it's the tracking underneath it. If your GA4 purchase event has duplicate fires, missing parameters, or attribution gaps, you'll measure variants against a distorted baseline and draw conclusions you can't act on reliably.

Run a GA4 ecommerce tracking audit before your first test, and your test results will be worth the effort it takes to run them.

Need help validating your GA4 and GTM setup before running A/B tests? Talk to FunnelFreaks, we audit ecommerce tracking implementations for D2C brands on Shopify before the testing work begins.

How to Set Up GA4 Funnel Exploration for a D2C Brand Running Multiple Ad Channels ›