TL;DR
Flash sales break tracking in a specific, mechanical way, and almost nothing written about "pixel problems" describes it. Modern Shopify tracking has two halves: browser events fired by pixels during the session, and server events sent when the order is processed. The server half depends on Shopify delivering an order webhook to your tracking app, and that delivery is exactly what degrades under load: Shopify documents retries of up to 8 attempts over 4 hours, delays that can reach a day, and removal of the webhook subscription after multiple failures within a 24-hour period [1]. Shopify itself rehearses peak season hard; its 2025 readiness testing pushed synthetic loads of 146 million requests per minute before the real event [2]. Your tracking stack gets no rehearsal. This article maps which tracking layer fails in which way during a spike, what each failure looks like from your dashboards, and which gaps self-heal versus which ones lose data for good.
Key Takeaways
- Server-side purchase events for every ad platform are triggered by Shopify's order webhook. If the webhook is late, the purchase event is late by the same amount. There is no independent clock.
- Shopify's documented webhook behavior under disruption: retries up to 8 times over 4 hours, deliveries possibly a day late, and subscription removal after multiple failures inside a 24-hour period [1].
- After an outage clears, queued webhooks can arrive as a burst. Expect your ad platforms to show a surge of conversions with delivery timestamps hours after the orders actually happened.
- Late is not lost: a purchase event that arrives late still carries the original order data, and when the sender stamps the order's original time on the event, platforms attribute by click and event time, not arrival time. Most flash-sale "missing conversions" reappear within hours.
- Browser events degrade differently: they fire on time or not at all, and the usual causes on a peak day are consent choices, ad blockers, and shoppers completing checkout faster than tags load. We covered that layer in the ad-blockers and server-side guide.
- Your reconciliation anchor is Shopify's own order count. Ad platforms converge toward it over hours; if the gap is still widening a day later, you have a real failure, not lag.
Where your purchase events actually come from
Ask most store owners where their Meta purchase event originates and they will say "the pixel." For most serious Shopify tracking setups in 2026, that is no longer true for the purchase itself. The purchase is typically sent once, server-side, when the order exists, precisely because the browser at checkout completion is the least reliable place to fire the one event that matters most. Shoppers close tabs and block scripts; the order record does not lie.
That design decision, correct as it is, moves the purchase event's fate onto a single dependency: Shopify's order webhook reaching your tracking app. On a normal Tuesday, that delivery is fast and boring. During a flash sale, three documented behaviors change the picture [1]:
- Delivery slows. Shopify states plainly that you "might experience delays receiving webhooks" during disruptions, potentially "up to a day late."
- Retries stretch failures out. A delivery that fails gets retried up to 8 times over a 4-hour window. If your tracking app's endpoint is itself struggling, each order's event slides further down that schedule.
- Persistent failure removes the subscription. After multiple failed deliveries within a 24-hour period, Shopify removes the webhook subscription entirely. At that point events are not late; they stop, silently, until the app re-registers.
There is one more behavior worth knowing, documented by the integration engineers who live downstream of these queues: after an outage clears, the backlog flushes. They call it a recovery surge [3], and from a merchant's dashboard it looks like a strange gift: dozens of conversions landing in a burst, timestamped to arrival on some platforms and to the original event on others.
What does each ad platform see during the spike?
The same late webhook produces different symptoms on different platforms, because each one treats event timing differently.
| Layer | During the spike | After it clears |
|---|---|---|
| Shopify admin orders | Correct in real time; this is ground truth | Unchanged |
| GA4 purchases | Arrive when the server event lands; GA4 report processing adds its own delay on top | Converge toward order totals as processing completes |
| Meta purchases | Late events still match their click window; Ads Manager also models and restates recent days | Converge; recent days keep revising as delayed and modeled events land |
| Google Ads conversions | Uploaded per order once processed; Google then applies its own reporting freshness of about 3 hours for last-click and up to 15 hours for other models [4] | Converge; late uploads within the click-through window still count |
| Klaviyo events | Flows keyed to placed-order events trigger late | Sends catch up; time-sensitive flows may need review |
Two structural notes on that table. First, Google's freshness windows stack on top of webhook lag: an order whose webhook arrived two hours late, uploaded immediately after, may still take until the next morning to show in a non-last-click column [4]. Second, the platforms deduplicate well-built events: a tracking app that carries a stable event identifier per order means a late event lands once, and a redelivered webhook does not turn into a second purchase. That identifier discipline is the same mechanism we explained in the event deduplication guide, and it is what separates "late but correct" from the double-counting failures described in the server-side retries article.
Which failures self-heal, and which lose data for good?
Here is the honest sorting, because they are not all recoverable.
Self-healing: late webhooks, retry-scheduled deliveries, recovery surges, platform reporting lag. All of these end with the event delivered once, attributed to the right click, at the right value. The only casualty is your nerves between 10 a.m. and evening.
Permanent, small: browser-side funnel events (view, add to cart, checkout started) from shoppers whose sessions were consent-declined or blocked. These were never recoverable server-side and peak days simply have more of them.
Permanent, serious: two cases. If the ad platform's own API rejects or fails an event and the sender does not retry it, that conversion is gone; whether your tracking tool retries platform-side failures is a question worth asking it before November, and no honest vendor will claim the answer is free of edge cases. And if the webhook subscription is removed after sustained failure [1], everything from that moment until re-registration is lost. The second case announces itself with a flat zero; the first is quieter and shows up only as a platform gap that never fully closes.
One aside for the reader running the numbers at home: the permanent cases are rare precisely because the platforms designed for peak. Shopify load-tested at 146 million requests per minute and a final 200 million before BFCM 2025 [2]. The weak link on a flash-sale day is rarely Shopify or Meta; it is whichever piece of middleware between them was never rehearsed at that volume.
The on-the-day detection playbook
You cannot fix webhook lag while it is happening, and you should not try. What you can do is tell lag from loss with three checks, in order:
- Anchor on orders. Note Shopify's order count at a fixed time (Analytics > Reports in admin, or the live view). Every platform number gets compared to this, never to each other.
- Check arrival, not totals. In Meta's Events Manager and GA4's realtime view, look at whether purchase events are arriving at all, even at reduced rate. A reduced-but-flowing stream is lag. A hard zero for more than an hour while orders flow is a failure worth escalating.
- Re-read before reacting. Compare the order-to-platform gap at two points a few hours apart. Narrowing gap: lag, stand down. Widening gap: check the simplest culprits first, in this order: did anyone change checkout, theme, or apps this week; is the tracking app's status page reporting an incident; is one specific platform down while others flow.
The discipline that makes this playbook work is the freeze that precedes it: if nothing changed in the two weeks before the sale, the diagnostic space on the day collapses to "lag or platform incident," both of which resolve without you. The panic edits, the mid-sale pixel reinstall, the "let's just add the platform's native channel too" move: those create the double-counting and learning-phase damage that outlast the weekend.
FAQ
My ad platform shows fewer conversions than Shopify during a sale. How long should I wait before worrying?
Compare the gap at two checkpoints a few hours apart, anchored to Shopify's order count. Webhook lag plus platform reporting freshness (about 3 to 15 hours on Google's own numbers [4]) means most gaps close within a day. A gap still widening after 24 hours, or a hard zero while orders flow, is a real problem.
Can a late purchase event still be attributed to the ad click?
Yes, provided the sender stamps the event with the order's original time, which well-built server-side senders do. Platforms then attribute against the click within its window, not the arrival wall-clock. A purchase delivered hours late lands in the right campaign column once processed. The exception is an event so late it falls outside the platform's click-through window entirely, which webhook-scale delays do not approach.
Do browser pixels also slow down when traffic spikes?
Not meaningfully. Browser events are generated in each shopper's session and do not queue behind other shoppers. Their peak-day losses come from consent declines, ad blockers, and fast checkouts, the same as any other day, just at higher volume. The layer that queues is the server-side delivery chain.
Should I add the platform's native integration as a backup during BFCM?
No. Running two senders for the same purchase without shared event identifiers is how stores double-count their biggest weekend. If you want redundancy, verify your existing setup's deduplication in advance instead, as covered in the browser-versus-server-events explainer.
Sources
- Shopify Developers, Troubleshooting webhooks (retry schedule, delays, subscription removal). https://shopify.dev/docs/apps/build/webhooks/troubleshooting-webhooks
- Shopify Engineering, Preparing for BFCM 2025 (load testing figures). https://shopify.engineering/bfcm-readiness-2025
- Hookdeck, The recovery surge webhook failure mode. https://hookdeck.com/blog/recovery-surge-webhook-failure-mode
- Google Ads Help, Data freshness for conversion reporting. https://support.google.com/google-ads/answer/2544985
WeltPixel Conversion Tracking sends the purchase once, server-side, when Shopify delivers the order, carries a shared per-order event identifier so other pixels on the store cannot double-count it, and shows per-platform delivery status you can check on the day instead of guessing. A late webhook lands late, but it lands once.