That's a good thing. It's also why a lot of "just paste this snippet" tracking advice doesn't work anymore, especially at checkout. This post walks through building an app pixel (the kind you ship inside a Shopify app) that subscribes to events, respects consent, and forwards purchases to your own endpoint, plus the gotchas that cost me the most time.

Note: Shopify's Web Pixels API evolves. I've linked to the official docs where behavior matters, and you should check them before shipping. Treat the snippets here as a starting point, not a drop-in implementation.

App pixels vs custom pixels

Shopify has two kinds of pixels:

• Custom pixels are code a merchant pastes into Settings → Customer events. Good for one store.

• App pixels are web pixel extensions shipped as part of an app. Good when you're building something for many stores.

Both run in the same sandboxed environment and use the same event API. App pixels add a shopify.extension.toml configuration, merchant-editable settings, and declared privacy requirements.

Why the sandbox exists

Pixels run isolated from the storefront, in a sandbox (Shopify documents it as a Web Worker for app pixels). The practical consequences:

• No DOM access. You can't query selectors, read document.cookie directly or inject script tags.

• No access to the theme's window or dataLayer. If your old tracking relied on window.dataLayer, it won't be there.

• You subscribe to standard events and receive structured data instead of scraping the page.

• Network calls are allowed (fetch), so you can send data to your own server or a platform's API.

The upside is that one pixel works across the storefront and checkout, because you're not depending on the theme.

Scaffold the extension

From your app directory, using the Shopify CLI:

shopify app generate extension
# choose "Web pixel" when prompted

(Template names have changed in different CLI versions, so pick the web pixel option from the menu rather than relying on a name from a blog post.)

You'll get something like:

extensions/my-pixel/
├── shopify.extension.toml
└── src/
    └── index.js

Configure it: settings and privacy

In shopify.extension.toml you declare the extension's settings (what the merchant can enter) and which kinds of consent your pixel needs.

name = "My tracking pixel"
type = "web_pixel_extension"
runtime_context = "strict"

[customer_privacy]
analytics = true
marketing = true
preferences = false
sale_of_data = "disabled"

[settings]
type = "object"

[settings.fields.endpoint]
name = "Endpoint URL"
description = "Where purchase events are sent"
type = "single_line_text_field"
validations = [{ name = "min", value = "1" }]

Things to check against the current docs, because the schema has changed over time:

• The exact keys in [customer_privacy] and the allowed values. Shopify states its pixel manager only loads your pixel when there is visitor permission for all the settings you declare as required, so declaring marketing = true means the pixel won't load for visitors who declined marketing. That's powerful, but it also means you may lose events you wanted. Declare only what you actually need.

• The runtime_context value (strict vs lax). It changes what the pixel can access.

• How settings are typed and validated.

Subscribe to events

The entry point is register. You get analytics, browser, settings and init:

// src/index.js
import { register } from '@shopify/web-pixels-extension';

register(({ analytics, browser, settings, init, customerPrivacy }) => {
  // 1. Know what consent looks like right now
  let consent = init.customerPrivacy;

  // 2. Keep it updated when the visitor makes a choice
  customerPrivacy.subscribe('visitorConsentCollected', (event) => {
    consent = event.customerPrivacy;
  });

  // 3. Subscribe to the events you care about
  analytics.subscribe('checkout_completed', async (event) => {
    // we'll fill this in below
  });
});

Two details from Shopify's privacy docs worth knowing:

• init.customerPrivacy gives you the initial consent state when the pixel loads.

• visitorConsentCollected is the event to listen to for changes. Consent can change mid-session, so a value read once at startup can be stale.

Common standard events include page_viewed, product_viewed, product_added_to_cart, checkout_started and checkout_completed. Check the current reference for the full list and each event's data shape.

Build the purchase payload

Keep the payload small, explicit and the same shape every time. Don't forward the raw event.

function buildPurchase(event) {
  const c = event.data.checkout;
  const orderId = String(c.order?.id ?? c.token);

  return {
    event_name: 'purchase',
    event_id: `purchase_${orderId}`,     // stable ID for deduplication
    transaction_id: orderId,
    value: Number(c.totalPrice.amount),
    currency: c.currencyCode,
    items: c.lineItems.map((li) => ({
      id: li.variant?.sku || String(li.variant?.id),
      name: li.title,
      price: Number(li.variant?.price?.amount),
      quantity: li.quantity,
    })),
    timestamp: event.timestamp,
  };
}

Why a stable event_id built from the order? If you later add a server-side path (a webhook, for example), both paths can use the same ID, so the destination can deduplicate. A random UUID generated separately on each side is the classic way to double-count sales.

Forward it, with consent checked

Now fill in the subscriber. The key rule: check consent at send time, using the current value.

analytics.subscribe('checkout_completed', async (event) => {
  // Only send if the visitor allowed what this data is used for
  if (!consent?.marketingAllowed && !consent?.analyticsProcessingAllowed) {
    return;
  }

  const payload = buildPurchase(event);

  try {
    await fetch(settings.endpoint, {
      method: 'POST',
      headers: { 'Content-Type': 'application/json' },
      body: JSON.stringify({
        ...payload,
        consent: {
          analytics: !!consent.analyticsProcessingAllowed,
          marketing: !!consent.marketingAllowed,
        },
      }),
      keepalive: true, // lets the request finish if the page is closing
    });
  } catch (err) {
    // Don't throw: a tracking failure should never affect the page
    console.error('pixel send failed', err);
  }
});

Notes:

• keepalive: true matters on a thank-you page. Customers navigate away fast, and without it the request can be cancelled.

• Decide your consent logic deliberately. The check above is deliberately simple. What you may send, and for what purpose, depends on your legal situation and the destination. Mapping Shopify's consent fields to a platform's own consent signals (for example Google's Consent Mode) is a separate step that deserves care.

• Pass the consent state along to your server so downstream systems can honor it too. Moving collection server-side doesn't remove the need to respect the visitor's choice.

• Never throw from a subscriber. Wrap network calls so a failure is contained.

Using cookies and storage

Because you can't read document.cookie, the browser object provides sandbox-safe access:

const fbp = await browser.cookie.get('_fbp');
const sessionKey = await browser.sessionStorage.getItem('my_key');

Check the docs for the exact methods and for what is available in your runtime context. This is also where consent matters: reading advertising cookie IDs and forwarding them is something you should gate behind the right consent.

The gotchas that cost the most time

1. Events fire, but your fetch goes nowhere. Check the Network panel for your endpoint, CORS responses and mixed content. Your server has to accept requests from the sandbox's origin, and a missing CORS header fails silently from the pixel's point of view.

2. The pixel never loads for some visitors. That's often your own [customer_privacy] declaration working as designed. If you require marketing consent and a visitor declined, your pixel doesn't run at all.

3. A stale consent value. Reading init.customerPrivacy once and never updating it means you act on old consent. Subscribe to changes.

4. You test on production and pollute your data. Use a development store, and add a test flag so test orders can be filtered at your endpoint.

5. Two tracking implementations are both live. An app pixel plus a custom pixel plus a leftover theme snippet will send the same purchase three times. Audit Settings → Customer events and installed apps before you ship, and make sure your event_id scheme is consistent.

6. Local dev doesn't behave like checkout. Test end to end on a dev store with a test payment gateway. Don't trust only the storefront events, because checkout is where several implementations differ.

7. Silent breakage after changes. There's no error in the admin when a pixel stops sending. Log on your endpoint, watch for sudden drops in event counts, and consider an automated test that buys a product and checks the request.

Debug checklist

• Open DevTools → Network and filter for your endpoint

• Confirm the payload contains the right value, currency and transaction_id

• Confirm exactly one purchase request per order

• Toggle consent (accept, then decline) and confirm what's sent in each case

• Check your server logs for the same order, and for duplicates

• Compare against the real order in the Shopify admin

When you don't want to maintain this

An app pixel is a good fit if you're building a product, or you need a custom integration. For a single store sending to the usual ad platforms, the maintenance adds up: consent mapping, deduplication, retries, and updates when platforms change their requirements.

If you'd rather not own that, Webgarh GTM Assistant is a Shopify app that handles client-side and server-side tracking through Google Tag Manager, with event deduplication, Consent Mode v2 support and tag diagnostics. It's newer than some alternatives, so test it on a dev store and compare what it sends with your own pixel.

Disclosure: [add your relationship to Webgarh here, e.g. "I work at Webgarh"].

Wrapping up

A Web Pixel extension is a different mental model from pasting a script: events in, structured payloads out, consent respected by design. Keep payloads small, build a stable event ID from the order, check consent at send time, and never let a tracking failure break the page. Then test it like production code, because it is.

Have you built one of these? I'd like to hear which sandbox limitation surprised you most, so drop it in the comments.

By then you've paid for days of ad spend with no learning signal. Tracking is code, and it breaks like code. A theme update, a changed trigger, a new app or a consent banner tweak can all kill a purchase event without a single error in the Shopify admin.

We already test checkout flows and APIs. Tracking deserves the same. This post shows a simple setup: a Playwright test that runs a purchase on a dev store, listens to the network requests, and fails if the purchase event is missing, duplicated or carries wrong data. Then we schedule it.

What we're actually testing

A purchase tracking test should answer four questions:

1. Did the event fire? (at least once)
2. Did it fire exactly once? (no duplicates)
3. Is the payload right? (transaction ID, value, currency)
4. Did it go to every destination we expect? (GA4, Meta, Google Ads)

Notice that we test the network requests, not whether a tag appears in Tag Manager. A tag firing doesn't mean the request left the browser with the right data.

Setup and a major caveat

Use a development store, not production. Check Shopify's current documentation for dev-store behavior, because two things matter:

• Password protection. Dev stores are often password-protected, so your test has to enter the storefront password.
• A test payment method. Use a test or "Bogus" gateway as Shopify documents for dev stores, so no real card is charged.

One honest warning: Shopify's checkout is hardened against automation and changes over time, and bot protection can interfere. Expect to maintain your selectors, and consider testing the pieces separately (see "What you can't easily test" below).

npm init -y
npm i -D @playwright/test
npx playwright install chromium

The test: capture requests during a purchase

The idea is to record every request to your analytics endpoints while the test buys a product, then assert on what was captured.

// tests/purchase-tracking.spec.ts
import { test, expect, Request } from '@playwright/test';

const STORE = process.env.STORE_URL!;          // https://your-dev-store.myshopify.com
const STORE_PASSWORD = process.env.STORE_PASSWORD;

type Hit = { url: string; body: string };

test('purchase is tracked once, with correct data', async ({ page }) => {
  const ga4: Hit[] = [];
  const meta: Hit[] = [];

  page.on('request', (req: Request) => {
    const url = req.url();
    const body = req.postData() ?? '';

    // GA4 collect endpoint (also covers server-container domains if you add them)
    if (url.includes('/g/collect') || url.includes('google-analytics.com/g/collect')) {
      ga4.push({ url, body });
    }
    // Meta Pixel
    if (url.includes('facebook.com/tr')) {
      meta.push({ url, body });
    }
  });

  // 1. Unlock the storefront if password-protected
  await page.goto(STORE);
  if (STORE_PASSWORD && (await page.locator('input[type="password"]').count())) {
    await page.fill('input[type="password"]', STORE_PASSWORD);
    await page.keyboard.press('Enter');
  }

  // 2. Add a known product and go to checkout
  await page.goto(`${STORE}/products/test-product`);
  await page.getByRole('button', { name: /add to cart/i }).click();
  await page.goto(`${STORE}/checkout`);

  // 3. Fill checkout (selectors will differ per store and checkout version)
  await fillCheckoutWithTestData(page);

  // 4. Wait for the confirmation / thank-you state
  await page.waitForURL(/thank[-_]you|orders\//, { timeout: 60_000 });

  // 5. Give async tags a moment to send
  await page.waitForTimeout(5_000);

  // ---- Assertions ----
  const ga4Purchases = ga4.filter(h => /(^|[?&])en=purchase(&|$)/.test(h.url + '&' + h.body));
  expect(ga4Purchases, 'GA4 purchase should fire exactly once').toHaveLength(1);

  const metaPurchases = meta.filter(h => h.url.includes('ev=Purchase'));
  expect(metaPurchases, 'Meta Purchase should fire exactly once').toHaveLength(1);

  // Payload checks
  const ga4Params = new URLSearchParams(ga4Purchases[0].url.split('?')[1]);
  expect(ga4Params.get('cu')).toBe('USD');                 // currency
  expect(Number(ga4Params.get('epn.value') ?? ga4Params.get('ep.value'))).toBeGreaterThan(0);
  expect(ga4Params.get('ep.transaction_id')).toBeTruthy();

  const metaParams = new URL(metaPurchases[0].url).searchParams;
  expect(metaParams.get('cd[currency]')).toBe('USD');
  expect(metaParams.get('eid')).toBeTruthy();              // event ID for dedup
});

A few things worth noting:

• Parameter names vary. GA4's /g/collect uses short names (en, cu, ep.*, epn.*) that you should confirm against what your own requests look like. Open DevTools → Network during a manual purchase and copy what you actually see before writing assertions.
• Meta's pixel can batch or use different endpoints depending on setup, so inspect your own requests first.
• If you use server-side GTM or a custom tracking domain, add that hostname to the request filter, or you'll test the wrong thing.
• waitForTimeout is a blunt tool. Prefer page.waitForRequest(...) for the specific event once you know it, so the test is both faster and less flaky.

Compare against the real order

Network assertions catch missing and duplicate events. To catch wrong values, compare the tracked value with the order Shopify actually created.

// helpers/shopify.ts
export async function getLatestOrder() {
  const res = await fetch(
    `https://${process.env.SHOP}/admin/api/${process.env.API_VERSION}/orders.json?limit=1&order=created_at+desc`,
    { headers: { 'X-Shopify-Access-Token': process.env.ADMIN_TOKEN! } }
  );
  const { orders } = await res.json();
  return orders[0];
}

const order = await getLatestOrder();
expect(Number(ga4Params.get('ep.value') ?? ga4Params.get('epn.value')))
  .toBeCloseTo(Number(order.total_price), 2);
expect(ga4Params.get('ep.transaction_id')).toBe(String(order.id));

Now the test fails if your tracking ever sends 24.90 for a 249.00 order, or uses the order name where your server uses the order ID. Keep the Admin API token in CI secrets, scoped read-only to orders, and use API_VERSION from config because Shopify retires old versions.

Testing the server path

If a webhook sends purchases to a server, test that separately. It's much more stable than browser automation.

// tests/webhook.spec.ts
import crypto from 'node:crypto';
import { test, expect } from '@playwright/test';

test('webhook rejects a bad signature', async ({ request }) => {
  const body = JSON.stringify({ id: 1, total_price: '10.00' });
  const res = await request.post(`${process.env.APP_URL}/webhooks/orders-paid`, {
    headers: { 'X-Shopify-Hmac-Sha256': 'invalid', 'Content-Type': 'application/json' },
    data: body,
  });
  expect(res.status()).toBe(401);
});

test('same webhook twice results in one send (idempotency)', async ({ request }) => {
  const body = JSON.stringify({ id: 999, total_price: '10.00', currency: 'USD', line_items: [] });
  const hmac = crypto.createHmac('sha256', process.env.SHOPIFY_API_SECRET!)
                     .update(body).digest('base64');

  const send = () => request.post(`${process.env.APP_URL}/webhooks/orders-paid`, {
    headers: { 'X-Shopify-Hmac-Sha256': hmac, 'Content-Type': 'application/json' },
    data: body,
  });

  expect((await send()).status()).toBe(200);
  expect((await send()).status()).toBe(200);
  // Then assert your downstream mock received exactly one event for id 999.
});

For the downstream assertion, point your handler at a mock endpoint in test mode (an API_BASE_URL env var is enough) and count what it receives. That tests deduplication without sending fake data to real ad platforms.

Run it on a schedule

A test that only runs when you remember to run it won't catch the Tuesday-night theme change. Run it daily.

# .github/workflows/tracking-check.yml
name: tracking-check
on:
  schedule:
    - cron: '0 6 * * *'     # daily
  workflow_dispatch:
jobs:
  test:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with: { node-version: 20 }
      - run: npm ci
      - run: npx playwright install --with-deps chromium
      - run: npx playwright test
        env:
          STORE_URL: ${{ secrets.STORE_URL }}
          STORE_PASSWORD: ${{ secrets.STORE_PASSWORD }}
          SHOP: ${{ secrets.SHOP }}
          ADMIN_TOKEN: ${{ secrets.ADMIN_TOKEN }}
          API_VERSION: ${{ vars.API_VERSION }}
      - uses: actions/upload-artifact@v4
        if: failure()
        with:
          name: playwright-report
          path: playwright-report/

Add a Slack or email notification on failure, and trigger the workflow after theme publishes if you deploy through CI.

What you can't easily test

Being honest about the limits will save you frustration:

• Real attribution. You can test that the events were sent, not that Google Ads or Meta credited a campaign.
• Production consent behavior. Different regions and banners need separate test cases, and consent-driven differences are hard to simulate fully.
• Modeled conversions. These happen on the platform side.
• Checkout bot protection. If automation gets blocked, test the storefront events and the webhook path separately, and verify checkout manually after changes.

A practical rollout

1. Start with one assertion: purchase fires exactly once.
2. Add the payload checks: transaction ID, value, currency.
3. Add the order comparison to catch wrong values.
4. Test the webhook path with signature and idempotency cases.
5. Schedule it, and make failures noisy.
6. Update it after each checkout or theme change, because selectors and request shapes change.

If you'd rather not build this yourself

A test suite tells you that something broke. Finding out why still takes digging. Tools with built-in diagnostics can shorten that. For example, Webgarh GTM Assistant includes tag diagnostics and event deduplication alongside its client-side and server-side GTM tracking. It's newer than some alternatives, so test it on a dev store against your own checks and compare what it reports with what your Playwright test sees.

Disclosure: [add your relationship to Webgarh here, e.g. "I work at Webgarh"].

Wrapping up

Treat tracking like production code. Test the requests, not the tag. Compare against the real order. Run it daily. Then the next time a theme update silently breaks your purchase event, your CI tells you that morning instead of your ad report telling you next week.

Meanwhile, Shopify shows orders coming in. So the sales are real, and the tracking has quietly stopped.

When tracking breaks, people tend to start by reinstalling things, which often makes it worse. A better way is to match what you're seeing to a symptom, because each symptom points to a different, smaller set of causes. Find yours below.

First, a two-minute triage

Answer these before you touch anything:

1. When did it stop? Pin down a date, even roughly.
2. What changed around that date? A new theme, an app installed or removed, a checkout update, a new payment method, a consent banner, a domain change, someone "cleaning up" Google Tag Manager.
3. Is it everything or just one platform? If Google Ads, GA4 and Meta all dropped on the same day, suspect something on your store. If only Google Ads dropped, suspect the Google connection.

Most tracking problems start with a change somebody made, so the date gives you the biggest clue you'll get.

Symptom 1: Zero conversions, ever

If Google Ads has never recorded a purchase for this store, tracking was probably never connected properly. The usual causes:

• The wrong Google Ads account is connected. Shopify happily sends data to an account you aren't looking at. This happens a lot when an agency or a former employee did the setup. Check which account the Google & YouTube channel is linked to, and compare it to the one running your campaigns.
• The Google account doesn't have enough access. The account used to connect needs administrator access to the Ads account. If it doesn't, the connection can look complete and still not work.
• The conversion action exists but nothing is feeding it. Someone created a "Purchase" conversion in Google Ads by hand, but no tag or integration sends to it. The action sits there at "Unverified" or "No recent conversions" forever.
• A conversion ID or label was pasted wrong. One missing character in a GTM tag means the conversion goes nowhere, and nothing warns you.

What to do: In Google Ads, open the conversion action and read its status and source. Then follow one real test order from Shopify to see where it stops. Don't change anything until you know which of these you have.

Symptom 2: It worked, then suddenly dropped to zero

A sudden drop is almost always caused by one specific change. Check these, roughly in order of how often they cause it:

• A change to your checkout. Shopify has been moving stores onto its newer checkout system, and older methods, such as scripts pasted into the order status or "thank you" page, have been phased out. If your tracking relied on one of those, it can stop working when your store moves over. Check Shopify's current guidance for your plan and dates, because the timeline has differed for Shopify Plus and other stores.
• A theme change or update. If your tracking code was pasted into the theme, a new theme or an update can wipe it out.
• An app was removed or updated. Uninstalling an app doesn't always clean up after itself, and sometimes it takes tracking with it.
• Someone edited or published a Google Tag Manager container. A published change to a trigger or tag can break purchase tracking without any visible error.
• A new consent banner. If the banner now blocks tags until someone clicks "accept," and most visitors ignore it, a large chunk of conversions disappears.
• A new payment method. Some payment methods send the customer off to another site to pay and return them afterward. If some customers don't make it back to your confirmation page, they never trigger the purchase event, even though the order is real.

What to do: Match the drop date against your changes. If you have a theme version history, a GTM version history or an app install log, use them. The change next to the drop is your suspect.

Symptom 3: The tag fires in Tag Manager, but Google Ads shows nothing

This one confuses people most, because the preview says everything is fine.

A tag firing only proves the tag ran. It doesn't prove Google accepted what it sent. Common reasons for the gap:

• GTM isn't running where you think it is. On newer Shopify checkouts, the theme's GTM container doesn't run on checkout pages the way it used to, because checkout is more locked down. A trigger that waits for the "thank you" page URL may never fire in real life, even if it seemed to in a test.
• Consent is blocking the request. The tag fires, but the consent state tells it not to send, or to send in a limited form.
• The tag fires, but for the wrong conversion. It's sending to a different conversion ID or label than the one you're checking.
• A browser extension is blocking the request on your own device. Test in a clean browser profile.

What to do: Open your browser's Network tab during a test order and look for the request to Google. Check that it was sent and that it carried the right values. If you don't see it, the problem is before Google. If you do, it's on Google's side, such as the wrong action or attribution.

Symptom 4: Conversions show up, but the numbers or values are wrong

Here, tracking is working but reporting something false.

• Revenue is off. Wrong value, wrong currency, or a value that includes or excludes tax and shipping differently from how you report revenue elsewhere. If a $249 order shows up as $24.90, that's usually a formatting or parsing problem in the tag.
• Orders are counted twice. Two things are sending the same purchase, such as Shopify's Google channel plus a manual GTM tag. Look at your conversion actions list and check whether more than one counts purchases.
• Add to cart or checkout counts as a "conversion." If those are set as primary, your conversion numbers will look great while your sales stay flat.
• Test orders are being counted. Real events from your own test orders end up in your data. Use a clear test process, and exclude those orders in reporting where you can.

Symptom 5: Conversions are recorded, but ads don't get credit

If Shopify and GA4 show sales but Google Ads attributes few or none to your campaigns, the purchase is being recorded but the connection back to the ad click is lost.

• Auto-tagging is off, so Google can't tie the visit to a click.
• A redirect strips the click identifier before the visitor lands, so the page never sees it.
• The visitor crosses to a different domain during checkout, and the identity doesn't carry across.
• Consent or browser restrictions limit what can be matched.
• The attribution window is shorter than your customers' buying time.

What to do: Check that auto-tagging is on, click your own ad (or a test link with the click ID) and watch whether the identifier survives all the way to the order. If your buyers usually take several days to decide, look at the conversion window setting too.

A simple way to find where it breaks

When you can't tell which symptom you have, trace one real order forward. Place a test order, then ask:

Did the order exist? → Was a purchase event created? → Was it sent? → Did it contain the right data? → Did Google accept it? → Was it credited to a campaign?

The first "no" is where your problem is. Write that step down, and you've turned "tracking is broken" into a specific, fixable question.

Fixes people try that make it worse

• Installing another tracking app on top. If something partly works, this usually creates duplicate purchases.
• Deleting and recreating conversion actions. You lose history, and the new action also needs time to learn.
• Assuming a green status means it works. "Recording conversions" doesn't tell you whether the values are right.
• Changing several things at once. You'll never know which one fixed it, or which one broke something new.

When the basic setup keeps breaking

If you keep fixing tracking only to have it break again after each theme update or checkout change, the setup is too fragile. Pasted scripts and several overlapping apps are the usual reason. At that point, a single managed tracking layer is easier than patching.

The Webgarh GTM Assistant is built for this situation. It handles browser-side and server-side tracking through Google Tag Manager, supports Google Ads, GA4, Meta, TikTok, Pinterest and others, and includes event deduplication, Consent Mode v2 and tracking diagnostics. The diagnostics matter most here, because they show what's being sent from your store instead of leaving you to guess.

If your conversions have stopped and you can't see why, install the Webgarh GTM Assistant from the Shopify App Store, then place one test order and look at where the event stops. That one step often points straight at the cause.

Quick checklist

• I know the date tracking stopped and what changed around it
• The correct Google Ads account is connected, with administrator access
• The conversion action has a real source, not just a name
• I've traced one real test order from Shopify to Google
• Purchase is the main conversion, with correct value and currency
• Only one implementation sends purchases
• Consent settings aren't blocking tags for most visitors
• Auto-tagging is on
• I re-tested after fixing, instead of trusting a status label

If you define a single purchase event properly, with a predictable shape and a stable ID, every destination (GA4, Google Ads, Meta, or anything else) becomes a mapping job rather than a separate integration.

This guide walks through building that event on Shopify using customer events, a custom pixel, the data layer, and Google Tag Manager. It assumes you are comfortable with JavaScript and GTM basics.

The Goal: One Event, Defined Once

Before writing code, decide what a purchase event should look like in your system.

A minimal, GA4-friendly shape looks like this:

{
  "event": "purchase",
  "event_id": "purchase_5678901234",
  "ecommerce": {
    "transaction_id": "5678901234",
    "value": 249.00,
    "currency": "USD",
    "items": [
      {
        "item_id": "SKU-123",
        "item_name": "Example Product",
        "price": 249.00,
        "quantity": 1
      }
    ]
  }
}

Three decisions matter here:

• Stable event ID: Derive it from the order, not from a random value generated per page load. If the same order ever produces the event twice, the ID stays the same.

• Numeric values as numbers: Send 249.00, not "$249.00". Formatting errors at this layer are a common reason revenue looks wrong in reports.

• One shape for every destination: GTM tags read from this structure instead of each platform getting its own custom logic.

Step 1: Understand Where Your Code Can Run

Shopify's checkout is locked down, so you can't drop arbitrary scripts into it the way you could on older setups.

Tracking in checkout is now handled through customer events, where a pixel subscribes to events emitted by the store and runs in a sandbox.

Shopify has been moving stores from older checkout customization methods to this model, so check the current Shopify documentation for what applies to your plan and checkout version before building.

Two practical consequences:

• Your code runs in a sandboxed environment and can't read the storefront's window directly. It receives data through the event object.

• You can load GTM inside the pixel's own sandbox. GTM then works with a dataLayer that lives in that environment.

Step 2: Create a Custom Pixel

In the Shopify admin, go to Settings → Customer events and add a custom pixel.

The pixel subscribes to the checkout_completed event and pushes your standard shape to the data layer.

// Custom pixel: runs in Shopify's sandbox
window.dataLayer = window.dataLayer || [];

analytics.subscribe('checkout_completed', (event) => {
  const checkout = event.data.checkout;
  const orderId = checkout.order && checkout.order.id;

  if (!orderId) return; // Don't send an event without an order

  const items = checkout.lineItems.map((line) => ({
    item_id: line.variant && line.variant.sku
      ? line.variant.sku
      : String(line.variant && line.variant.id),
    item_name: line.title,
    price: Number(
      line.variant &&
      line.variant.price &&
      line.variant.price.amount
    ),
    quantity: line.quantity,
  }));

  window.dataLayer.push({ ecommerce: null });

  window.dataLayer.push({
    event: 'purchase',
    event_id: 'purchase_' + orderId,
    ecommerce: {
      transaction_id: String(orderId),
      value: Number(checkout.totalPrice.amount),
      currency: checkout.currencyCode,
      items: items,
    },
  });
});

A Few Important Notes

Field names such as checkout.order.id, totalPrice.amount, and lineItems should be verified against Shopify's current customer events reference, as the structure can change between versions.

Clearing ecommerce with null before each push prevents old ecommerce values from leaking into the new event.

The early return also prevents the pixel from sending a purchase event when there is no real order behind it.

Load your GTM container snippet at the top of the same pixel so it initializes before the data layer push.

Step 3: Map the Event in GTM

Inside Google Tag Manager, build the mapping once.

1. Create the Trigger

Create a Custom Event trigger with:

purchase

2. Create Data Layer Variables

Create variables for:

ecommerce.transaction_id
ecommerce.value
ecommerce.currency
ecommerce.items
event_id

3. Configure the GA4 Tag

Create a GA4 Event tag with:

Event Name: purchase

Use the ecommerce data from the data layer for the relevant parameters.

4. Map Other Destinations

Google Ads, Meta, and other destinations can read the same variables.

Each platform becomes a mapping exercise rather than another custom tracking implementation.

That is the main advantage of defining the event properly at the source.

If the value format needs to change or a bug needs to be fixed, you fix it in the pixel. The downstream tags don't need to be rebuilt.

Step 4: Use the Event ID for Deduplication

If you later add server-side tracking, the browser event and server event need to share an identifier so the destination can treat them as the same action.

Because the event ID in this example comes from the order:

purchase_<orderId>

a server process — for example, one triggered by an order webhook — can generate the exact same ID from the same order.

You can then pass that value in the event ID field supported by the destination, such as event_id for Meta's Conversions API.

The rule is simple:

Derive the ID from something both sides already know.

That is much more reliable than generating a random ID independently in the browser and server.

Step 5: Test the Whole Path

Don't stop at confirming that the tag fired.

Test the entire tracking path.

1. Place a Test Order

Place a test order and note the actual order ID and order total.

2. Inspect the Data Layer

Confirm that:

• transaction_id matches the order

• value matches the order total

• currency is correct

• value is a number rather than a formatted string

• items contains the expected products

3. Check GTM Preview

Open GTM Preview and confirm that the purchase trigger fires once.

If it fires twice, investigate before moving forward.

4. Check the Network Request

Open the browser's Network tab and confirm that the request to the destination contains the expected parameters.

5. Check the Destination

Use the relevant debugging tools, such as:

• GA4 DebugView

• Meta Events Manager → Test Events

• Google Ads conversion diagnostics where applicable

Confirm that the event is actually being received and processed.

6. Reload the Confirmation Page

Refresh the confirmation page and verify that it does not create another purchase event.

This last test catches a surprising number of duplicate-event problems.

Common Mistakes to Avoid

Generating a Random Event ID on Every Load

A new ID on every page load defeats the purpose of deduplication.

If the same order is sent twice with two different IDs, the destination may treat them as two separate purchases.

Sending Formatted Strings as Values

Avoid:

value: "$249.00"

Use:

value: 249.00

Currency symbols and thousands separators should not be part of numeric tracking values.

Rebuilding the Event for Every Platform

Creating a completely different purchase payload for GA4, Google Ads, Meta, and other platforms is how tracking implementations gradually drift apart.

Define the event once and map it downstream.

Skipping the ecommerce: null Reset

Without clearing the previous ecommerce object, stale values can remain in the data layer and potentially contaminate subsequent events.

Assuming the Sandbox Behaves Like the Storefront

It doesn't.

Shopify's customer events environment has its own restrictions and execution model. Test the implementation inside that environment instead of assuming storefront JavaScript behavior will carry over.

Where a Ready-Made Setup Fits

If you would rather not maintain this tracking layer yourself, it helps to know what a good implementation should do.

Look for:

• One consistent event definition

• Stable event IDs

• Validated payloads

• Consistent ecommerce parameters

• Browser/server deduplication

• Support for multiple advertising and analytics destinations

Webgarh GTM Assistant handles Shopify tracking across GTM, GA4, Google Ads, and Meta, with the goal of removing much of this manual setup.

You can also find it on the Shopify App Store.

Even if you decide to build your own implementation, these are useful criteria for evaluating any Shopify tracking solution.

Wrapping Up

A reliable purchase event comes down to a few decisions made early:

One shape. Numeric values. An ID tied to the order. A test routine that checks the actual data, not just whether a tag fired.

Get those right once in the pixel, and every platform downstream becomes much easier to manage.

Once the event is stable, it also pays to monitor it over time.