Checkout Extensibility Killed the Old Tracking Snippet. Web Pixels Are the Replacement.

If your checkout tracking still lives in a script pasted into Additional Scripts, it is running on borrowed time. Shopify's move to checkout extensibility ended that pattern, and the replacement, Web Pixels, runs in a sandbox with no direct access to the checkout DOM. The migration is not optional, and the deadline already passed for new scripts.

What changed, and when

The old pattern was simple: paste a tracking snippet into checkout.liquid or the Additional Scripts box, and it ran on the order status page with full access to the page. Checkout extensibility replaced it with checkout UI extensions and Web Pixels, which run in a sandboxed environment. The pixel can observe checkout events, purchases, page views, and custom events, but it cannot touch the DOM directly, and it cannot run arbitrary code in the checkout.

The timeline is specific. Shopify's developer documentation states that script tags with an all or order_status scope could not be created after February 1, 2025, and they stop running on the order status page for all remaining stores on August 26, 2026. Theme app extensions and web pixels are the supported path, and the old script-tag route is closed for new installs and closing for existing ones.

The reason is not only security. The old inline scripts blocked rendering and slowed the checkout, and checkout is where interaction latency costs the most. Moving tracking into the sandboxed pixel is both the supported path and the faster one, because the pixel loads independently of the checkout render. A store that migrates gets its tracking back and a faster checkout in the same change.

What breaks, and what to do about it

Anything that depended on reading the checkout DOM breaks. A script that scraped the order number from the page, or modified the checkout layout, or read a field value directly, has no equivalent in the pixel sandbox. The replacement is the pixel's event API: subscribe to the checkout_completed event, read the order data from the event payload, and send it to your analytics endpoint from the pixel. The data is there. The DOM access is not. Related reading: The Chatbot Told Her Shipping Was Free. It Was Not..

Custom pixels are the escape hatch for tools without a native integration. Shopify lets you create a custom pixel in Settings, paste the tracking code into it, and publish it, and the pixel runs in the sandbox with access to the standard events. App pixels, installed from the app's own integration, are the preferred route where one exists, because the app vendor maintains the event mapping.

Test the migration with a real purchase, not a page load. Create a test order, walk it through checkout, and confirm the purchase event fires in your analytics with the right order value, currency, and line items. A pixel that fires on page view but not on purchase is the most common migration failure, and it only shows up in a full checkout test. More on this: The AI Size Chart Measured a Different Garment.

The part teams forget

Uninstalling the old script is part of the migration. A store that adds Web Pixels and leaves the old Additional Scripts in place double-counts every purchase for as long as both run, and the double count looks like a sudden conversion improvement right up until someone reconciles against real orders. Remove the old script the day the pixel is verified, and reconcile the first week of pixel data against Shopify orders before trusting it.

Frequently asked questions

Can Web Pixels read the checkout DOM?

No. Pixels run in a sandbox by design, with no direct DOM access. They observe checkout events and read data from the event payload instead.

What breaks if I do nothing?

Script tags with all or order_status scope stop running on the order status page on August 26, 2026. Tracking that depends on them simply stops firing.

Do pixels slow the store?

They run in a sandbox independently of the checkout render, so they are faster than the old inline scripts, which blocked rendering while they loaded.

Should I use an app pixel or a custom pixel?

Use the app pixel where the tool offers one, because the vendor maintains the event mapping. Use a custom pixel for tools without a native integration.