Shopify Checkout Extensibility Broke Your Tracking? Here’s the Rebuild Checklist

What died (Additional Scripts / checkout.liquid / thank-you scripts)

Checkout Extensibility changed the contract. The old “drop a snippet on thank-you and pray” model is gone.

Additional Scripts deprecated tracking is not a rumor — on the modern checkout path, that box is retired or effectively useless for purchase. Anything that depended on pasting GA4, Meta, TikTok, or GTM loaders into Additional Scripts stopped when you migrated.

checkout.liquid tracking removed (or never available under Checkout Extensibility) means theme-level checkout injections that used to fire pixels no longer run in the same place. Classic thank-you hardcodes, app embeds that only fire on storefront, and GTM tags scoped to thank-you URLs that no longer match fail silently.

The post-migration signature: mid-funnel looks fine (add_to_cart, begin_checkout) while purchase vanishes.

Leftover theme snippets that never ran on checkout still do not. Inventory every purchase source before you add another pixel — stacking a new app on a dead Additional Scripts path usually creates the next problem: duplicates.

What replaced it (Customer Events / custom pixels / Web Pixels API / checkout_completed)

Shopify’s replacement stack is not “paste harder.” It is:

1. Customer Events — where you add app pixels and custom pixels
2. Custom pixels — JavaScript in Shopify’s sandbox, subscribed to checkout lifecycle events
3. Web Pixels API — analytics.subscribe(...) event model
4. checkout_completed — the event that maps to purchase / conversion for most DTC stacks

If you never subscribed a custom pixel (or a vetted app pixel) to checkout_completed, GA4 and ads look like purchase died — because for the browser path, it did.

Customer Events GA4 setups typically either:

• Rely on Shopify’s Google & YouTube channel / native GA4 connection (configure carefully; watch for dupes with GTM), or
• Load GA4 / GTM from a custom pixel that listens to checkout_completed and sends purchase with a proper payload

Neither is set-and-forget. Both need verification on a real order after migration. Mid-funnel subscriptions (checkout_started, payment_info_submitted, and storefront events where applicable) help funnel fidelity — but the cliff everyone feels is checkout_completed not firing into analytics and ads.

Subscribe checklist (events + payload)

Events to subscribe (minimum)

• checkout_completed — mandatory for purchase / conversion
• Optional: checkout_started, address/contact/payment info events — only if you report those steps
• Storefront events belong in the right pixel context — one custom pixel does not magically cover theme + checkout

Payload on checkout_completed → purchase

Decide once: order id vs order name as transaction_id. Native Google & YouTube often leans order name; custom GTM often uses order id. Mismatched keys make GA4 vs Shopify reconciliations look worse than reality.

One authoritative purchase path per destination — or intentional dedupe if native + GTM both fire. Respect Consent Mode. Do not leave dead Additional Scripts “just in case.”

Sandbox vs GTM Preview lies → DebugView

Custom pixels run in Shopify’s sandbox. They do not share the storefront dataLayer the way classic theme tags did.

That produces a reliable false negative: you open GTM Preview on the shop, walk checkout, and Preview looks empty or incomplete. You conclude GTM is dead. Purchase may still be firing from a sandboxed custom pixel — or may not be — and Preview alone cannot tell you. Fix the verification method, not your mood.

1. Place a real test order
2. Confirm in GA4 DebugView that purchase arrives with transaction id, value, currency
3. Confirm ads pixel / Events Manager test events if Meta (or equivalent) is in scope
4. Only then trust “it works” — homepage Preview proves nothing about checkout

If DebugView is silent after checkout_completed should have run, your subscribe or mapping is wrong — not “GA4 is broken.”

Signal table (symptom → cause)

15-minute post-migration checklist

AUDIT-497: quantify the post-migration gap in 72h

When the rebuild checklist does not explain the silence — or finance will not wait while you guess — buy the diagnostic. AUDIT-497 is read / diagnose only:

• Quantified variance: GA4 purchases vs Shopify orders over a defined post-migration window
• Customer Events / GTM health notes (missing checkout_completed, payload gaps, native + GTM dupes)
• Ads conversion spot-check where you grant access
• Written report + recommended Sprint tier (SPRINT-25 / 35 / SERVER-50)
• $497 fully credits into the first TRACKFIX Sprint booked within 30 days of delivery
• 72h clock starts when collaborator + GA4 + GTM / Customer Events access is confirmed — not at payment alone

Live rebuild of custom pixels, dedupe, and validation against real orders are the Sprint, not the audit. We do not guarantee ROAS, manage ad spend, or sell “free audit → retainer” theater. If you only need variance math after migration, the audit is the wedge; if you need the pixel rebuilt and proven on real orders, that is Sprint scope.

Related reading while you decide: Why GA4 purchases don’t match Shopify — same variance logic once checkout_completed is alive again.

FAQ