A conversion tracking audit is a structured review of the path between a real business conversion and the systems that are supposed to record it.
The goal is not to prove that your tracking is broken. It is to find out whether important events are missing, duplicated, carrying the wrong data, failing between browser and server paths, or reaching platforms in a way that no longer reconciles with the source of truth. If the event path is healthy, the audit should say so. If it is not, the diagnosis should show where the problem starts and what the minimum appropriate next step is.
What a conversion tracking audit is designed to find
A useful audit starts with a simple problem: the business sees numbers it cannot explain.
The store shows one revenue figure. An advertising platform shows another. Purchase counts differ. Browser and server events do not line up. Some orders seem to disappear from the tracking flow. Others appear more than once.
Those symptoms do not all have the same cause.
A conversion tracking audit is designed to separate them.
It should look for evidence of missing conversion events, duplicate events, browser/server gaps, attribution discrepancies, weak or missing identifiers, event-quality problems, and delivery failures.
The important word is evidence.
An audit should not begin with the assumption that the business is “losing conversions.” It should compare known transactions with the events that are meant to represent them.
That distinction prevents the audit from becoming a sales device.
The job is to answer: what happened to the conversion data, where did the path diverge, and does the issue actually require a technical change?
The event path an audit should examine
Good diagnostics follow the event from the source outward.
If you start only inside an advertising dashboard, you may see the symptom without seeing where it began.
A practical audit should examine the full path.
Source
The source is the transaction or business action you trust.
For ecommerce, that is usually a completed order or another confirmed business event in the store or backend.
The first question is basic:
Did the transaction happen, and did the source create the event or data needed to represent it?
If no event exists at the source, downstream delivery cannot repair it.
This is why the store or another approved source of truth should be the starting point for reconciliation.
Browser and server collection
Next, check how the event enters the tracking system.
Does the browser create an event?
Does a server-side source create another representation?
Are both expected?
If browser and server paths are active together, the audit should determine whether they represent the same business action consistently.
This is where missing browser events, missing server events, or overlapping implementations can become visible.
Processing and identifiers
Once the event exists, inspect what happens to it before delivery.
Check the event definition, value, currency, event or order identity, and any permitted identifiers relevant to the workflow.
If browser and server paths represent the same conversion, review whether the event identity is coordinated well enough for deduplication.
A technically delivered event can still be poor tracking if the value is wrong or the event cannot be traced back to the source transaction.
Destination and reconciliation
Finally, check whether the event leaves the tracking system and reaches the intended destination.
Then compare what happened there with the original transaction.
The audit should distinguish between an event that never arrived, an event that arrived with poor data, and a valid event that is simply being reported differently because of attribution or reporting rules.
That last distinction is critical.
Not every difference between a store and an ad platform is a transport failure.
The most common tracking failures an audit reveals
A tracking audit becomes useful when it can turn vague discrepancies into specific failure modes.
Missing events
A source order exists, but the expected conversion event does not appear somewhere in the path.
The audit should locate the stage where the event disappeared.
Was it never created?
Did browser collection fail?
Did server processing fail?
Did delivery fail?
Did the destination reject or fail to process it?
Without tracing the path, “missing conversion” is only a symptom.
Duplicate events
One real transaction may create more than one technical event.
That can happen when browser and server implementations overlap without coordinated event identity, or when multiple tags, plugins, scripts, or backend workflows all create the same event.
The audit should determine whether the duplicates are intentional overlapping representations with working deduplication, or genuinely separate events being counted as multiple conversions.
Wrong values
An event may arrive and still be wrong.
Purchase value can be missing, stale, formatted incorrectly, or different between browser and server paths.
Currency can also be wrong.
These problems matter because a platform can successfully receive an event that does not accurately represent the transaction.
Delivery success is not the same as data quality.
Weak identifiers
Identifiers make the event traceable.
If event IDs, order IDs, or other permitted identifiers are missing or inconsistent, it becomes harder to connect technical events to real transactions and harder to coordinate overlapping browser/server paths.
The exact fields depend on the destination and implementation.
The diagnostic principle is broader: the event should be identifiable enough to reconcile with the source and to support the verified workflow.
Tracking issue or attribution issue?
This is one of the most important questions in the audit.
Store revenue and advertising-platform revenue do not have to match exactly for tracking to be healthy.
The store records transactions.
Advertising platforms may apply their own attribution windows, attribution models, reporting cutoffs, and processing rules.
So the audit should verify the event path first.
Ask:
Did the source transaction happen?
Was the correct event created?
Were the value and currency accurate?
Were identifiers present and consistent?
Did the event leave the tracking system?
Did the destination receive or process it?
If those checks are healthy, then some remaining differences may be attribution or reporting differences rather than a tracking failure.
If the event itself is missing, duplicated, carrying the wrong value, or failing in delivery, then the discrepancy has a measurement component that should be fixed before debating attribution.
The order matters.
Verify the event first. Interpret attribution second.
That prevents teams from blaming attribution for broken tracking — or rebuilding tracking to solve a normal reporting difference.
When a tracking health audit is worth doing
A tracking audit is most useful when the numbers do not reconcile and the root cause is unclear.
Typical reasons to investigate include persistent missing purchase events, duplicate conversions, browser/server mismatch, unexplained value differences, delivery errors, weak identifiers, or recurring gaps between source transactions and platform reporting.
But an audit should not assume every discrepancy requires a migration or new implementation.
Sometimes the event path is healthy.
If the evidence shows no material tracking problem, that is a valid result.
If the evidence shows a problem, the next step should be proportional to the diagnosis.
A broken source event may need a source fix.
A deduplication issue may need better event identity.
A delivery failure may need a destination-specific repair.
A wider architecture problem may justify a larger implementation.
That is the purpose of a Tracking Health Audit: diagnose first, then recommend the smallest appropriate fix.
Related guides
Frequently Asked Questions
What should an audit uncover?
Missing/duplicate events, browser/server gaps, attribution discrepancies, weak identifiers, event-quality and delivery problems.
Which event-path stages should be checked?
Source, collection, browser/server processing, identifiers, deduplication, delivery, destination and reconciliation.
Can an audit reveal missing and duplicate conversions?
Yes; both are explicit confirmed audit-scope items, but conclusions must be evidence-based.
How do you separate tracking from attribution problems?
Verify event accuracy/delivery first; if the path is sound, attribution/reporting rules may explain remaining differences.
When should an ecommerce team run an audit?
When numbers do not reconcile and the root cause is unclear.