Conversion tracking validation framework
Validation is the part almost everyone skips, and it's what separates a setup that works from one that appears to. The framework is four rules: agree a source of truth in writing before anything is built, match per record rather than on totals, use a fully closed window, and re-run the check thirty days later. Totals are the trap — ten missing conversions and ten duplicated ones produce a perfect total and a broken setup, and that's exactly what a dashboard comparison shows you.
Free30 minutesNo obligation
Validation framework · what breaks
Where teams get this wrong — Validation framework
- 01
Comparing totals
Equal and opposite errors cancel out. A perfect total can hide a completely broken setup.
- 02
Validating in preview mode
Preview shows intent. Only a live payload shows what left.
- 03
Checking once and never again
A setup that holds at handover and drifts a month later is the harder failure to catch.
Validation framework · the fix
What a correct implementation looks like — Validation framework
A source of truth agreed in writing
Before any technical work, so the comparison has a reference.
Per-record matching
On an ID, not on a sum.
A fully closed window
Partial periods produce differences that are only timing.
A re-check after thirty days
Drift is normal and catching it early is cheap.
Validation framework · architecture
The four rules — Validation framework
Simple, and consistently skipped. Each one exists because of a specific failure it prevents.
- 1
Agree a source of truth first
The system whose record decides whether a conversion happened. In writing, before any build.
- 2
Match per record
On order ID, lead ID or booking ID. Totals hide equal and opposite errors.
- 3
Use a fully closed window
A partial period produces timing differences that look like faults.
- 4
Categorise the residual gap
Attribution overlap, blocked events, consent denial and duplication are four different problems with four different fixes.
- 5
Re-check after thirty days
A setup that drifts is more common than one that never worked.
- 6
Document it so someone else can run it
Validation that depends on one person isn't validation.
Validation framework · diagnose
Common mistakes and how to validate each
Ordered by how often we find them. Each one has a specific check rather than a general instruction to be careful.
- 01
Totals compared instead of records
Match on ID and count how many appear in one system and not the other. The number is usually a surprise.
- 02
Partial window
Re-run on a fully closed period. Half the apparent gap often disappears.
- 03
Gap treated as one problem
Split it. Overlap is expected; duplication is a fault. Fixing them the same way fixes neither.
- 04
Validated once at handover
Re-run it now. If nobody has since the build, that's the finding.
- 05
Non-comparable records included
POS orders, internal test leads, imported records. They belong in your total and not in a platform comparison.
Validation framework · prove
How to prove your implementation is right — Validation framework
Against your own records and a live payload, not against a preview screen.
Source of truth
whichever system you agreed, in writing, before starting
- Source of truth documented before any technical work.
- Records matched on a shared ID over a fully closed window.
- The residual gap split into named categories.
- The procedure documented and re-run by the client's own team.
- Checked on a live conversion, not in preview mode.
- Reconciled over a fully closed window, matched per record.
- Re-checked 30 days later.
Validation framework · free audit
What we check in the free audit
- Totals compared instead of records
- Partial window
- Gap treated as one problem
- Validated once at handover
- Non-comparable records included
Checked against
whichever system you agreed, in writing, before starting
Free30 minutesNo obligation
Validation framework · when not to buy
What this reference deliberately leaves out — Validation framework
Stated openly, because a reference that's silent about its own gaps is the dangerous kind.
- Acceptable gap size depends on your traffic mix, consent rate and channel set. We won't publish a universal threshold, because one doesn't exist.
- Statistical approaches like incrementality testing answer a different question and aren't covered here.
- Platform-specific attribution behaviour is covered on the comparison pages.
- Vendor documentation is the authority, not this page. Where the two disagree, the vendor is right and we'd like to know so we can correct it.
- Parameter names and behaviour change. Anything here is accurate as we last verified it; verify against the current documentation before you rely on it for a build.
Validation framework · what we deliver
The checklist — Validation framework
Source of truth named in writing
Store, CRM, booking system or billing.
Records matched on a shared ID
Never compared as totals.
The window is fully closed
No partial periods.
The residual gap is categorised
Attribution overlap, blocked events, consent denial, duplication.
The check is documented and re-runnable
By your team, without the person who built it.
Pricing
Pick the package that fits your ad spend
Browser-side starter
$400One-time fee · lifetime ownership
Repairs and verifies your existing browser-side setup against this reference, on a live conversion.
- Implementation checked against the spec
- Verified on a live conversion
- Reconciled against your own records
- Written handover
1st-party server-side
Recommended$800One-time fee · most popular
Money events sent from your own records through a first-party container on your subdomain, built to this specification.
- First-party server container on your own subdomain
- Events from your records, not the browser
- Deduplicated on a shared event ID at every destination
- First-party cookies beyond Safari's 7-day cap
- 95%+ accuracy and 8+ Meta EMQ, guaranteed in writing
Full 1st-party stack
$1,800One-time fee · lifetime ownership
Every paid channel server-side plus the offline loop, documented to this standard.
- Everything in 1st-party server-side
- Pinterest, Snapchat, Reddit and LinkedIn CAPI
- CRM and offline conversion loop
- Refunds and cancellations corrected wherever each platform allows it
- Monitoring so the next break surfaces in days
FAQ
Validation framework questions, answered
Because ten missing conversions and ten duplicated ones produce a perfect total and a broken setup. Totals can only tell you when things are badly wrong.
There's no universal number — it depends on your traffic mix, consent rate and channels. What matters is that the gap is explainable and stable month to month.
Monthly is ideal, quarterly is realistic, and always after a site release. Most breaks we find date to a deploy.
Someone internal. If the only person who can run it is the agency that built it, you don't have validation, you have a dependency.
Free · 30 min
Get a validation your own team can re-run
WhatsAppFree30 minutesNo obligation
