Ecommerce tracking audit: the checks that change a budget decision

A tracking fault matters when it moves a number that moves a budget. A misnamed event in a report nobody reads is untidy. Purchases counted twice in the report that sets next month's spend is expensive.

So rank faults by what they distort:

1. Revenue and orders. If reported purchases do not match real orders, every ROAS and CPA built on them is off.
2. Duplicates. The same order counted more than once inflates the platform that counts it.
3. Consent signals. If consent choices are not passed on, platforms may see less, or the wrong, data.
4. Everything else. Naming, UTM hygiene, internal traffic filters, event parameters. Fix these, but later.

That order is our view, not an industry standard. It follows one rule: the closer a fault sits to money, the earlier it gets checked.

Treat shop orders as the reference for revenue. Ad platforms and analytics tools are estimates built around that record. They attribute orders by their own rules, so they will not match the shop exactly. They should not drift far from it without a reason.

The reconciliation, in order:

1. Pick one period and one definition of revenue. Say whether it includes tax, shipping, discounts and refunds.
2. Pull orders and revenue from the shop for that period.
3. Pull purchases and revenue from Google Analytics 4 basics and from each ad platform.
4. Compare on the same attribution window. A platform with a longer window will claim more by design.
5. Put the three side by side. Write down the gap per source, and whether it is stable or moving.

A stable gap is a property of counting rules. A gap that jumps after a site release, a banner change or a new tag is a fault. Vendor guides on why numbers never match list causes such as differing windows and tracking loss, and they sell fixes for them¹. Read them for the causes. For the full diagnosis of one common gap, see Meta ROAS vs Shopify revenue.

Check the basics on the Google side as well. Conversion actions feed bidding, so Google Ads conversion tracking should be built on the same purchase event GA4 counts. Otherwise the two drift for reasons nobody wrote down.

A tracking pixel sends visitor actions from the browser to an ad platform. The Conversions API (CAPI) sends events from the advertiser's server instead. Meta describes it as a connection between an advertiser's marketing data and Meta's systems for targeting and measurement². Running both is a normal setup. It also means one purchase can arrive twice.

Event deduplication is the fix. Meta's developer documentation says an event arriving from both sources is counted once when the event name and event ID match and the second copy arrives no more than 48 hours after the first³. If the IDs differ or are missing, this method cannot match the two copies. Meta documents a fallback based on browser and user identifiers, but it works in narrower cases³.

What to check:

• Does every purchase event from the browser carry an event ID?
• Does the server event carry the same ID and the same event name?
• Does the platform's own diagnostics view show the two sources as matched?

Meta's Conversions API overview also tells advertisers to confirm that events are received, deduplicated and matched correctly². A purchase count in Ads Manager far above shop orders is the symptom to look for. The detailed fix is in Meta pixel and Conversions API deduplication. If you are weighing the server route itself, read is server-side tracking worth it. Server-side tracking means collecting data on a server you control and passing it on, instead of running every tag in the browser.

This check is about whether the banner's decisions reach your tags. Consent Mode is a Google mechanism where the consent banner passes the visitor's choices to Google tags, which then change what data they send⁴. Google's documentation distinguishes basic and advanced implementations. In basic mode, Google tags do not load until the visitor responds to the banner. In advanced mode, they load straight away and send cookieless pings while consent is denied⁴. For the practical difference, see consent mode basic vs advanced.

For advertisers with EEA traffic, Google's EU user consent policy sets obligations and refers to consent signals for ad user data and ad personalisation⁵. We are not your lawyer, and this is not legal advice. For the privacy side, see server-side tracking GDPR.

The audit question is mechanical:

• Does the banner pass a consent state to the tags on every page?
• Does the state change when the visitor changes their mind?
• Do purchases from visitors who declined behave as your setup says they should?

A broken consent signal is a high-impact fault because it shrinks what the platforms see without any error message.

You will find "normal" gap ranges online. Treat them as rules of thumb. The ones we found come from vendors and have no primary source behind them¹. We do not quote a number here, because we cannot stand behind one.

Use three tests instead:

• Is it stable? A steady gap points to counting rules. A moving gap points to a fault.
• Does it move with a release? Gaps that change the day a tag, theme or banner changed are tracking problems.
• Does it differ by event? If purchases match and add-to-carts do not, look at that event.

A gap you can explain is fine. A gap you cannot explain is the work.

Fix in the order of the money, and name an owner for each item. An audit without owners tends to end at "someone should look at this".

For campaign tagging, UTM parameters tell analytics where a visit came from, and UTM naming conventions decide whether your channel report can be read at all. It is boring work. It is also why some channel reports say "direct" far too often.

Then re-run the reconciliation. An audit with no before and after is a document, not a fix.

How often should you audit ecommerce tracking? We know of no sourced standard interval. Our view: repeat the revenue reconciliation every month, and run the full audit again after any change to tags, theme, checkout or the consent banner.

For ZFD: We run the audit in this order because a fault near the money costs more than a fault in a tag name. We also say plainly that a clean audit does not tell you which sales the ads caused. That is a separate question, covered in incrementality.