Shopify Web Pixels: What Actually Fires at Checkout, and What Cannot

Checkout extensibility replaced checkout.liquid, and with it went the ability to drop a script into the checkout page and read whatever it wanted. The old pattern was a tracking script that scraped the DOM for the order total, the product list, or a field value, and it worked because the script ran in the same page as the shopper. That page no longer exists as a place to run code.

The replacement has two parts. Web pixels handle analytics, and checkout UI extensions handle anything visual. Both run in sandboxes, and neither can touch the checkout DOM. If your tracking depended on the DOM, it did not migrate. It died, and the migration is a rebuild, not a copy.

Checkout.liquid is gone, and so is the DOM

A web pixel runs isolated from the checkout page. It subscribes to standard events that Shopify publishes, like checkout completed or payment info submitted, and it receives the event data Shopify chooses to send. It cannot read the page, it cannot see the card fields, and it cannot set a cookie on the shopper's browser outside its own sandbox. That isolation is the point: the shopper's payment data never enters the pixel's reach.

This is a real constraint, not a paperwork one. A pixel that used to read the discount code from the page has no way to get it now, unless the event data includes it. Before migrating, list every data point the old script read from the DOM, and check each one against the standard events. The ones with no event equivalent are the ones that need a different approach.

The sandbox is the deal

Purchase events fire reliably, because they are computed server-side and published as standard events. They fire whether the shopper uses the standard flow or an accelerated checkout like Shop Pay, which is the main advantage over the old DOM scraping: the old script never saw express checkouts at all, and the pixel does. That is a genuine improvement, and it is worth saying so.

What does not fire is anything that needed the page. A script that watched a field for changes, read a button label, or scraped a shipping method has no equivalent. If the business needs that data, the sanctioned path is a checkout UI extension, which can read its own inputs and publish its own events, but cannot read the rest of the page either.

What still fires, and what does not

Pixels first, then UI extensions, then measurement. Move the analytics to web pixels and verify the purchase event matches the old numbers for a week before touching anything visual. Then rebuild the visual pieces as UI extensions, one at a time, and measure each one. A migration that changes the tracking and the design in the same release cannot tell you which one broke the numbers.

Keep reading: Checkout UI Extensions: Three Per Target, 64 KB, No Exceptions, Custom-App Functions Need Plus. Public-App Functions Do Not.

The rebuild order

The test that matters is a completed order in a development store, with the pixel subscribed and the event log open. If the purchase event fires with the right total and the right products, the pixel works. If it does not, the problem is the subscription, not the sandbox.

Frequently asked questions

What is a Shopify web pixel?

A sandboxed script that subscribes to standard checkout events. It cannot read the checkout DOM or the shopper's card details.

Can a web pixel read a shopper's card details?

No, by design. Pixels receive event data from Shopify, not page content, and payment data never enters the pixel's reach.

What replaced checkout.liquid for tracking?

Web pixels for analytics and checkout UI extensions for visual changes. Both run in sandboxes with no DOM access.

Do web pixels work on express checkouts?

Yes. Web pixels subscribe to checkout events, which fire whether the shopper uses the standard flow or an accelerated checkout like Shop Pay.