Hi everyone. I work on the onsite side of a number of Shopify stores, so I end up staring at a lot of dashboards, and since the checkout extensibility upgrade on the 26th a few of them have stopped agreeing with each other.
Shopify order counts look normal, but Meta reports fewer purchases across the same days. The gap is small enough that you would miss it unless you put the two numbers side by side, and the odd part is that it has not turned up on every store even though they are set up much the same way.
My guess is that the Conversions API events are the ones going missing. Everyone checked their Additional Scripts box before the deadline, but CAPI does not run from there. It goes through the native Shopify integration or through something like Elevar or Triple Whale, and all of those hook into the order status page, which is the page that got replaced. The browser pixel keeps firing normally, so deduplication means the total event count barely moves and the dashboard looks close to normal, while match quality is what quietly gets worse.
Two things I would like to hear from people who have already been through this.
If you upgraded earlier in the year instead of waiting for the deadline, did your CAPI events survive it, or did you have to reconnect the integration afterwards?
And for anyone on Google Ads, did your CPA move before the reporting showed anything? Smart bidding optimizes against whatever conversions it can still see, so I would expect the spending to change before the numbers do.
I will post what I find once I have a full week to compare.
@Taras_claspo Seeing the same pattern on a couple of stores we watch.
Aug 26 killed Additional Scripts on Thank You / Order status for non-Plus. Pixels that still lived there went quiet with no dramatic error. Shopify admin orders look fine. Meta (and sometimes Google) under-report.
Quick triage we use:
Confirm the Meta channel / web pixel is installed via Customer events (Settings → Customer events), not a leftover script on the old Thank You page.
Check the app that owned the purchase event has migrated to checkout extensibility / thank-you blocks. Place a real test order and watch Events Manager live.
CAPI vs browser pixel: if only one path broke, the gap stays small and easy to miss, exactly like you described.
Compare same UTC day windows. Timezone mismatches make “Shopify vs Meta” look worse than it is.
Plus stores with checkout.liquid leftovers need the same audit. Extensibility is the destination either way.
This is classic post-migration tracking debt. The store didn’t stop selling. The receipt page stopped talking to Meta.
If a store still has purchase events only in Additional Scripts, that’s the smoking gun.
One thing I would separate before reconnecting CAPI is an actual delivery failure from a consent/configuration change. Shopify notes that event counts can drop after moving from Additional Scripts to app or custom pixels because the newer pixel path respects customer consent, while legacy scripts often did not. Shopify also warns that, with a custom storefront domain, the customer-account domain needs to be a subdomain of it or pixels and cookie consent can fail on the order-status page.
For two affected stores and one unaffected store, I would compare the same four items:
Meta data-sharing level in the Facebook & Instagram channel. Shopify says CAPI is used at Enhanced or Maximum, not Standard.
Customer Events pixel status and a real test order in Shopify Pixel Helper.
Consent-banner integration/regions and the customer-account domain.
In Meta Events Manager, whether Purchase arrives as browser, server, or both, and whether the same event is deduplicated.
Then reconcile a small sample of Shopify order timestamps/IDs against Meta rather than only comparing daily totals. If the affected stores cluster on consent, domain, or data-sharing level, reconnecting CAPI alone may not fix it. Are the affected stores using the same Meta data-sharing level and customer-account-domain setup as the unaffected ones?
A quick way to tell which kind of loss you have: Meta Events Manager > your pixel > open the Purchase event and look at the connection-method breakdown (browser vs server) for the week before and after the 26th. If the browser share collapsed while server events held, the store was firing its purchase pixel from Additional Scripts and that path is simply gone now - which also explains why not every store is affected: stores already on the official Meta and Shopify app send events through the web pixel and CAPI and never touched Additional Scripts. One more subtle case worth checking: stores that ran browser pixel plus CAPI with event_id deduplication can report FEWER total purchases after the browser event died if the server event was only ever a partial backstop. The durable fix is the same either way - install or reconnect the official Meta and Shopify sales channel so purchase events flow through Customer Events and CAPI, then place one test order with a card and watch it arrive in Events Manager within a few minutes.
Taking your second question, since the thread has gone all in on the Meta half.
Yes, and there’s a structural reason it has to happen in that order. Smart Bidding and the reporting column are reading the same event stream on two different clocks. The bidding is live. It sees today’s conversions today, and when fewer of them arrive it reads that as demand softening and reprices within hours. The reporting is retrospective, so the exact days where the loss is happening are the days that are still settling, and they stay unreadable for as long as you most need to read them.
That leaves a window where the algorithm has already changed what it is doing based on something you cannot yet confirm. Worth worrying about more than the missing conversions themselves, because the bidding is learning from the hole the entire time it is open. A week spent training on a partial signal does not unwind itself the moment tracking gets fixed.
We’re one of the apps you’d end up looking at if you went shopping for a fix here, so I’ll be straight that nothing in my category touches this bit. The lag belongs to Google’s reporting rather than to your tracking.
The concrete thing I’d do before comparing anything is pull your own conversion lag rather than assuming it. On the campaigns table, Segment, then Conversions, then Days to conversion. Most of the people I’ve asked guess that number, and guess it low. Once you know yours you know which days are still moving and which have settled, so you can compare like for like instead of arguing with a column that hasn’t finished writing itself. The click-through window behind it can be set as long as 90 days, which makes “recent” a much wider stretch of your reporting than checking yesterday would suggest.
Following this one closely tbh, we’ve got a couple of stores where the numbers are just slightly off in the same way.
Nobody’s answered Taras’s Google Ads question yet so throwing in what we’ve seen, CPA did start drifting up for us before the reporting dashboards actually showed anything wrong, which lines up with his theory about Smart Bidding reacting to whatever signal it can still see. Kind of unsettling honestly, the ads look like they’re underperforming before you even know why.
The native Meta sales channel CAPI should survive the checkout upgrade because it does not rely on Additional Scripts. I would not reconnect it blindly, since that can create duplicate Purchase events.
Today I’d do this:
In Events Manager, compare Purchase by connection method for Aug 19 to 25 vs Aug 27 onward.
Run one paid test order and confirm browser and server events share the same event ID and deduplicate.
Check the Meta channel is on Enhanced or Maximum data sharing, then reconnect only if the server event never arrives.
In Google Ads, check the purchase action is still Primary and inspect Diagnostics. Avoid changing tCPA or budgets until conversion lag has passed.
CPA can move during a signal loss, but Smart Bidding already models normal conversion delay. A sudden CPA shift is more convincing when the primary conversion action also shows a drop in captured purchases.
@clickfromai is right about the lag modelling and I would narrow what I wrote above. CPA moving on its own is not evidence of a tracking loss. Plenty of things move CPA.
The part I would still defend is why the early days of a real loss look survivable. The delay model is fitted to history, most of it your own account’s, and in that history the conversions that arrived late did eventually arrive. It cannot separate a purchase that is coming next week from one that is never coming at all. So for the length of your usual delay window it keeps crediting the fill-in it expects, over the same stretch where the reporting column is also incomplete for ordinary reasons. Both look normal for the same period, and neither is.
What separates them is maturity rather than recency. Take the clicks from the week before the 26th and the clicks from the week after, then compare each at the same number of days out from the click, on the same conversion action. Ordinary delay hits both groups equally. A genuine loss leaves the later group short at equal age. Once you know which of those you have, CPA becomes worth reading, and until then it is a number moving.
That does mean waiting out your own delay window before the comparison says anything, which is a poor answer when the bidding does not pause to wait with you.
One consequence worth flagging while people are chasing the CAPI reconnection: during a gap like this your measured ROAS drops but your actual profit doesn’t move at all. The orders are still happening, Shopify sees them, Meta just stopped counting.
The risk is that someone looks at the dashboard, sees ROAS fall below what they think their threshold is, and pauses a campaign that was making money the whole time. Tobi.Akilo’s note about CPA drifting before dashboards showed anything is the same problem from the other end.
So before touching budgets this week, compare Shopify’s own orders by referrer against what Meta reports for the same dates. If Shopify’s number is healthy the campaign is probably fine and what’s broken is the measurement, which is a different thing to fix and doesn’t need a budget change.
For this Aug 26 gap, I’d start in Shopify admin at Settings → Customer events. Confirm the official Facebook & Instagram by Meta app is connected and subscribed to the purchase event; use the official Google & YouTube or TikTok app for those channels where it covers your setup. Remove any duplicate legacy Additional Scripts and compare identical UTC date windows before concluding that CAPI is missing.
If the official apps don’t cover a custom multi-network setup, I make and sell a $24 Custom Pixel Multi-Ad Kit with paste-ready Meta, Google, and TikTok Custom Pixel files for the post-cutoff flow: Shopify Custom Pixel Multi-Ad Kit (Meta + Google + TikTok) — Post–Additional Scripts. It’s a browser-side Custom Pixel kit, not CAPI or server-side GTM.
This lines up with what changed on 26 Aug: Shopify stopped running Additional Scripts and legacy order-status-page tags for non-Plus stores. Anything that read the order-status page directly (a lot of older CAPI setups from Elevar, Triple Whale, or a custom script) stopped getting that hook, even if the browser-side pixel kept firing fine. That’s exactly why your totals look close but match quality is down: dedup hides the gap because the event count barely moves.
Quick way to confirm: open Meta Events Manager, look at the Purchase event’s diagnostics, and check the browser vs. server split for the last week vs. late August. If server-side collapsed around the 26th, reconnect the Meta channel through Settings, Customer Events, rather than the old integration path; that’s what a few replies above already suggest and it matches what I’ve seen elsewhere.
If you want a faster gut check across all your channels at once (not just Meta), there’s a free page that reads your storefront’s current tags and flags which ones no longer fire at checkout: Is my Shopify conversion tracking alive? Free check | TrackAlive. Disclosure: that’s my app, TrackAlive.