Analytics you can trust during peak

The stories are always the same. GA4 says conversion fell 18% overnight and Shopify says revenue is up. Paid claims more revenue than the store took. The dashboard the board is watching disagrees with the dashboard the trading team is watching, and three people spend Black Friday morning reconciling numbers instead of trading.

None of that is a tooling failure. It is the absence of a decision made in September: which number is authoritative, what each one means, and who is allowed to say "ignore that panel today". Peak is a bad time to have the conversation because everybody is tired and the stakes make people argue for the number that flatters their channel.

So the work is mostly agreement, done early, written down. The technical part is confirming that the numbers you agreed on are actually measured the way you think.

For each number, do a reconciliation while there is time to fix it. Take a single ordinary day, pull the figure from the analytics tool and the equivalent figure from Shopify, and compare. You are not looking for equality — you will not get it, and chasing it wastes the autumn — you are looking for a stable, explainable gap.

A tool reporting 8% fewer transactions than Shopify, consistently, is usable: you know the offset and you can read a trend through it. The same tool reporting 8% one week and 22% the next is not usable, and finding that out in September gives you two months to work out why. The most common causes are ad blockers, consent, and a tag that fires on a page some customers skip.

Write the gap down next to the metric on the dashboard. "GA4 sessions run ~10% below server-side" is one line that stops a recurring argument for a whole season.

Shopify's Customer Privacy API defines four consent purposes — preferences, analytics, marketing and sale of data — and determines what is allowed by combining three things: the merchant's configuration, the visitor's location, and the consent they have given. In regions that require consent, the documentation is clear that non-essential purposes are not allowed by default until it is given; elsewhere processing defaults to allowed.

Read that again with a peak traffic mix in mind. Your November audience is not your October audience. More paid, more international, more first-time visitors who have never seen your banner before. The proportion of sessions that consent to analytics moves, and your measured traffic moves with it, without a single thing having broken.

This is why the year-on-year comparison everybody reaches for on the Monday after Black Friday is weaker than it looks. Order data is unaffected by consent — you took the money, you have the record. Session and attribution data is not. Lead with orders in anything that goes upward, and treat channel attribution as directional.

If your measurement still depends on a script reading the page, peak will find it. Shopify's web pixels run in a sandbox: app pixels get analytics for subscribing to customer events, browser for asynchronous access to cookies and storage in the top frame, init for a snapshot of context and cart at render, and settings; custom pixels configured in the admin get the same minus settings. What neither gets is free rein over the DOM.

That constraint is a good thing and it has a consequence: anything you want to measure has to exist as an event. Shopify provides standard events such as page_viewed and product_viewed alongside the checkout progression, and you can publish custom events and subscribe in batches. A bespoke interaction — a size guide opened, a bundle configured, a delivery slot chosen — needs publishing deliberately.

Do that work in September too. Adding an event in peak week means the series starts halfway through the period you want to compare, which is worse than not having it.

Most teams run a code freeze for peak and exempt the tag manager, on the grounds that tags are not code. Tags are code. They execute on every page, they can break a checkout, and — the quieter problem — every one added mid-season makes the before-and-after incomparable.

Freeze tag changes at the same moment you freeze deployments, with the same exception process. If marketing needs a new pixel for a campaign that starts on the 20th, it goes in before the freeze or it launches with the campaign untracked and measured by order data. That is a real trade-off, not a formality, and being explicit about it beats discovering a stray tag in the diff in January.

One exception worth keeping open: turning things off. Removing a broken or slow tag mid-peak is almost always safe and occasionally saves the day.

Do not stand up a warehouse in October because the reporting is frustrating. It is a quarter of work, the payoff is in analysis you will not do until January, and a half-finished pipeline during peak is a third source of numbers to argue about. If you want one, start it in February.

Do not re-platform attribution in the run-up either. Every model is a set of assumptions, changing the assumptions changes every historical comparison, and peak is the period you will most want to compare against next year. Keep last year's model through this year's peak even if you have decided it is wrong.

And do not add dashboards. The instinct under pressure is more visibility; the effect is a room full of people watching different screens. Four numbers, one screen, one person who calls it.

• Shopify support and store management
• Consent, tracking, and a marketing stack that still works
• The pre-peak code freeze, and what it should cover