Direct to consumer
Hosted checkout
The purchase completes inside a checkout the platform owns and sandboxes, so the tag that fires there cannot see your data layer and cannot be debugged the way every other tag on the site can.
Paid, fixed scope · Within ten business days after complete access
What breaks
Storefronts where the purchase completes on the commerce platform rather than in your own page, and post-purchase scripts run inside a sandbox
A sandboxed checkout surface is isolated from the parent document by design. Code running in it cannot read the data layer the rest of the site populates, cannot reach variables your container resolves everywhere else, and is restricted in what it may do with the page around it. So the purchase event, the single event the entire ad account optimises against, is built in a different environment from every other event on the site, with a different set of available fields. Two consequences follow. The value and identifiers sent from checkout drift from the ones sent everywhere else, because they were assembled by different code from different sources. And the surface is the hardest one to inspect, so the drift is found late or not at all.
Why nobody catches it
Checkout is the surface nobody wants to touch. It is the one place where a mistake costs revenue immediately rather than costing a report later, so it accumulates a standing exemption from the changes made everywhere else. The tags there are frequently the oldest on the property, installed once during launch by whoever built the store, and left alone on the reasonable grounds that they appear to work. Appearing to work is exactly the failure mode: the event fires and the platform reports conversions. Only a reconciliation against the store record shows the number is assembled wrong.
The work
The checkout payload written out field by field, what each destination received from a real order, and the reconciliation against the store record.
- 01Read what the checkout surface can actually reach in its own environment, before assuming any variable available elsewhere on the site is available there
- 02Establish what the platform already sends natively from checkout, so nothing gets added that counts the same order twice
- 03Rebuild the purchase payload from the order record rather than from page state, so value and identifiers come from one source
- 04Put a real order through and record what each destination received, field by field
Elsewhere in ecommerce and subscription
One stack usually has more than one of these.
These boundaries compound. A brand running a hosted checkout and a subscription plan has two separate reasons for its channel report to be wrong, and fixing one leaves the other in place. The audit establishes which are live on your stack before anything gets rebuilt.
Start with the smallest useful check
Send one account running hosted checkout and we will read its setup before anyone signs anything.
Send the domain, the customer journey, and the platforms that should receive it. The tracking audit shows what is working, what is missing or duplicated, and the exact build recommended next.
Paid, fixed scope · Within ten business days after complete access