Why a Shopify Theme Update Can Break Your Meta Pixel
Theme updates break Meta tracking because much of a store's pixel code lives inside the theme itself. A snippet pasted into theme.liquid, an app embed toggled on in theme settings, or a custom event script inside a section all belong to one specific theme. Publish a new theme, or even a fresh copy of the same theme, and none of that carries over automatically: the snippet is gone, the app embed defaults to off, and the custom script never runs again. The store looks identical, orders keep arriving, and campaigns keep spending, which is why nobody notices. After any theme change, load your storefront with the browser's Network tab open and confirm that fbevents.js loads and that requests to facebook.com/tr fire on a product page. Then check your app embeds are still enabled, and watch your own visit appear in the Events Manager Test Events feed.
Where pixel code actually lives in a Shopify store
There are two very different homes for tracking code. App managed web pixels run in Shopify's sandboxed pixel environment; they are attached to the store, not the theme, and survive theme changes. Everything else is theme scoped: code pasted directly into theme files, app embeds that are enabled per theme in the theme editor, and scripts added through sections or custom liquid blocks.
Stores accumulate both kinds over years, often installed by different people or agencies. The result is that almost nobody can say from memory which parts of their tracking are theme scoped. The theme update reveals it for them.
The three ways a theme change kills tracking
First, the published theme simply lacks the snippet: the old theme had pixel code pasted into its layout file, the new one does not, and nothing warns you.
Second, app embeds reset: an embed enabled in the old theme's settings is off by default when a different theme is published, so the app is still installed and its dashboard still looks healthy while its storefront code no longer loads.
Third, custom event wiring disappears: scripts that fired ViewContent or AddToCart from a section of the old theme were never migrated, so the standard events that campaigns optimize on go quiet while PageView, fired from a surviving app pixel, keeps looking alive.
What to verify after any theme change
Load the storefront with developer tools open and confirm two things on a product page: the fbevents.js script loads, and requests to facebook.com/tr leave the page with event names attached.
In the theme editor, open App embeds and confirm everything that should be on is on. In Events Manager, use Test Events to watch your own visit produce PageView, ViewContent, and AddToCart. Finally, compare event recency under Data Sources the next day: a theme problem shows up as a drop that starts at publish time.
Catch the next one automatically
The check above takes ten minutes, and the failure it catches happens at unpredictable times: a scheduled theme publish, a seasonal design refresh, an agency edit. Standing verification removes the memory burden. PixelSentry visits your storefront every 6 hours like a shopper, verifies the pixel loads and generates tracking requests with the captured requests as evidence, and reads Meta's Dataset Quality metrics so a theme publish that silently drops tracking becomes an alert with proof instead of a quiet month of wasted spend.