A Tracking Audit Checklist to Run Before You Spend on Ads
Every ad platform optimises toward the events you send it. If those events are missing, doubled or wrong, the platform learns from a distorted picture of your business, and you judge the result with the same distorted numbers. Spending first and checking later means paying for that distortion.
The decision in front of you is simple: is the data good enough to start or scale spend, or should you fix it first? This checklist gives you a way to answer it in an afternoon.
Why "the pixel is installed" is not an audit
Most stores check one thing: does a tag exist on the site. A tag that exists can still fire twice, fire before payment, send no value, or never reach the platform because of a consent banner or a blocker.
Presence is the weakest test. A real audit asks three different questions in order: does the event fire, is its content correct, and do the totals agree with your own orders. A pass on the first says nothing about the other two.
The model: five layers, tested from the bottom up
Start with the thing you trust most, your order system, and move outward. Each layer depends on the one below it, so a failure low in the stack makes everything above it unreliable.
1. Source of truth
Your store or order system: what counts as an order, and when
Base2. Firing
Each key event fires once, at the right moment
Layer 23. Payload
Value, currency, order ID and items are present and correct
Layer 34. Matching
Browser and server copies of an event are recognised as one
Layer 45. Attribution
Campaign tags and consent do not hide or misassign the traffic
Layer 5
Reconcile totals at the end. If a layer fails, stop and fix it before testing the one above.
Layer 1: define the order
Decide what a counted order is. Is it a placed order, a paid order, a confirmed cash-on-delivery order, a delivered one? Write it down. Every later comparison needs this definition, and it is the same one you use in your break-even calculation.
Layer 2: firing
Place a test order and watch the events live. For GA4, DebugView shows events from a device with debug mode on, and Google's documentation explains how to switch that on in the Google tag or in Tag Manager. For Meta, use the Test Events tool in Events Manager. Check that the purchase fires once, only after a real order, and not on a page refresh. Meta's setup guide lists the events a store needs.
Layer 3: payload
An event that fires with the wrong content is worse than silence. For the purchase event check the value, the currency and the transaction ID. Google's ecommerce documentation lists the transaction ID as the unique identifier of the order, which is what protects you from counting a repeated purchase twice. Confirm the value is what the customer pays, in the right currency, and say in writing whether it includes shipping and tax.
Layer 4: matching
If you send events from both the browser and a server, they need to carry the same name and the same ID, or they are counted as two purchases. This is the most common reason a platform reports more orders than the store has. The article on duplicate purchase events explains the mechanics.
Layer 5: attribution and consent
Check that campaign links carry consistent tags, and that consent choices do not silently remove events for part of your audience. Google's documentation notes that DebugView may not show events when consent for analytics is not granted, so test with the same consent state a real visitor would have.
A worked illustrative example
Illustrative example, not real results. A store takes 100 confirmed orders in a week, and you compare three counts.
Percent of the store's order count. The gaps, not the exact numbers, are what you investigate.
GA4 is at 91 percent of the store, a 9-order gap (100 minus 91). Meta shows 118, which is 18 more than the store has. The gap in GA4 points to events not arriving: blocked scripts, consent, or a checkout step that skips the thank-you page. The surplus in Meta cannot be explained by lost data, so look for double counting first.
Treat this as a pointer, not a verdict. Platforms count with their own attribution rules and time windows, so an exact match is not the goal. The goal is a gap you can explain. An unexplained gap in either direction is the finding.
When the recommendation changes
- Very low spend. If you are testing with a small budget, a full five-layer audit may cost more than the test. Do layers 1 to 3, and expect noisy data.
- A platform you barely use. Audit the platform that receives most of your budget first.
- Cash on delivery. An order placed is not a sale kept. If your business works that way, layer 1 must define the order by confirmation or delivery, and the signal you send may need to change. See the Delivery Signal page.
- Recent changes. After a theme, checkout or consent-banner change, repeat layers 2 to 5.
Limits of what the audit can tell you
An audit shows whether your measurement is internally consistent. It cannot tell you which ad caused a sale, because users move across devices and channels and some paths are never observable. It also cannot prove data is perfect: tests use your own device, which may behave differently from your customers'. Re-run it on a schedule and after each change, and use the reconciliation view to track the gap over time.
Your next action
Run layers 1 to 3 this week with a single test order, and write down every discrepancy before touching any setting. If you would rather have the full chain reviewed, the Full Ads & Tracking Audit covers it, and the tracking setup service covers the fixes. Related reading: GA4 e-commerce events.