“Meta says 12 conversions. Stripe says 30.”
Your ad platform and your payment processor disagree, and the gap is wide enough to change what you do with your budget. Here is where those conversions actually go and how to get most of them back.
A composite of engagements I have run, not a specific client. The numbers are illustrative, but the shape of the problem is one I see repeatedly.
The month looks bad
A premium homeware brand spends £4,200 on Meta over a month. Average order value is £320. Meta’s dashboard reports 12 purchases, which works out to a £350 cost per acquisition. £30 more than the average order. On paper, the channel is destroying money.
The decision gets made
The team drafts a plan to halve Meta spend and move the budget to another channel, where the reported numbers look healthier. Nobody is being careless; they are reading the dashboard exactly as intended.
Stripe disagrees
Stripe shows 30 orders in the same window, and the post-purchase “how did you hear about us” survey attributes most of them to Instagram. Real cost per acquisition is closer to £140 against a £320 order value. The channel is comfortably profitable, and it is about to be switched off because of a measurement fault.
Where the other 18 purchases went.
Measurement wasn’t broken in predictable ways, nor is it a 404. The browser-based pixel simply never got the chance to fire. Every layer below removes a slice of the truth before it reaches Meta.
Proportions are illustrative. The real split varies enormously by audience, device mix, and how your consent banner is configured — measuring your actual split is part of the audit.
Ad and tracking blockers
A meaningful share of visitors never load the Meta pixel at all. The script is requested from a domain that blocklists recognize, so it is dropped before a single event fires.
Safari ITP and iOS ATT
Browser-set cookie lifetimes are capped at days, and app tracking prompts let people opt out entirely. The purchase still happens; the link back to the ad click does not survive.
Consent denials
Visitors reject tracking on the website consent banner; the browser tag does not fire. That is the banner working correctly, but without a fallback, the conversion vanishes rather than being modeled.
The last mile
Payment completes on a redirect page, the customer closes the tab before the pixel loads, a script error prevents the event from firing, or a weak mobile connection drops the request. The pixel needs the browser to load, and the browser sometimes does not obey.
Reduce the dependency on the Browser.
The principle is simple: send the conversion from a system you control, not from the browser on a user’s device.
The same month, measured properly.
It will never match exactly — and it should not.
Meta and Stripe are counting different things. Meta credits a conversion to the click that earned it within an attribution window, including view-through; Stripe counts money received today, regardless of when the customer first arrived. Add modeled conversions and cross-device journeys, and a residual gap is not just expected; it is correct. The goal is a gap that is small, steady, and explainable.
Not when it is set up properly. Both routes carry the same event_id, and Meta uses it to collapse duplicates into one conversion. Deduplication failures are the most common way a rushed CAPI implementation makes reporting worse, not better, which is why validation is a real phase of the work and not a formality.
No, and you should be skeptical of anyone who promises it. They measure different things over different windows. What you can reach is a materially smaller, stable month-to-month, and understood gap; enough to make confident budget decisions.
Server-side tagging is not a way around consent. Consent Mode v2 forwards the consent state. It models denied users in aggregate rather than tracking them individually, and handles identifiers accordingly. I build to whatever your legal position requires.
The most reliable trigger is your order or payment webhook, and wiring that up usually needs someone with backend access for a short spell. There is a GTM-only path that avoids this and still recovers much of the loss; it is just less bulletproof because it still starts in the browser.
Typically two to four weeks. The container setup is quick. Most of the time goes on getting the event payload right and then validating against Stripe until the numbers reconcile. If you already have a server-side implementation in place, the timelines are shorter.
A server container has a real hosting cost; modest for most businesses, but not zero, and it scales with traffic. I size it and tune it as part of the build so there are no surprises on the cloud bill.
Sound like your setup?
That is usually where we start. Thirty minutes, no obligation — and you leave knowing whether this is your problem or something else entirely.
Book a free 30-minute call