Every Black Friday and Cyber Monday checklist making the rounds right now covers the same ground: confirm inventory sync, QA the discount codes, schedule the email sends, stress-test the site for traffic. All of that matters. None of it tells you whether the number you will stare at on November 27th, the one that decides whether you scale ad spend at 11am or pull back, is actually true.
That is the gap. Search for a BFCM tracking checklist and most results are marketing-ops lists wearing an analytics label: "make sure UTMs are set up," "check your dashboards," nothing about why those dashboards specifically break under the kind of traffic Black Friday sends them. Tracking that looked fine in October fails in different, more expensive ways in the one week of the year every number matters most.
Why tracking breaks specifically at BFCM volume
Most tracking bugs are latent, not active. A duplicate tag that fires a purchase event twice has been sitting in the container for months, quietly inflating revenue by a percent or two that nobody notices in a normal week. At ten times the order volume, that same bug inflates revenue by ten times as much, in absolute dollars, inside a 48-hour window where everyone is watching the number.
In a delivered tracking audit, we found a purchase event firing from both a browser pixel and a server-side connector without a shared event ID on part of the catalog. The dedup rate between the two sources ran at roughly 71 percent, which inflated reported ROAS by about a third. On a normal Tuesday that gap is background noise. On Black Friday, at four times the order count, it is the difference between a campaign that looks like it is printing money and one that is actually losing it.
The fix for that specific failure mode is Meta's own, and it has existed the whole time: pass a matching event_id from both the pixel and the Conversions API call so Meta's deduplication logic can collapse the pair into one event instead of two. Checking that this is actually wired up, on every purchase-triggering surface, not just the main checkout, is the single highest-leverage item on this list.
The event sequence check, done properly
Google's own ecommerce measurement guide lays out the sequence GA4 expects: view_item, add_to_cart, begin_checkout, add_shipping_info, add_payment_info, and purchase. Most teams check this once at launch and never again.
Run it again now, specifically:
- Place one real test order on desktop and one on mobile, watching the dataLayer live in the browser's network tab, not just the GA4 DebugView, since DebugView can mask a parameter that is present but malformed.
- Refresh the order confirmation page once after the purchase event fires, and check whether it fires a second time. A refresh re-firing
purchaseis the most common single cause of GA4 reading higher than Shopify, and it is covered in more depth in our breakdown of GA4 and Shopify revenue mismatches. - Check every "add to cart" button location separately. Product page, quick-view modal, cart drawer upsell, and post-purchase upsell flows commonly instrument only one of the two or three places a customer can actually trigger the event, which under-reports add-to-cart volume right when a BFCM landing page funnels traffic through all of them at once.
The revenue reconciliation check
Pull three numbers for the same hour window:
- Shopify's order count and revenue.
- GA4's transaction count and revenue.
- Each ad platform's self-reported conversions.
In a delivered reporting audit, summed platform-attributed revenue exceeded actual store revenue by roughly 40 percent in a single reconciliation window, because the same order IDs were showing up in more than one platform's conversion export at once. That overlap gets worse, not better, during BFCM, because paid traffic volume rises across every channel simultaneously and the same customer is more likely to click two different ads before buying once.
The fix is not picking whichever platform's number is most convenient. It is checking order count against Shopify first, since a transaction-count mismatch is a tracking bug and a revenue-only mismatch can just be currency, refunds, or attribution window differences. Our Conversions API setup guide walks through getting this reconciliation right on the Meta side specifically, which is usually where the biggest BFCM gap shows up.
The consent and server-side check
Paid traffic spikes during BFCM specifically, which means more sessions than usual arrive through a consent banner before any tag fires at all. Two checks matter here:
- Consent gating: confirm the banner is actually gating correctly. A banner misconfigured to show only for one region, or a default "deny" state that never correctly updates to "grant" after a real click, quietly blocks tags for every visitor who hits it, and a bigger traffic spike just means more visitors silently excluded from measurement.
- Server-side capacity: if server-side GTM is already live, confirm the server container's quota and cost ceiling can handle four to ten times normal event volume without throttling or an unexpected bill.
If server-side GTM is not live yet, do not migrate to it this week. New infrastructure changes belong in the weeks before or after BFCM, never during the traffic spike itself.
What to do with the time you actually have left
How much of this list is realistic depends entirely on how many days are left before the sale starts, so decide based on that instead of trying to do everything at once.
- Four or more weeks out: run the full sequence, the dedup check, and the reconciliation, and fix anything you find. This is also the point to book a full Performance Audit, which checks tracking, CRO, paid media, and reporting together and hands back one prioritized list instead of four separate reports to act on separately.
- One to two weeks out: skip anything that requires a code deploy or a GTM container publish unless it is actively costing money right now. Run the test-order check and the reconciliation only, and freeze everything else.
- Inside BFCM week itself: do not touch tags or the container at all. Monitor hourly, comparing counts against Shopify, and write down what broke for the post-mortem instead of trying to fix it live, since an untested change made under traffic pressure is how most new tracking bugs get introduced in the first place.
If the checks above turn up more than one real problem and the sale starts in days, not weeks, a fixed-scope tracking audit delivered in one to two days will find the exact cause faster than guessing under pressure, with the fee credited toward the fix.
The number that matters is the one you can defend afterward
Nobody asks "was our Black Friday tracking accurate" during the sale. They ask it in the Monday debrief, when the CFO wants to know if the spend worked, and the honest answer depends entirely on whether anyone checked these six things before the traffic arrived. A BFCM tracking checklist that only covers inventory and email timing will not save you from that conversation. One that covers duplicate events, revenue reconciliation, and consent gating will.
