TL;DR
Nobody breaks their tracking on a quiet Tuesday. It breaks on launch day: new theme, checkout upgrade, consent banner swap, or the agency's cleanup pass. The failure is almost never inside the ad platforms, and it is rarely inside the tracking app either. It is in the connective tissue between your storefront and those systems, and each connection type fails differently. Script tags die with the theme era that spawned them, app embeds get toggled off silently, web pixels survive theme changes by design, and checkout surfaces follow their own migration calendar. Work the checklist top to bottom and you will find it; most stores find it at step one.
Key Takeaways
- App embeds are per-theme settings. Publishing a new theme, or even a fresh copy of the same theme, resets which embeds are on. Check this screen before anything else.
- Web pixels are the one delivery mechanism a theme change cannot delete, because they run in Shopify's pixel sandbox, not in your theme's code. If your tracking rides a web pixel and order webhooks, a redesign cannot delete the events that count revenue.
- Script-tag era code is on a countdown: as of October 1, 2026 apps can no longer create or update script tags, and Shopify stops injecting them entirely on March 1, 2027 [1]. A broken script tag found today should be replaced, not repaired.
- On non-Plus stores, the legacy Thank-you and Order-status pages upgraded automatically on August 26, 2026, and Additional Scripts on those pages went away with them, irreversibly.
- Consent tooling swaps break tracking legally: a new banner that defaults analytics consent to denied turns off browser events for every visitor who ignores it.
- Reinstalling an app during a redesign can leave two copies of a pixel firing. Duplicate events inflate platform numbers and get purchases flagged as spam by dedup.
- Diagnose before you fix: a free scan tells you which pixels and server-side connections a store actually fires, with a confidence level per finding.
Start with app embeds, because that's usually it
Theme app extensions ship tracking code as an embed block you toggle in the theme editor. The toggle state belongs to the theme, not to the app. Launch a new theme and the app is still installed, still billed, still showing a green dashboard, while its storefront code simply is not in the published theme anymore.
Open Online Store → Themes → Customize → App embeds and read the list against the apps you believe are tracking. Anything that should be on and is not: that was your incident. Toggle it, save, and confirm events resume before touching anything else. If you keep a preview of the old theme around, compare its embed list with the new one; the difference is a complete list of what the switch silently dropped.
Which delivery mechanisms survive a theme change?
The four ways tracking code reaches a Shopify storefront fail in four different ways, and knowing which ones your stack uses turns panic into a lookup table.
| Mechanism | Theme switch | Where to check | Era |
|---|---|---|---|
| Theme-edited snippets (pasted pixels) | Gone. Edits live in the old theme's files | Old theme's theme.liquid
|
Legacy |
| Script tags (app-injected) | Survive the switch, but frozen: no create/update after Oct 1, 2026; dead Mar 1, 2027 [1] | Vendor question, in writing | Deprecated |
| App embed blocks | Survive install, but toggle resets per theme | Customize → App embeds | Current |
| Web pixels | Unaffected. Run in the pixel sandbox, outside the theme | Settings → Customer events | Current |
The bottom row is the design lesson. A web pixel subscribes to storefront events inside Shopify's sandbox, so there is no theme file to lose and no embed to toggle. WeltPixel Conversion Tracking delivers browser events through a web pixel and sends purchases server-side from the order webhook, so the events that count revenue survive a theme switch. Full disclosure about our own app: it also ships a theme app embed that bridges ad-click IDs from browser to server, and that toggle is as per-theme as everyone else's. With it off, events keep flowing but attribution quality drops, so it belongs on your step-one checklist too. The full mechanics are in our plain-English guide to the Web Pixels API.
Checkout changes have their own calendar, separate from themes. Plus stores made these moves in 2024 and 2025; every other store's legacy Thank-you and Order-status pages auto-upgraded on August 26, 2026, taking the Additional Scripts box with them permanently. If your purchase confirmation tracking lived in that box and September's numbers look thin, that is not a mystery, that is the deadline we wrote up in the August 26 thank-you page deadline.
Did the consent setup change with the redesign?
Redesigns bundle a consent banner swap surprisingly often, either because the old banner clashed with the new design or because the agency standardized on their preferred tool. Two failure shapes follow.
The loud one: the new banner defaults analytics and marketing consent to denied and most visitors never touch it. Browser events legally stop for those visitors. Your traffic did not fall; your permission to observe it did. Purchases keep arriving in Shopify while pixel-side events thin out, which reads exactly like breakage unless you check consent rates.
The quiet one: the new banner is not wired to Shopify's Customer Privacy API at all. It shows a banner, records a choice somewhere private, and never tells Shopify. Depending on your store's protection settings, that can leave events either firing for everyone or firing for no one. After the June 2026 GA4 consent change this got easier to misread, and the audit steps in the GA4 June 2026 consent change guide apply to any banner swap, not only that update.
While you are in there, glance at the pixel's own status: since January 2026 Shopify can pause a marketing app pixel's data sharing under the Optimized default, and the pause is visible in admin, not in your ad dashboards.
Did the cleanup create duplicates instead?
The opposite failure appears when apps get reinstalled during a migration or an old pasted pixel comes back with a restored theme section: two sources now fire the same event. Platform dashboards inflate, then dedup kicks in on whatever carries proper event IDs and purchase counts wobble. The symptom is numbers that got better in a way nobody can explain, followed by numbers that got strange.
Check the app pixel activity log under Customer events for what is actually subscribed and firing; Shopify added a per-pixel activity log in June 2026 that records data-access changes with timestamps, which is the closest thing this platform has to a black-box recorder for launch day.
Run the twenty-minute triage
- App embeds screen. Compare against your app list. Fix toggles first.
- Real-time check. Browse your own store with a platform debugger open (GA4 DebugView, Meta Test Events) and watch page view, product view, add to cart fire or not fire.
- Consent pass. Load the store fresh, decline everything, confirm events stop; accept everything, confirm they resume. Both halves matter.
- Purchase path. Place a $1 test order. Server-delivered purchases from the order webhook will arrive even when browser events are consent-thinned, so a missing purchase points at credentials or configuration rather than the storefront.
- Scan it. Our free pixel audit scans a storefront and reports which of the four major platforms (Meta, TikTok, GA4, and Google Ads) have working pixels, which have server-side delivery, whether consent mode is set up correctly, and whether duplicate pixels are firing. Each finding comes with a stated confidence level rather than a verdict pretending to certainty; checkout-domain events are verified by proxy since no external scan can watch a real purchase. It takes under a minute and it turns "something broke" into a named list.
Then fix in order of revenue: purchase events, add to cart, everything else.
FAQ
Why did my conversion tracking stop after publishing a new theme?
Almost always app embeds: the new theme has its own embed toggles and the tracking app's block defaulted to off. Online Store → Themes → Customize → App embeds, re-enable, save. Tracking that runs as a web pixel keeps working through theme changes because it does not live in theme code.
Will my existing tracking break on October 1, 2026?
Existing script tags keep running past that date; October 1 only blocks apps from creating or updating them. The real stop is March 1, 2027, when Shopify stops injecting script tags into storefronts entirely [1]. Use the run-up to move anything script-tag based to a web pixel or app embed.
How do I know if my tracking uses script tags or a web pixel?
Ask each vendor in writing: does your storefront code ship as a script tag, an app embed, or a web pixel? In admin, web pixels appear under Settings → Customer events, and embeds under the theme's App embeds panel. Anything visible in neither, but present in page source, is worth a pointed follow-up.
Can a consent banner change reduce my tracked conversions without anything being broken?
Yes. A banner that defaults to denied, or that visitors now actually see, lawfully suppresses browser events for non-consenting sessions. Purchases delivered server-side from the order webhook keep your revenue counts intact while browser-side funnel data thins out.
If this checklist keeps finding the same fragile pieces every redesign, the durable fix is tracking that ships as a web pixel plus order-webhook delivery, so the next theme launch cannot take the revenue events with it.
Sources
- Shopify Developer Changelog, "Script tags are deprecated and will stop running on March 1, 2027", shopify.dev/changelog/online-store-script-tags-deprecation, published August 24, 2026