Introduction
You open GA4 and the purchase count is about 20% below what your order management system says. The first suspect is usually a tagging mistake. On a headless commerce site, though, purchases can go unrecorded even when every setting is correct.
The reason is that the front end showing products and the checkout handling payment run as separate systems. Tracking responsibility is split by a page transition, so if nothing carries data across that seam, the purchase event alone goes missing.
This article maps out which boundary loses what. Once you can isolate the cause, deciding where to intervene next becomes straightforward.
Three Boundaries Where Data Is Lost
In short, the loss isn't one leak in one place — it happens at three separate points along the path to purchase, each for a different reason. Let's take them in order.
The Moment the Checkout Screen Opens
The jump from cart to checkout is where information is most likely to vanish. Identifiers held inside the browser do not travel to the payment side once the page is left behind. Redirect without doing anything about it and all you're left with is the bare fact that a purchase happened, with no way to connect it to the ad or search result that brought the user in. Building a small handoff step into the standard flow, before the redirect, changes the stability of everything downstream.
The Moment the Order Data Arrives
Even if the payment-complete notification (a Webhook — a mechanism that automatically sends word when something happens) arrives properly, you can't send an accurate purchase to GA4 if the order carries no identifying information. What this looks like in practice is "orders are visible, but GA4 purchases won't budge." The problem isn't the destination settings — it's that the raw material for sending is incomplete. So you need a way to check, at intake, that everything required is present.
The Moment You Resend
Sends will sometimes fail because of a brief network problem, and you will need to resend. If nothing determines whether that order was already sent, one purchase gets counted twice. Tighten the exclusion rules too far, though, and you start dropping purchases that should have been recorded. Being able to resend, and never double-counting: those two have to hold at the same time. One without the other leaves the numbers unstable.
Decide What Counts as a "Purchase" First
Use Confirmed Payment, Not a Thank-You Page
If you decide a purchase happened based on whether a thank-you page rendered, your numbers will wobble with browser back buttons, rendering failures, and dropped connections. Using "an order whose payment is confirmed" as the basis is far more reproducible, and it keeps analytics, advertising, and management reporting aligned. Standardizing what counts as one purchase up front prevents both reconciliation headaches and disagreements between teams later.
The Cause Is Rarely in Just One Place
"We set it up, but the numbers still don't match" shows up in several forms: counts that differ even after event names are aligned, purchase totals that disagree between the ad platform and GA4, or specific orders that quietly go missing. Because the causes sit in different layers, fixing one may not resolve anything. Starting with "which boundary lost it?" keeps you from making guesswork changes and gives you a sensible order of operations.
Splitting the Roles of Front-End and Server Tracking
Why the Front End Can't Follow a Purchase All the Way
Browser-side tracking is good at capturing behavior — which pages were viewed. Leaving the confirmation of a purchase entirely to it, though, isn't realistic. Browser type, extensions, connection quality, and differences in how pages transition can all knock out that final event. Assigning behavior tracking to the front end and confirmed-fact recording to the server puts you in a much better position to stand behind your numbers.
Assume Tools Will Never Match Perfectly
Running an operation where GA4 and your ad platform dashboards always agree exactly is not achievable in practice. They differ in when a conversion is counted, how credit is assigned across touchpoints, and what gets excluded. Decide in advance how much divergence is acceptable, and investigate only when it exceeds that band. With that rule in place, you can keep improving without halting day-to-day operations.
Working with a Small Technical Team
If you have few engineers in-house, aiming for fine-grained optimization from day one produces worse results than prioritizing a basic setup that doesn't break. Standardize the definition of the purchase event, implement the identifier handoff, and make success-rate checks a routine. Narrow it to those three and quality improves step by step, even without deep technical knowledge. The implementation itself was handled with an AI agent, but deciding what counts as correct was a call people had to make.
Three Things to Settle Before Design
What Counts as the Correct Number
Which event confirms a purchase, whether tax and shipping are included in the revenue figure, and at what point cancellations and refunds are reflected. Without these decisions, the same data gets interpreted differently by different people. Writing them down keeps the criteria steady as the team grows and makes handovers much easier.
What Gets Handed Off
Decide which pieces of information travel all the way to the purchase. At minimum: an analytics identifier, an order identifier, and an identifier showing which site the order came from. Adding more fields increases both the maintenance burden and the risk of leaking information, so start with only what's essential for tying a purchase together. Add fields later, based on what operations actually turn out to need.
How You'll Monitor It
Make success and failure counts visible, prepare a resend procedure that a non-technical team member can run, and review the numbers weekly or biweekly. Monitoring isn't only for catching problems — it also tells you what to improve first. Grounding decisions in numbers keeps the operation from depending on one person's instincts.
Summary
Purchase conversions go missing in headless setups because data is lost at three boundaries — moving to checkout, receiving the order, and resending — each for a different reason. Before hunting for a misconfiguration, work out which boundary is broken. Then settle the definition of a purchase, the information to hand off, and the monitoring approach before you start building. That gives even a mostly non-engineering team a clear basis for decisions.
The next article covers the first boundary: how to carry identifying information across the checkout redirect.