Why your ad platform and your Stripe dashboard never agree

Your ad platform says four sales. Stripe says seven. Both numbers are in front of you, neither is a lie, and the difference decides whether you scale the campaign or switch it off. This is the single most common way coaches lose money on ads: not by buying bad traffic, but by making a real budget decision from a number they have quietly misread. This guide explains what is actually breaking, what you can fix, what you cannot fix at any price, and how to read the gap well enough to spend confidently. Disclosure up front: we make Drry, which includes the setup described near the end. Every principle here applies wherever you run your funnel.

The two numbers are counting different things

Stripe counts money that moved. It is a ledger, it is complete, and nothing a visitor's browser does can change it. Your ad platform counts something much harder: sales it can ATTRIBUTE, meaning ones it managed to connect back to a specific person who saw or clicked a specific ad. Every sale in Stripe is real. Only the sales the network could match appear in Meta.

So the honest framing is not "my tracking is broken". It is "my ad platform sees a SUBSET of my sales, and I need to know how big that subset is". Once you hold the numbers that way, a consistent 60% match rate stops being alarming and starts being useful, because a campaign that doubles your attributed sales almost certainly doubled your real ones too.

What actually breaks the browser tag

The traditional pixel is a piece of JavaScript in the visitor's browser. Four things routinely stop it, and none of them are your fault:

• Content and tracking blockers. A meaningful share of people run one. The tag is not slowed down, it is never fetched at all, so the sale it would have reported simply never existed as far as the network is concerned.
• Browser privacy defaults. Safari and Firefox limit how long tracking cookies survive. Someone who clicks your ad on Monday and buys on Friday may no longer carry the cookie that linked those two moments.
• App tracking permission on iOS.When people decline the "allow this app to track" prompt, the identifiers that let a network tie an in-app ad view to a later purchase go away. A large majority decline.
• Ordinary life. They saw the ad on a phone and bought on a laptop. They clicked, thought about it for nine days, then came back by typing your name. No pixel catches either, because no pixel can.

Notice that the first three are delivery problems and the fourth is a matching problem. That distinction is the whole of what follows: one of these is fixable with better plumbing, and the other is a fact about how people buy.

What server-side tracking fixes, and what it does not

The fix for delivery is to stop relying on the visitor's browser to make the report. When the purchase happens, your platform's own server tells the ad network directly, over an ordinary API call. Meta calls this the Conversions API; TikTok calls it the Events API. A browser extension cannot block a request made from a server it never sees, so the event always arrives.

There is a second, subtler benefit: the server knows things the browser does not. It knows on a SIGNED payment webhook exactly what was charged, in what currency, and to whom, which means the value attached to the conversion is the real one rather than a list price the page happened to display.

Expect server-side sending to recover a good portion of what blockers were eating, and expect the cross-device and long-consideration gap to remain. That remaining gap is not a defect to be engineered away. It is the honest cost of people being people.

Consent is part of the plumbing, not a legal afterthought

If you have visitors in the EU, the EEA or the UK, advertising identifiers require their prior agreement. That is not a banner you add for appearances: it genuinely changes what you can measure. A visitor who has not accepted tracking arrives from your ad and the click id in that link cannot be stored, so a purchase they make an hour later has less to match on.

The practical consequence is worth planning around rather than resenting. Your European campaigns will read worse than your American ones for reasons that have nothing to do with the ads. Compare like with like, judge each market against its own history, and never conclude a region is underperforming by holding it next to a region with different measurement rules.

Refunds: the part almost every guide gets wrong

Suppose a sale comes back. You would expect the conversion to be removed from your ad reporting, and it is reasonable to assume that a good integration does that automatically. It does not, and it is worth knowing why before you build a budget on the number.

Neither Meta nor TikTok offers a way for a website to retract a web conversion it has already reported, and both reject a negative purchase value, so "send minus fifty dollars" is not available either. Google does have a genuine retraction mechanism, but it lives behind its Ads API and a Google-issued developer token, which is a different integration entirely rather than a setting somebody forgot to switch on.

What a good setup does instead is report the refund as its own separate event. That gives you two things worth having. You can see refund volume per campaign, which sometimes reveals that your cheapest traffic is also your least durable. And you can build an exclusion audience from refunders, so the network stops looking for more people like the ones who asked for their money back. The original purchase count stays where it is; if you want it reduced, that is a manual job inside the ad platform.

The checks worth running before you touch the budget

• Use the test tools first.Meta's Test Events tab and TikTok's equivalent show events arriving live, without polluting your real numbers. If a purchase does not appear there, no amount of budget analysis is meaningful yet.
• Buy your own product once. A real checkout, at a real price, refunded afterwards. It is the only test that exercises every step in the order a customer does.
• Check for double counting. If both your browser tag and your server report the same purchase, the network needs a shared event id to collapse them. Without it you will read twice your real performance, which is far more dangerous than reading too little.
• Wait a full attribution window. Seven days from the click for most objectives, plus a settling day or two. Numbers before that are not early, they are wrong.
• Reconcile monthly, not daily. Compare attributed sales to the real ones in Stripe once a month. Daily comparison is noise, and noise invites tinkering.

How this works in Drry

On the Growth plan ad tracking lets you connect your own Meta, Google and TikTok pixels, and they stay yours: your ad account, your data, your audiences, with nothing routed through us. Add a Conversions API token for Meta or TikTok and purchases, subscriptions and leads are sent from our servers on the signed payment event, carrying the real amount charged and a hashed email rather than a plain one. Refunds and lost disputes are reported as reversals, with the honest limits described above.

The consent banner, the regional rules and the record of who agreed to what are handled for you, and your pixels load only on your public pages: your funnels, your bio link, your shop and your join page, never inside the community itself, so nothing follows a paying member around while they are reading a lesson. There is a test-event button in the console so you can watch an event land in your own Events Manager before you trust a single number.

The goal was never a perfect number, because there is not one to be had. It is a number you understand well enough to bet on: delivery fixed where it can be fixed, consent handled properly, refunds visible, and a match rate you have measured rather than assumed. Get those four right and the gap between your ad platform and your bank stops being a mystery and starts being a constant, which is all a budget decision ever needed.