Why did my tracking stop working after a Shopify migration or theme change?

Because tracking depends on code and settings that a migration or theme update can change or drop: tags and customer-events pixels not carried over, changed checkout or domains, consent settings reset, and different product IDs breaking catalog and conversion matching. Any of these can silently stop GA4, Meta or Ads from recording events.

How do I fix analytics that broke after moving to Shopify?

Audit systematically against a pre/post checklist: confirm each tag and pixel is present and firing, that customer events and the purchase event work through checkout, that consent is configured, that domains and cross-domain setup are correct, and that product IDs still match your feeds and conversion setup. A test order reveals most of it.

Does a theme update break Shopify tracking?

It can. If tracking was added directly in theme code, a theme update can remove it; and pixels installed via app embeds or the theme may not carry to a new theme. Using Shopify's customer events (web pixels) and app-based tags is more update-safe than hard-coding tags into the theme.

Shopify Tracking Broke After a Theme Update or Migration: What to Audit

Tracking stopped working after a Shopify theme update or migration? A pre/post checklist — tags, customer events, checkout, consent, domains, product IDs and feeds — to find and fix the regression.

If your tracking broke after a Shopify migration or theme update, the cause is almost always mechanical: the migration or theme change dropped, reset, or shifted something your tracking depends on. A tag that lived in the old theme’s code is gone. Customer events didn’t carry over. The checkout or domain changed. Consent got reset to a default that blocks analytics. Or your product IDs changed and no longer match your feeds and conversion setup. Analytics doesn’t “just break” — one of those links snapped. The fix is to audit each one against a pre/post checklist, confirm what fired before versus after the change, and repair the specific link that’s now missing.

Diagnosis: what changed, and why tracking depends on it

Shopify tracking is a chain of parts that all have to survive a migration:

Tags and pixels — GA4, Meta, Google Ads, TikTok. If any were pasted into theme code, switching or updating the theme can wipe them. If they were installed via an app embed, they may not carry to a new theme.
Customer events (web pixels) — Shopify’s sandboxed pixels that fire on browsing and checkout, including checkout_completed. These live at the store level, but a channel app reinstall or a checkout migration can leave them misconfigured.
Checkout — a move to a different checkout, or a checkout-domain change, can break where and whether the purchase event fires.
Consent — a new theme, a new consent app, or a re-installed banner can reset consent state so analytics is blocked until opt-in (or blocked entirely).
Domains — a domain change or a store/checkout split breaks cross-domain measurement and attribution.
Product IDs — a migration can re-issue product and variant IDs. Your catalog feed, Meta catalog, and Ads conversions still reference the old ones, so matching silently fails.

Any one of these can stop events from recording without a visible error on the storefront. That’s why tracking can look “fine” while your data quietly goes flat.

Why it matters

When tracking breaks after a migration, you go blind at the worst possible moment. A migration is exactly when you need clean data — to confirm the new store converts, that campaigns still perform, that nothing regressed. Instead, GA4 shows a purchase cliff, Ads stops crediting conversions, and Meta’s optimizer loses its signal and starts spending badly. You risk pausing a profitable campaign, or scaling a bad one, on numbers that aren’t real. Broken analytics isn’t a reporting inconvenience — it’s mis-spent budget and blind decisions during the one window you can least afford them. (The same root cause is often behind traffic that dropped after a Shopify migration and GA4 missing Shopify purchases: the change happened, and a signal never came back.)

The pre/post checklist

Audit every item before you change anything (baseline) and after the migration or theme update (current state). The break is wherever a “yes” became a “no”.

Area	Pre-change (baseline)	Post-change (verify now)
Tags present	GA4, Meta, Ads, TikTok all installed	Each tag still present on the new theme/store
Tags firing	Each fired on page + product views	Each fires now (Tag Assistant / Pixel Helper / DebugView)
Customer events	Web pixel(s) firing browse + checkout	Same pixels active and configured after the change
Purchase event	`checkout_completed` fired with value + items	Test order fires `purchase` end to end
Consent	Banner + consent mode configured	Consent not reset to block analytics by default
Domains	Store + checkout domain, cross-domain set	Domain unchanged, or cross-domain re-configured
Product IDs	Feed/catalog/conversions matched IDs	IDs still match feeds and conversion setup
GA4	Realtime + DebugView saw events	Verified with a live test order
Meta	Events Manager showed events + match	Test event shows in Events Manager
Google Ads	Conversions recorded from checkout	Conversion tag fires on the test purchase

How to run the audit

You don’t need to guess — you can watch each link directly:

Place one real test order. This is the single most revealing step. Complete a full checkout on the live store and watch what fires. Most regressions surface in one order.
Use the vendor debug tools. GA4 Realtime and DebugView, Meta Events Manager (Test Events) and the Pixel Helper, Google Tag Assistant. Confirm each platform receives the browse events and the purchase/checkout event.
Inspect Shopify Customer Events. In admin, open Settings → Customer events and confirm the pixels you expect are present and active, and that channel apps (Google, Meta, TikTok) are still connected.
Compare against Shopify orders. Shopify admin is the source of truth for orders. If a test order lands in Shopify but not in GA4/Meta/Ads, the event isn’t firing — that’s a build issue, not measurement noise.
Check the change date. Line up your GA4 purchase trend against the migration/theme-update date. A clean cliff on that date confirms the change caused it and narrows what to inspect.

How to fix each break

Missing tag/pixel — reinstall it the update-safe way (see prevention below), not by re-pasting into theme code. One install per platform; remove any leftovers.
Customer event not firing on checkout — implement or repair the web pixel so checkout_completed sends transaction ID, value, currency and items. This is the usual reason a purchase never reaches GA4 or Meta after a migration.
Consent reset — reconfigure consent mode and wire the banner to update consent state, not just hide the tags. Some loss is legitimate; a total block usually isn’t intended.
Domain / cross-domain — add the current checkout/thank-you host to cross-domain measurement and confirm the same GA4 stream carries through checkout.
Product-ID mismatch — re-sync your product feed and Meta catalog to the new IDs, and update Ads conversion mapping so catalog and conversion matching line up again. This one is easy to miss because nothing looks broken on the storefront.
Duplicate tags — a migration can leave both the old and new install firing. Audit every surface and keep exactly one source per event so you don’t over-count. (If you’re seeing inflated counts, our sibling piece on Shopify duplicate purchase events walks through de-duplicating.)

How to prevent it next time

Use update-safe tracking. Prefer Shopify customer events (web pixels) and app-based / channel installs over tags hard-coded in theme files. Theme-embedded tags are the first thing a theme update or theme swap drops.
Keep one source per event. No duplicate installs across theme, apps and a tag manager.
Make tracking QA a migration step. Before go-live, run a test order and verify every platform in a staging or preview context; after go-live, run it again on the live store. A structured Shopify conversion tracking audit turns this into a repeatable pre/post gate instead of a scramble.
Snapshot the baseline. Record what fired before the change so you have a real “post” to compare against.

Common mistakes

Assuming a theme update can’t touch analytics. If tracking lived in theme code, an update or swap removes it — silently.
Fixing before measuring. Changing tags, consent and domains all at once with no baseline means you never learn what actually broke.
Ignoring product IDs. Storefront looks perfect, but re-issued IDs quietly kill feed and conversion matching.
Testing only browse events. Pageviews can fire while the purchase doesn’t — always verify a full checkout, not just a product view.
Trusting the vendor dashboard as the books. Shopify admin is the source of truth for orders; GA4/Meta/Ads are marketing signals.

When to get help

If a test order lands in Shopify but not in your analytics, if multiple platforms went dark on the same date, or if you can’t find which link in the chain snapped, it’s worth handing off. Tracking regressions are precise — a customer event, a consent config, a product-ID re-sync — but easy to get wrong under live traffic, and every day they run costs you real budget on bad data. Building tracking QA into the migration itself is exactly what our store migration service is for.

Analytics went dark after your migration? Send us your store URL — we’ll audit tags, checkout events, consent, domains and product IDs, find what broke, and get your tracking recording real data again. See our store migration service or get a free profit audit.