Direct to consumer
Headless storefront
The front end and the checkout are two different origins, so the identifier stored on the first one is not readable from the second, and the purchase lands as a new visitor unless identity is carried across deliberately.
Paid, fixed scope · Within ten business days after complete access
What breaks
Custom front ends on their own domain with commerce, cart or checkout served from a platform domain, and any storefront where the buyer changes host mid-purchase
Browser storage is scoped to an origin. When the front end runs on one host and the purchase completes on another, the cookies and local storage holding the campaign source and the client identifier are not available at the point the order is created. The buyer is one person; the browser treats them as two visitors, and the second one arrives from nowhere. Nothing errors. The first origin reports a healthy funnel that stops at checkout, the second reports orders from direct traffic, and both reports are internally consistent, which is what makes the seam so easy to miss when each is reviewed on its own.
Why nobody catches it
A headless build is usually a considered engineering decision made for performance or flexibility, and it is reviewed as an engineering decision. Measurement continuity is not a requirement anyone wrote down, so it is not on the acceptance criteria and nobody fails the launch for it. Afterwards the drop is read as a checkout conversion-rate problem, because that is exactly what it looks like on the chart, and the team spends its next quarter optimising a checkout that was never the thing that broke.
The work
A written map of both origins, which identifiers survive the crossing, and an end-to-end trace of one real order across the boundary.
- 01Establish which identifiers exist on each origin and which of them survive the transition, by observation rather than by assumption
- 02Carry campaign source and client identifier across the boundary deliberately, in the request rather than in storage that cannot follow
- 03Send the purchase from the server against the order record, so the event does not depend on which origin the buyer finished on
- 04Trace one real order end to end across both hosts and keep the trace
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 headless and custom front ends 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