If your migration broke Google Ads and Meta tracking, the fix is systematic, not mysterious. A migration changes every input ad tracking depends on: the domain and checkout URL, the pixels and tags themselves, your product and catalog IDs, and your consent setup. Any one of those breaking is enough to stop conversions from being recorded — even while Shopify happily processes the orders. The recovery is to reinstate and re-verify each piece: confirm the purchase event fires on the new checkout, reconnect the Google Ads conversion action and the Meta pixel plus Conversions API, realign product IDs with your feeds, and restore consent. Do that in order and both platforms start recording sales again.
Why a migration breaks ad tracking
Ad platforms don’t “see” your sales — they see a purchase event fired by a tag or API when someone buys, matched to a click. A migration can sever that chain in several places at once:
- Domain and checkout change. Moving from another platform (or a replatform, or a domain switch) means the checkout that fires the purchase event is new. Any hardcoded pixel on the old checkout doesn’t come along.
- Tags and pixels don’t carry over. A theme migration or a fresh Shopify build rarely brings your old tags with it. The Meta pixel, Google Ads tag, and any GTM container have to be reconnected on the new store.
- Product IDs change. This is the quiet one. If your migration reassigned SKUs, variant IDs, or the ID field used in your feed, your Merchant Center feed and Meta catalog no longer match what the pixel reports — so conversions and catalog sales break even when the pixel fires.
- Consent resets. A new store often means a new consent banner (or none). If consent isn’t granted or signaled, Consent Mode and the Conversions API suppress or drop events.
- Event IDs and dedup drift. If browser and server events stop sharing a common event ID, Meta either double-counts or, worse, you lose the deduplicated server event you were relying on.
This is the same failure family we cover in why tracking breaks after a Shopify migration — here the focus is the paid-ads recovery specifically.
Why it matters: you’re paying for what you can’t measure
When the purchase event is gone, Google Ads and Meta keep charging for clicks but stop recording the sales those clicks produce. Two things happen, both expensive:
- Reported ROAS collapses even though real orders are steady. Dashboards say your ads “stopped working,” and the natural reaction — cut budget or pause winners — is the wrong call.
- Smart bidding starves. Target CPA, Target ROAS, and Meta’s optimization all learn from conversion signal. Cut off that signal and the algorithms optimize toward nothing, so performance actually degrades the longer it runs blind.
You can be selling well on Shopify and, at the same time, watch your ad accounts spend into the dark. If your orders are healthy but Google Ads shows no conversions, the mechanics are the same as in Shopify sales but Google Ads shows no conversions.
The recovery checklist
Work top to bottom. Purchase conversions first — they protect budget and feed bidding — then catalog, consent, and attribution hygiene.
| # | Area | What broke | How to fix it |
|---|---|---|---|
| 1 | Domain + cross-domain | Purchase fires on a new checkout domain; sessions split | Confirm the store domain and checkout host; if checkout is on a separate domain, set cross-domain / linker so the click and the purchase stay one session |
| 2 | Checkout / purchase event | Old checkout pixel didn’t migrate | Verify a purchase event actually fires on the new order-status/thank-you step for a real order — this is the event everything else depends on |
| 3 | Google Ads conversion action | Purchase conversion no longer recording | Reconfirm the conversion action is active and firing, via the Google & YouTube channel or your own tag; check it’s set as primary for bidding |
| 4 | Enhanced conversions | Hashed first-party data not sent | Re-verify enhanced conversions for leads/purchases so match rates recover |
| 5 | Meta pixel | Pixel not on the new store | Reconnect the pixel; confirm PageView and Purchase fire with a value and currency |
| 6 | Meta Conversions API + dedup | Server events lost or double-counting | Reconnect the Conversions API and confirm browser + server events share an event ID so they deduplicate |
| 7 | Consent | New/absent consent banner suppresses events | Restore the consent banner and signal; verify Consent Mode / CAPI receive granted signals for opted-in users |
| 8 | Product IDs → feeds/catalog | IDs changed; feed/catalog mismatch | Realign the ID sent by the pixel/feed with your Merchant Center feed and Meta catalog so conversions and dynamic ads match products |
| 9 | Event IDs | Browser/server IDs no longer match | Ensure a single event ID per purchase across pixel and CAPI to keep dedup honest |
| 10 | Attribution windows | Defaults reset on new setup | Reconfirm attribution windows/models so post-migration numbers compare like-for-like |
Item 8 is the one teams miss. If your migration renumbered products, the pixel can fire a perfect purchase and Merchant Center still won’t credit it, because the reported ID isn’t in the feed anymore. The same mismatch is what makes Meta purchases go missing from the pixel.
How to verify: place a test order
Don’t trust dashboards until you’ve proven the chain end to end. Place a real test order on the migrated store and confirm, for that single purchase:
- The purchase event fires on the thank-you / order-status step (browser tag).
- The Conversions API logged a matching server event with the same event ID (Meta Events Manager will show it as deduplicated).
- Google Ads records the conversion against the action — allow for its reporting delay before deciding it failed.
- The product ID in the event exists in your Merchant Center feed and Meta catalog.
- Value and currency are present and correct, not blank or 0.
One clean test order verifies items 2–9 at once. Then watch real data recover over the following days rather than expecting instant numbers.
How to prioritize
If you can only fix one thing today, fix the purchase conversion — items 2, 3, and 5. That’s what stops budget from spending blind and what refeeds smart bidding. Catalog and product-ID realignment (item 8) come next because they restore dynamic/shopping performance. Consent, event IDs, and attribution windows are essential for accuracy but won’t, on their own, bring a dead conversion back — do them once the purchase signal is flowing again.
Common mistakes
- Assuming tags “carried over.” A theme or platform migration almost never brings your pixels with it. Verify, don’t assume.
- Ignoring product IDs. Teams reinstall the pixel, see it fire, and declare victory — while the feed mismatch silently kills catalog conversions.
- Forgetting the server side. Reconnecting the browser pixel but not the Conversions API leaves you exposed to browser/ad-blocker gaps the migration didn’t cause but did reset.
- Skipping consent. A fresh store with no consent signal can suppress events you think are firing.
- Judging recovery in an hour. Conversion reporting and modeling take time; give it days before you conclude a step failed.
A structured migration prevents most of this — see our Shopify migration checklist for the pre-flight version, and our store migration service if you’d rather have it done with tracking continuity built in.
When to get help
If you’ve reinstalled the pixels and conversions still aren’t recording, the break is usually deeper — a product-ID mismatch, a consent signal that never fires, or a deduplication problem between browser and server events. Those are hard to see from a dashboard and easy to misread as “ads stopped working.” A focused audit places a test order, traces each event across Ads and Meta, and pinpoints exactly where the chain breaks.
Ad tracking down since your migration? Send us your store URL — we’ll run the recovery checklist across Ads and Meta, restore your purchase conversions, and stop your budget spending blind. Get a free profit audit.