Your ad platform says fourteen conversions this week. GA4 says six. Your actual sales ledger, the one with real names and real invoices attached to it, says nine. At some point in the next meeting, someone is going to ask which number is correct, and the honest answer, the one nobody wants to give out loud, is that all three are correct, and none of them, by themselves, mean what everyone in that room assumes they mean.
This is what gets filed under conversion tracking issues, and it’s rarely one broken thing. It’s usually three or four small, individually reasonable decisions that happen to disagree with each other the moment you put their outputs side by side.
The Symptom: Your Numbers Don’t Match Across Platforms
Before fixing anything, it helps to accept a slightly uncomfortable fact: your ad platform, your analytics tool, and your CRM were never going to report identical numbers, because they’re not measuring the same event the same way, on the same timeline, with the same definition of “credit.” Treating a mismatch as proof that something is broken is the first mistake. The second mistake, and the more expensive one, is assuming the gap is fine and never checking whether part of it actually is a bug.
Why GA4 and Your Ad Platform Will Never Fully Agree
Two structural reasons sit underneath almost every mismatch you’ll ever see:
- Different attribution windows. Most ad platforms default to a short attribution window, frequently somewhere around a 7-day click and a 1-day view. GA4, by contrast, looks back across a window measured in months for its conversion paths. A purchase that happened twelve days after someone clicked an ad can get full credit in GA4 and zero credit on the ad platform, simply because the ad platform stopped counting that click as relevant after day seven.
- Different attribution models. Since the shift to data-driven attribution as the GA4 default, credit for a conversion gets distributed across multiple touchpoints based on a model, not assigned entirely to whichever channel happened to come last. Most ad platforms still report in a way that’s closer to last-click for their own channel. Same conversion, two entirely different accounting systems deciding who gets to claim it.
Common GA4 Tracking Problems
Past the attribution-model disagreement, a meaningful chunk of GA4 tracking problems come from configuration, not philosophy:
- Missing required event parameters. A purchase event fired without a
valueandcurrencyparameter still shows up as an event in GA4, it just won’t behave like a conversion in revenue reporting, which makes it look like tracking failed when really the event just wasn’t given the information it needed to be useful. - Consent Mode blocking tags before consent is granted. Under Google’s Consent Mode requirements for EEA and UK traffic, tags that aren’t properly wired into the consent signal either get blocked outright or get modeled, estimated rather than measured, which can look exactly like “tracking broke” in a specific region while actually being a compliance configuration issue.
- Default channel grouping confusion. Traffic landing without clean UTM parameters, through a redirect chain, a shortened link, an app-to-web handoff, often gets bucketed into “Direct” or “Unassigned” instead of the channel that actually sent it, quietly inflating one bucket and starving the channels doing the real work.
- Data thresholding. With Google Signals enabled, GA4 will withhold or generalize certain rows of data below a population threshold for privacy reasons. A low-traffic segment can simply not appear, which is occasionally mistaken for a tracking failure when it’s a privacy feature doing exactly what it’s designed to do.
Attribution Is an Opinion, Not a Fact
Attribution gets discussed like it’s a measurement, when it’s actually a model, a set of rules someone chose for assigning credit across touchpoints that, in reality, all contributed something. Last-click gives all the credit to whatever happened right before conversion. First-click gives it all to whatever started the journey. Data-driven tries to distribute it proportionally based on observed patterns. None of these are wrong, and none of them are the singular truth, they’re different lenses on the same underlying behavior, which is precisely why two platforms running two different models will keep disagreeing no matter how perfectly each one is configured.
Where Tag Manager Quietly Breaks Things
A surprising share of tracking failures never touch GA4’s configuration at all, they happen one layer earlier, inside the container. Common culprits worth checking against Google Tag Manager’s own documentation:
- A container with unpublished changes, where someone tested a tag in Preview mode, it worked, and then nobody actually hit Publish, so production is still running the old version.
- Trigger conditions scoped too narrowly or too broadly, firing a conversion tag on every page load instead of only the confirmation page, or never firing it at all because the trigger is watching for a URL pattern that changed during a site redesign.
- Tag sequencing issues, where a tag that depends on another tag having already fired (a dataLayer variable that hasn’t been set yet) runs in the wrong order and silently fails to read the value it needed.
The Real Fix: Server-Side Tracking and Deduplication
Client-side tracking alone, a pixel sitting in the browser, has been degrading in reliability for years now, between ad blockers, browser privacy restrictions, and intelligent tracking prevention quietly trimming what a browser-based pixel can actually see. The more durable fix, and the one worth building properly rather than patching repeatedly, is server-side tracking through something like a Conversions API, sending the same event from your own server rather than relying solely on the visitor’s browser to report it.
Done correctly, against documentation like Meta’s Marketing API docs, this catches conversions the browser pixel alone would have missed. Done carelessly, it creates a new problem entirely, the same conversion getting counted twice, once from the browser, once from the server, which inflates your numbers in a way that looks like good news right up until someone reconciles it against actual revenue.
What the Tutorials Conveniently Leave Out
The part that separates a tracking setup that holds up from one that quietly lies to you for months:
- Deduplication depends on an exact match, not a close one. Browser pixel events and server-side CAPI events need to share the same event ID for the platform to recognize them as the same conversion rather than two separate ones. Generate that ID inconsistently, on the client one way and the server another, and you get silent double-counting that looks like strong performance and is actually a bug inflating your own numbers.
- Hashed personal data has to be normalized first, or it simply won’t match. Sending an email or phone number to a Conversions API means hashing it with SHA-256, but the platform expects that value lowercased and trimmed of whitespace before hashing. Hash “John@Email.com ” exactly as typed and the resulting hash won’t match what the platform expects, and the event gets quietly discounted rather than throwing an obvious error anyone would notice.
- Ad blockers aren’t a tracking bug, they’re a chunk of your traffic that was always going to be invisible to client-side tools. Before chasing a “missing conversions” mystery for days, separate how much of the gap is genuinely broken configuration versus simply the portion of visitors whose browser was never going to let a client-side pixel fire in the first place. Server-side tracking closes part of this gap. It does not close all of it, and treating it as a total fix sets up the next round of confused numbers.
- Your attribution lookback window is a setting, not a default you’re stuck with, and almost nobody checks it. GA4 lets this be adjusted in Admin settings, and most accounts are still running on whatever was set the day the property was created, frequently mismatched against the much shorter windows the ad platforms use for their own reporting.
- “It worked in Preview” is not the same as “it’s live.” Tag Manager containers sit unpublished more often than anyone wants to admit, and a tag confirmed working in Preview mode that never got published is functioning exactly like a tag that was never built at all.
Where This Fits
Conversion tracking doesn’t fail because anyone is careless, it fails because browser pixels, server-side events, attribution models, and consent requirements are all independently reasonable systems that were never designed to agree with each other out of the box. Getting the numbers to actually reconcile takes building deliberately around that disagreement instead of hoping it resolves itself.
This is exactly the work behind the conversion tracking system OJC Labs builds for clients, GA4 configured correctly, server-side events deduplicated against the browser pixel, attribution explained rather than just reported.
If your dashboards have been disagreeing with each other for longer than you’d like to admit, get in touch and we’ll find out which numbers are actually telling the truth.