Get your Validation procedure tracking to 95%+ accuracy guaranteed in writing.
A tag that fires isn't a conversion that landed. This page documents what happens between "the build is finished" and "the engagement is done": the live test transactions, the ten-order payload comparison, the deduplication check inside each platform's own interface, the consent states, and the pass criteria we hold ourselves to.
Free30 minutesNo obligation
Validation procedure · what breaks
What goes wrong without a validation procedure
- 01
Preview mode proves the tag, not the pipeline
GTM preview shows a tag firing in your browser. It says nothing about whether the platform accepted the payload, deduplicated it against the browser event, or silently dropped a required field.
- 02
One test order is a sample size of one
Guest checkout, logged-in checkout, discount codes, subscriptions and PayPal each take a different code path. A single test order exercises exactly one of them and hides the other four.
- 03
Deduplication gets assumed, never confirmed
Both events go out carrying an event_id and everybody moves on. Meta's Events Manager will actually tell you whether the pair was deduplicated — if someone opens it and looks.
- 04
Consent is only ever tested in the accepted state
Setups get validated with the banner clicked through. Nobody checks what fires when a visitor denies, or accepts analytics but refuses marketing, which is where double-fires and silent gaps live.
Validation procedure · the fix
What validation gives you at handoff
Evidence you can inspect, not assurances
You get the order numbers, the payloads, and each platform's own confirmation screen for those same orders. Nothing in the handoff rests on us saying it works.
Every checkout path exercised at least once
Guest, account, discounted, subscription and alternative payment flows each produce a verified event before sign-off, so the rare path isn't discovered by a customer.
Known behavior under a consent denial
You can state precisely what is and isn't sent when a visitor declines, because it was tested in that state rather than inferred from the consent tool's documentation.
A baseline that makes later drift visible
The validated payload becomes the reference. When a theme update strips a field six weeks from now, monitoring has something real to compare against.
Validation procedure · architecture
The validation pipeline, from first order to sign-off
Validation runs as a fixed sequence because each stage assumes the one before it passed. A field-by-field payload comparison on a checkout path nobody tested proves less than it appears to.
- 1
Stage 1: Live orders on every checkout path
Real orders with a real card on the production site — guest, logged-in, discounted, subscription and alternative payment methods — each refunded afterward.
- 2
Stage 2: Ten real orders, compared field by field
Ten genuine customer orders with every payload field set against the backend record: value, currency, transaction_id, items[] and the hashed identifiers.
- 3
Stage 3: Dedup confirmed in each platform's UI
Meta Events Manager, Google Ads diagnostics and GA4 are opened for named orders to confirm the browser and server pair collapsed into one conversion.
- 4
Stage 4: Each consent state tested separately
Granted, denied and analytics-only are each exercised live, and what fires and what's suppressed is recorded tag by tag rather than taken from the consent tool's documentation.
- 5
Stage 5: Sign-off call, then monitoring left on
Every criterion is marked off with you on a call, and alerts on event volume, API error responses and match quality run from that day forward.
Validation procedure · diagnose
Run your own ten-order comparison — Validation procedure
You can do this on an existing setup without touching a tag, and it surfaces most of what a full validation pass finds.
- 01
Pick ten orders that took different paths
Two guest checkouts, two logged-in, two with a discount code, two on an alternative payment method, and two of whatever your unusual case is — subscription, deposit, split payment.
- 02
Pull the backend record for each one
Order number, gross value, currency, line items with quantities, and the customer email or phone as stored. This is the column everything else gets compared against.
- 03
Find each order in the platform's event data
In Meta, open the Purchase event in Events Manager and inspect sample events for the order identifier; in GA4, look the transaction_id up in the ecommerce purchases report. An order you can't find at all is your first defect.
- 04
Compare field by field, in both directions
Value matching the backend to the cent, currency as the right ISO code, transaction_id identical, items[] carrying the same SKUs and quantities. Then look the other way for fields the platform received that the backend never had.
- 05
Check dedup and match quality on those same orders
If you send browser and server events, confirm both carry the same event_id and that Meta shows the pair deduplicated rather than as two conversions. Note the Event Match Quality on Purchase while you're in there.
- 06
Then place a denied and an analytics-only order
Order once with marketing consent declined and confirm nothing marketing-related fired, then once with analytics-only. This is where double-fires and silent gaps usually turn up.
Validation procedure · prove
The criteria we sign off against — Validation procedure
These are pass or fail, not a scorecard — if one fails we fix the cause and re-run the affected stage from the top. Passing means the data lands and matches your records; it does not mean a platform will assign attribution credit the way you'd prefer.
Source of truth
The ten compared orders in your store backend, processor or CRM
- Every money event present in both the backend record and the platform for all ten compared orders, with no exceptions.
- Value matching the backend to the cent, currency as the correct ISO code, and transaction_id identical on both sides.
- No required parameter arriving null: event_id, value, currency, transaction_id, and the identifiers each platform matches on.
- Deduplication confirmed inside each platform's own interface for named orders, never inferred from event_id merely being present.
- Meta Event Match Quality at 8 or above, with the parameters contributing to each score listed per event.
- The consent matrix matching what was specified, and the accuracy ratio at 95% or better over a settled window before handoff.
Validation procedure · free audit
What we check in the free audit
- Pick ten orders that took different paths
- Pull the backend record for each one
- Find each order in the platform's event data
- Compare field by field, in both directions
- Check dedup and match quality on those same orders
- Then place a denied and an analytics-only order
Checked against
The ten compared orders in your store backend, processor or CRM
Free30 minutesNo obligation
Validation procedure · when not to buy
When lighter QA is enough — Validation procedure
The full procedure costs a day or more of our time and yours, and some setups genuinely don't need it.
- One checkout path, one ad platform, and someone in-house already compares platform counts to the order table monthly. Two test orders will do.
- You're changing one parameter on a setup that was already validated. Re-test the affected event and its dedup, not the whole pipeline.
- Lead gen with a single form and no CRM stage between the submit and the money — a submitted form plus one platform check covers most of the risk.
- Your spend is small enough that a day of validation costs more than the misattributed budget it would prevent. Run the ten-order comparison yourself.
Validation procedure · what we deliver
What validation produces
A live test-transaction log
Real orders placed on the production site and refunded afterward, each recorded with its order number, the path it took, and the timestamp.
A ten-order payload comparison
Ten real customer orders with every field in the platform payload set against the backend record: value, currency, transaction ID, item array, hashed identifiers.
Deduplication screenshots per platform
Meta Events Manager showing the browser and server pair deduplicated for named orders, plus the equivalent diagnostics in Google Ads and GA4.
A consent-state matrix
What fires and what's suppressed under granted, denied, and analytics-only consent, recorded tag by tag and platform by platform.
Match quality evidence
Meta Event Match Quality per event with the parameters contributing to each score, and the enhanced conversions diagnostic status on the Google side.
A signed-off pass sheet and monitor config
Each criterion marked off with you on a call, plus the alert thresholds we leave running on event volume, error responses and match quality.
Written guarantee
95%+ tracking accuracy
Measured against The ten compared orders in your store backend, processor or CRM. Miss it and we keep working at no cost.
FAQ
Validation procedure questions, answered
Because test mode takes a different code path. Order confirmation pages render differently, webhooks may not fire, and payment processors skip steps. We place real orders with a real card on the production site, verify the whole chain, then refund them. It costs processing fees and it's the only way to see what a customer sees.
Ten is enough to cover every checkout path and to catch fields that populate intermittently rather than never — the failure mode a single order always misses. Beyond ten, the same errors repeat. If your catalog or checkout has unusual variants, we compare more, but we say so rather than quietly changing the number.
Every money event present in both the backend and the platform for the ten compared orders; deduplication confirmed in each platform's own interface, not inferred; Meta Event Match Quality at 8 or above; no required parameter arriving null; the consent matrix matching what was specified; and the accuracy ratio at 95% or better over a settled window.
We don't sign off. The miss gets a reason, we fix the cause, and the affected part of the procedure is re-run from the top — including new test transactions if the payload changed. A partial pass isn't a pass, and "it's within tolerance" isn't a category we use.
No, we run it. You're on the sign-off call, and we walk through the comparison sheet line by line so you can see which orders were checked and what came back. Everything is repeatable afterward — the join is a spreadsheet and the platform screens are ones your team can open.
Daily event volume against backend order counts, deduplication rate, Event Match Quality drift, error responses from the platform APIs, presence of the consent signal, and response codes on the server container itself. Alerts go to whoever you name. Most breakages we catch this way are theme updates and app installs, not our own work.
If you run one checkout path on one platform and someone in-house already compares platform counts to your order table every month, you have the important part of the procedure. The full validation earns its cost where there are several payment paths, multiple ad platforms, or a CRM stage between the click and the money.
More on Validation procedure
- GuideHow Accurate Is Your Conversion Tracking? Here's How to Actually Measure It
- Enhanced ConversionsEnhanced Conversions enrich the conversions that already fire. First we make sur…
- Meta CAPIA one-click CAPI integration sends thin events. That's why your Event Match Qual…
- LinkedIn CAPILinkedIn tracking that reports pipeline, not form fills
Free · 30 min
See what a validation pack looks like
WhatsAppFree30 minutesNo obligation
