How to audit your tracking in an afternoon
Six measurements, all on your side, all in one afternoon. They tell you whether the problem is collection, sending or definition — and stop you replacing a tool over a defect the new one will also have.
Almost every tracking tool migration starts with the same sentence: the numbers do not match. It is a true and useless sentence, because it does not say where things broke. Switching tools without knowing where usually reproduces the defect under a new brand.
The six measurements below answer that question. None of them needs privileged access, a vendor, or waiting for the next campaign cycle.
1. Parameter coverage on what was delivered
Across the events that went out in the last seven days, what percentage carried email, phone, the click cookie and your own person identifier. Not what the payload could have carried: what left.
If email is below 50% on a purchase event, stop here — that is the bottleneck, and nothing downstream compensates for it.
2. The same order arriving twice
Count distinct orders and delivered rows over the same period. If rows exceed orders, you are sending the same sale more than once.
The cause is usually obvious once you look: the checkout webhook delivers the sale in real time, and the history sync delivers it again, every hour. In one case we measured, nearly half of the person-events emitted in a week were byte-identical rewrites of what had already been emitted.
Without deduplication by business identity — order number, transaction id — double coverage becomes double counting.
3. What goes up and should not
List the states present in the events you sent as conversions. The list is usually longer than expected.
Invoice issued, payment initiated, payment expired, disputed and refunded are not sales. Each one that goes up teaches the campaign to find more people like the ones who did not pay.
4. The lag between happening and being sent
Compare the event timestamp with the send timestamp. A few seconds is normal and changes nothing. Days means you are sending old sales in a reprocess — and Meta rejects events older than seven days, so part of what you think you sent does not exist on their side.
5. How many visitors became someone
This is the most uncomfortable and the most revealing one. On your capture page, how many distinct visitors are there, and how many of them have an email attached.
On one page we measured, 96% of visitors were anonymous across an entire month. That is not a tool defect: email only sticks when the person fills the form, or when the session identifier survives to checkout. Knowing that number changes your expectations about everything downstream.
6. The cash test
Sum the period's sales in your own records and compare with what the ad platform credits. They will never match, and they should not: the platform credits what it can attribute inside its own window.
What matters is the size and direction of the gap. If the platform credits more than your records, you have double counting or you are sending events that are not sales. If it credits far less, it is matching — go back to measurement 1.
How to read the result
| Symptom | Where the problem is | What to do |
|---|---|---|
| Low email, no duplicates | Collection | Form capture and identity survival to checkout |
| Rows above orders | Sending | Deduplicate by business identity |
| Non-sale states going up | Filter | Slice by status before sending |
| Lag of days | Reprocessing | Do not resend history as conversions |
| All clean and still off | Definition | Align what counts as a sale and what is a renewal |
The last row is the most common once the other four are fixed — and it is the only one engineering does not solve. It gets solved by writing the definition down.
In CrazyLeads these six measurements are screens, not queries: parameter coverage, delivered payload audit, states present in the send filter, and a comparison between what was delivered and what the source recorded.