How does Shopify Checkout Extensibility break my tracking, and how do I fix it?

What Shopify changed

For years, Shopify stores tracked the checkout with code pasted into it. Plus stores could edit checkout.liquid, and stores on every plan had the “Additional scripts” box for the order status and thank-you page. That’s where most stores pasted their Meta Pixel, GA4 tags, TikTok pixel, Pinterest tag, and any custom purchase tracking. It worked because those scripts ran directly on the checkout and order status pages.

Shopify retired that model. checkout.liquid and the additional scripts field are gone, replaced by Checkout Extensibility. Checkout is now built from Shopify’s own upgraded checkout plus app extensions, and you no longer get to inject raw script tags into it. The order status page and post-purchase page moved with it.

So if your purchase event lived in additional scripts or checkout.liquid, it stopped firing the day your store migrated. The storefront tracking up to the cart still runs. Checkout and purchase are the part that goes dark.

The deadlines have passed

Shopify ran this in stages, and every stage has now passed. On Plus, checkout.liquid no longer works on the information, shipping, and payment steps. On August 28, 2025, Shopify sunset checkout.liquid and Additional scripts on the Plus thank-you and order status pages. On non-Plus stores, script tags on those pages ended on August 26, 2026. If nobody rebuilt the tracking, assume any purchase tracking that lived in those scripts is dead. Check Settings, then Checkout, to see what your store is running now.

Here’s what the upgrade broke and what kept working. Plus stores lost checkout.liquid too, and the fix is the same: Web Pixels plus the server-side setup below.

Broke when the checkout upgraded	Still works
Pixels and tags pasted into Additional scripts	Theme-page events: page views, product views, add to cart
Code in checkout.liquid on Plus	App pixels registered under Customer events
Script-tag apps that injected code into checkout	Server-side purchase events sent from the order
Custom purchase scripts and their dedup logic	The pixels from Shopify’s Google & YouTube and Meta channel apps

The trap is that the storefront still looks healthy. PageView, ViewContent, and AddToCart keep reporting because those fire on theme pages, not checkout. Only the bottom of the funnel breaks. That’s exactly the part you bid on, so a store can run for weeks thinking conversions are flat when really the purchase event quietly went to zero.

Where checkout tracking lives now

The replacement is the Web Pixels API, which Shopify surfaces in the admin as Settings, Customer events. This is a sandboxed JavaScript environment that subscribes to standard events: checkout_started, payment_info_submitted, checkout_completed, and the earlier funnel events like product_viewed and product_added_to_cart.

The sandbox is the important word. A Web Pixel runs in a Web Worker, isolated from the page DOM. It can’t read the page, can’t touch cookies the way an inline script could, and can’t rely on globals you used to set in the theme. You get a structured event payload and a small API for storage. Code written for additional scripts won’t drop into a Web Pixel unchanged. It has to be rewritten against the event schema.

There are two ways to use it:

• App pixels. Meta, GA4 via Google and YouTube channel, TikTok, and Pinterest all ship Shopify apps that register their own Web Pixel automatically. For most stores this is the cleanest path. Connect the channel, confirm the pixel is registered under Customer events, and the platform handles the event mapping.
• Custom pixels. For anything the apps don’t cover, you write a custom pixel in the Customer events screen, subscribe to the events you need, and forward them yourself. One boundary on this: Google documents that running Google tags inside the custom pixel sandbox isn’t a supported implementation, and enhanced conversions are one of the things that may not work correctly from there. Use custom pixels to forward events to your own endpoint or to platforms that support it, and keep Google Ads conversions on the Google & YouTube app or on the page itself. A theme-page conversion doesn’t need the sandbox at all, which is the defect I shipped into my own build.

How it works

Where the purchase event lives now

Before Retired

1. 1 Purchase pixel pasted in Additional scripts or checkout.liquid
2. 2 Stopped running on checkout pages

Now

1. 1 Web Pixels under Customer events Browser-side funnel events
2. 2 Purchase sent server-side Conversions API, Measurement Protocol, deduped by event ID
3. 3 Shopify orders as the ledger

Rebuild the purchase event server-side

Client-side checkout tracking inside the sandbox is more limited than the old inline script, and browser-side events still get blocked by ad blockers, iOS, and ITP. So the reliable fix is to stop depending on the browser for the sale.

One store I work with shows what’s at stake. After its checkout migration, the purchase event broke, and Google Ads recorded far fewer conversions than GA4 did. Once I fixed the event and validated it end to end, the two counts landed within 4% of each other. On a server-side build I run, measured over ten days, the first-party server path delivered about a third of all events and half of purchases that browser tracking prevention would otherwise have dropped.

Send the purchase server-side. For Meta that’s the Conversions API. For GA4 that’s the Measurement Protocol, or a server-side GTM container. The cleanest version routes the order through a server endpoint that fires the purchase with the order ID, value, currency, and hashed customer data, then dedupes against any browser event using a shared event ID.

Shopify’s order webhook, or the checkout_completed event passed to your server, gives you a trustworthy purchase signal that doesn’t depend on the customer’s browser finishing a script. That’s the signal you want feeding your ad platforms, because it reconciles to real orders in Shopify.

A practical setup I keep coming back to:

• Web Pixels (app or custom) for the browser-side funnel events, so platforms still get the in-session signals they use for optimization.
• Conversions API and Measurement Protocol for the purchase, fired from the order, deduped by event ID.
• A single source of truth for revenue, which is Shopify orders, not the pixel.

How to confirm it’s working

Don’t trust the admin toggle. Verify each layer.

1. Check Settings, Customer events, and confirm each platform’s pixel is registered and the custom pixels you expect are present.
2. Place a real test order. Watch Meta Events Manager Test Events and the GA4 DebugView for checkout_completed and purchase firing once, not zero times and not twice.
3. Reconcile a day of Shopify orders against purchases reported in Meta and GA4. If the platform numbers sit far below Shopify, something in the chain is dropping.
4. Confirm deduplication. If browser and server both fire without a matching event ID, you’ll double-count and your ROAS will read better than it is.

Step 3 is the one worth doing properly, because the gap runs in both directions. On the one account in my Ecommerce Tracking Accuracy Benchmark where I could read both the order table and the ad account, the ad platform’s counted purchases over 90 days equaled 58.5% of the store’s entire order book, and its all-conversions purchase total equaled 65.9%, while the store’s own journey data classified none of those orders as paid. That’s one account, N = 1, and it’s enough to show the comparison is worth running on your own store.

Ad platform purchases against the store's order book

One store, 90 days

• The store's whole 90-day order book

Two bars against a dashed line at 100% for the store's whole order book: the bidding metric counted 58.5% and the all-conversions total 65.9%.

Counted in the bidding metric

58.5%

All-conversions purchase total

65.9%

0%25%50%75%100%

If you migrated to Checkout Extensibility and your reported conversions fell off a cliff while Shopify revenue held steady, look at the checkout events first, because they’re the ones the migration moved. The sale still happened. The tracking just lost the page it used to live on. Rebuild it on Web Pixels plus server-side events, then verify against real orders before you trust a single number in the ad dashboards.

When to bring me in

Bring me in when purchases dropped in Google Ads or Meta after the checkout upgrade, when your purchase pixel still lives in Additional scripts, or when Google Ads and GA4 disagree on how many orders came in. I’ll check which checkout events fire and which ones your ad accounts bid on.

I'm Conner Crowe, and I write every audit myself. Send the free audit request and add me as a read-only user, and within 24 hours of access you'll have a written read on which numbers to trust and what to fix first. No call needed, and nothing in your account or store changes.

Request a free Google Ads audit →

See how I fix conversion tracking.