Shopify's Web Pixels sandbox, explained for advertisers

Since the August 26, 2026 auto-upgrade to Checkout Extensibility, the only way to run your own tracking JavaScript on Shopify's checkout and thank-you pages is a Custom Pixel — and Custom Pixels run inside the Web Pixels sandbox. Understanding that sandbox tells you exactly which parts of your Meta setup can live in it and which parts must live somewhere else.

What is the Web Pixels sandbox?

It is an isolated worker environment — sandboxed away from the page — where Shopify runs pixel code with a deliberately restricted API surface. Your code does not run "on" the checkout page; it runs beside it, receiving a curated stream of customer events through the analytics.subscribe API.

Inside the sandbox there is no direct handle on the real page. Shopify decides what your code can see (the event payloads) and what it can touch (a limited browser-like environment). App Pixels (installed by apps) and Custom Pixels (pasted by you in Settings → Customer events) both live here.

What the sandbox CAN do

Quite a lot, within its lane:

• Subscribe to standard customer events — page_viewed, product_viewed, search_submitted, checkout_started, checkout_completed, and more — with structured payloads including order totals and line items
• Fire browser pixels — load Meta's Pixel script and call fbq('track', 'Purchase', ...)
• Fetch external endpoints — fetch() to your own collection endpoint works
• Read and write its own cookies and storage — enough for basic identifiers, within browser privacy limits

A minimal Meta Purchase in a Custom Pixel looks like this:

jsanalytics.subscribe("checkout_completed", (event) => {
  const checkout = event.data.checkout;
  fbq("track", "Purchase", {
    value: checkout.totalPrice.amount,
    currency: checkout.currencyCode,
  }, { eventID: checkout.order.id });
});

What the sandbox CANNOT do

Three limits matter to advertisers. First: no direct Conversions API calls. Server-to-server Graph API requests require your CAPI access token, and a token embedded in pixel code ships to every visitor's browser — anyone can read it and send fake conversions to your pixel. The sandbox is a browser context; it is structurally the wrong place for CAPI, credentials aside, because everything it sends is still subject to the same blockers and tracking prevention that kill the browser Pixel.

Second: no arbitrary DOM access. You cannot query elements on the page, scrape values, attach listeners to buttons, or inject markup. If your old tracking read data out of the thank-you page's HTML, that pattern is gone. You get what the event payload gives you.

Third: no third-party cookie reach. The sandbox runs in a partitioned context, and modern browsers restrict cross-site cookies anyway. Identifiers like _fbp and _fbc may not carry cleanly from the storefront into checkout — which quietly degrades match quality even when events fire.

Why did Shopify build it this way?

Two reasons: privacy and checkout stability. The sandbox lets Shopify enforce consent (the Customer Privacy API can gate pixels until the buyer agrees) and guarantees that no third-party script can read card fields or other sensitive checkout data. And a decade of Additional Scripts proved that arbitrary JavaScript in checkout breaks checkouts — slow tags, race conditions, scripts editing the DOM out from under Shopify's own code. Isolating pixels means a broken tag can no longer take the checkout down with it.

Those are legitimate engineering reasons. The cost was transferred to advertisers: the sandbox is safer for buyers and worse for signal.

What does this mean for your Meta tracking?

Your browser signal survives — with the same losses it always had. A Custom Pixel restores fbq Purchase events for buyers whose browsers allow it. It does nothing for iOS tracking prevention, ad blockers, or filtered networks; a meaningful share of purchases still never produces a browser event.

Your server-side signal must live outside the sandbox. Conversions API calls need a server: your backend, a tagging server, or a managed service receiving Shopify order webhooks. That server holds the access token, hashes customer identifiers, retries failures, and keeps sending regardless of what happens in the buyer's browser.

How the two halves fit together

The sandbox and a server sender are complements, not competitors. The Custom Pixel fires the browser Purchase with an eventID; the server sends the same order to CAPI with the same event_id and hashed email and phone. Meta deduplicates the pair into one conversion, keeps the richer of the two, and your counts stay honest. Skip the shared ID and you double-count — the mechanics are in our deduplication guide, and the broader pattern in the server-side tracking guide.

Caply is the outside-the-sandbox half, run for you: managed servers deliver Purchase and Lead to Meta CAPI with SHA-256-hashed identifiers, automatic retries, and event_id deduplication against whatever fires in the sandbox. Each event gets a Match Forecast score, and Ghost conversions shows Caply-sent versus Ads-Manager-counted by day. Check your store with the Shopify check, or see pricing — plans from $29/month with a 14-day trial.