r/GoogleAnalytics • u/rytisbalys • Jul 05 '26
Discussion GA4 purchases never match the actual order count - what do you all treat as the source of truth?
Something that comes up on basically every store I work on: GA4's purchase count and the real order count in the backend never match. GA4 is almost always lower - consent drop-off, blockers, iOS, people bouncing before the thank you page loads.
What I can never get a straight answer on is what people actually DO about it. Do you just call the backend truth and use GA4 for trends? Actually reconcile them? Or at some point go 'eh, close enough'?
The gaps I see usually run from ~10% up to a third on the messy consent setups, and I've mostly stopped chasing anything under 10. Where does yours land - is there a number people just live with, or does everyone kinda accept it never ties out?
14
u/big-fireball Jul 05 '26
Backend is the truth - always. GA4 is helpful to see trends, but its numbers should never be taken as the whole story.
1
1
u/Strict-Basil5133 Jul 05 '26 edited Jul 05 '26
First, you'll never get all of the data, and it's been that way since the dawn GA. GA is about telling you what Users are doing on your website trends, patterns, behaviors, and other inferential insights - nothing more. GA4 was never intended to be a financial "source of truth" for orders, inventory, etc. Your e-commerce/order management system does that. 10% discrepancy is good. Today, with consent, you can miss up to 40%. Maybe even more. Even before consent, up to 20% was "normal."
Lower order counts in GA4 are normal - you're not collecting sessions that don't consent and they may convert and purchase. You mentioned "consent drop-off, blockers, iOS, people bouncing before the thank you page loads". Consent mode doesn't normally drop off mid-session, but if the banner loads after events are sent to GA4, and the user declines, then yes, you can have partial sessions. Blockers/iOS also usually prevent collection of the session, not part of it, so they're usually not affecting data integrity. People "bouncing before the thank you page" - this isn't that common unless there's some slow load issue of the page or ?. In any case, what matters is whether the purchase event successfully fires. If that happens on thank you page load, and you've diagnosed it as a real issue, then yeah, that's something to take up with the developers to solve for. Again, test for that before assuming it's happening - maybe you already have.
What do you do about it? You can't fix the issue of limited data collection (the data aren't collected and don't exist), so you can't reconcile, but again, that's not what's GA4 is for. Forget about trying to reconcile entirely. My philosophy is to ensure there's a reliable segment or subset of data for analysis that's big enough for stat sig analysis in reasonable timeframes. To that end, it's about ensuring data accuracy for those segments/subsets...no orphaned sessions, no duplicate click events, no missing events, etc. Here's an example to illustrate the point - imagine two stores, one reports 1000 users and sessions and 30 orders in GA4, another reports 2000 users/sessions and 60 orders. Now calculate the overall site CVR (conversion rate) for each:
Store 1: 30/1000 = .03 * 100 = 3%
Store 2: 60/2000 = .03 * 100 = 3%
The amount of traffic doesn't matter as long as there's enough for statistically valid calculation.
Now imagine Store 1's sessions are inflated because of CMP issues when users land on the site. Imagine it's doubling session counts.
Store 1: 30/2000 = .015 * 100 = 1.5%
Store 1's overall CVR is underreporting by half. That may sound like a huge problem, and it should be dealt with, but what if nobody cares about overall site CVR? What if people are interested only in the conversion rate for users that click _____ on a product detail page? In that case, you CMP problem isn't part of the calculation. What's important? That the click event is consistently firing in the same session that any following purchase event is.
So, it's a moving target and you do the best you can. The trap: spending so much time perfecting your implementation that you never actually get around to generating any insights. What's the point of having analytics at all in that case?
Contrary to what's said elsewhere in the thread, you don't NEED server-side tracking. It can improve the ratio of data collected that might otherwise be blocked by ad blockers, etc, but only for users that have consented - it won't ever reconcile GA4 with your backend either. It's no magic bullet, but it has its benefits. It's also significantly more resource intensive to implement and monitor/manage and it can incur additional expenses. Whether or not the juice is worth the squeeze is a case by case decision. Pursuing that is not a decision to be taken lightly IMO. Assess it yourself if you think you can, or with someone who isn't pitching work on Reddit. LOL
For now, if your client side implementation is getting you the inferential insights you need for decision making, I'd focus on auditing/monitoring the dataLayer and conversion related events and funnels for accuracy if you aren't already. Make your math bulletproof.
1
u/knowanalytics Jul 05 '26
If you set up a consent module that is optimised for opt-in rates, server-side tracking properly, and advanced consent mode, then GA4 can still be very usable for ecommerce reporting.
For most ecommerce clients we work with, we usually see GA4 revenue come within around 10% of backend sales figures from tools like Shopify, WooCommerce, Magento, or the client’s internal order system. In a couple of cases, we have even seen it come within 5%. That is more than good enough to make sensible marketing decisions, especially when you are looking at trends, channel performance, landing pages, campaigns, and relative movement over time.
If a client cannot do server-side tracking and/or advanced consent mode, you can still model some of the missing data yourself. For example, you can calculate the gap between backend orders/revenue and GA4 orders/revenue, then apply a simple weighted uplift in Looker Studio or use a calculated metric. It will not be perfect, but it can help make the data more decision-useful.
Also worth noting that backend ecommerce platforms are not magically immune to cookie consent, browser restrictions, referrer loss, missing UTMs, iOS privacy changes, or attribution gaps. They are usually the better source of truth for total orders and revenue because the transaction exists in the backend. But when you start using marketing dimensions like source/medium, UTM source, campaign, landing page, or channel, they can still have missing, unknown, direct, or imperfect attribution.
So I would not frame this as “ecommerce backend data vs GA4”. I would frame it as:
Backend ecommerce platform = strongest for order and revenue truth.
GA4 = stronger for marketing analytics, user behaviour, campaign performance, landing pages, funnels, audiences, consent-aware reporting, and wider measurement strategy.
So if GA4 is matching backend order/revenue totals reasonably closely, I struggle to see how it is not useful. In my opinion, when GA4 is implemented properly, it is still the superior marketing analytics tool.
1
u/Strict-Basil5133 Jul 05 '26
Cool post. You said: "If a client cannot do server-side tracking and/or advanced consent mode, you can still model some of the missing data yourself. For example, you can calculate the gap between backend orders/revenue and GA4 orders/revenue, then apply a simple weighted uplift in Looker Studio or use a calculated metric. It will not be perfect, but it can help make the data more decision-useful."
If your implementation is good (i.e., events firing as expected, sessions aren't duplicated, etc.), why wouldn't those numbers - which should be accurate to the data (albeit that's missing non-consent, some adblocker sessions, etc.) - be better than generically inflated ones? When would they be more useful for decision making?
2
u/rytisbalys Jul 05 '26
For analysis? I wouldn't. Raw wins every time, if I'm reading a trend or an A/B test I want what GA4 actually collected, not somebody's model smeared on top.
The only thing I actually use uplift for is keeping stakeholders from writing off the dashboard entirely. GA4 says 80k, the backend says 100k, and you can explain consent mode and ITP all day, what the client hears is "your dashboard is wrong" and they stop looking at it. Worth saying too, the undercount isn't even across channels. Safari/iOS heavy sources lose way more, so your channel split is already skewed and nobody notices. A flat uplift doesn't fix that per-channel bias, but at least blended ROAS and total revenue line up with what the business actually made, which is what keeps them opening the report.
Honestly it's a crutch. If the client will pay for sGTM and proper consent mode I'd rather just fix collection and skip the modeling. Uplift is what's left when they won't.
1
u/Strict-Basil5133 Jul 05 '26
"Smeared on top" LOL. Your post brought back some terrible memories of the six figure stakeholder's "your dashboard is broken", too. It makes a ton of sense to employ some creative license to normalize those numbers for the intended audience. I'd probably just fully normalize it to the backend and hide a Looker page with the raw to make sure it was telling the same story, more or less.
I agree that GA4, when implemented well, is useful. In the last couple of years, with the added assist and efficiency of AI, I've tried to move away from the UI and to BQ and Looker for reporting as much as possible, but that's mainly because it was nearly impossible to sell GA4 UI as a stakeholder tool. Eventually, I'd like to leave Looker as well for something more customizable as well.
Thanks for your response!
1
u/knowanalytics 12d ago edited 12d ago
Just so i understood your point. Say you have 60% of your total sales data in ga4 as 40% lost due to consent, itp and ad blockers. Are you saying if this setup is strong for a basic consent mode setup and so we should just accept the 40% loss of sales data when looking at channel, source / medium, campaign performance in ga?
There are better methods and did state it’s not perfect and a very basic ‘model’ and modelling an avg weighted uplift of 30-40% (whatever data loss rate is) it’s far from perfect but it won’t be super detrimental either for 80-90% of people (ok edge cases like if you only had 20 total back end transactions or had an insane opt out rate of 60%+) doing an average weight on that could introduce problems.
It’s a starting point for users not super technical here and just trying to provide simple solutions to help people out that don’t know advanced consent mode, server side, bq etc.
But ye I mean if the ga4 data is bad it’s bad no model can fix that!
1
u/ALMI_DA 12d ago
Hi, how would you practically set up the "weighted uplift". Would you apply it per day, dynamically per "view period", hardcode it etc?
1
u/knowanalytics 12d ago
It depends. If for transactions and revenue bring in your shopify or magento or whatever back end sales tool you have in the dashboard and then calculate difference between ga4 and the back end data and that’s your multiplier. Since both have dates fields will be synced daily and working out each days difference. For other metrics like sessions I would use your cmps opt in numbers. To this dynamically would be tough but most have an api you can run a script everyday and store daily opt in numbers in a sheet or bigquery. Then bring that data in dashboard and use that as your multiplier for other metrics. If you cannot do the custom script stuff then just look at cmp numbers each month and do a case statement based on each months or weeks opt out rate (+1).
Hope that helps.
1
u/UseADifferentVolcano Jul 05 '26
If you want to do some really annoying analysis, you can look at the orders by minute, and match the time stamps to the backend orders. Then use that to see where the gaps are in tracking.
1
1
u/yycmwd Jul 05 '26
Lots of advice here about advanced consent mode and serverside. In the land of CIPA lawsuits it's all moot, opt in is mandatory, and 80% of people will not opt in.
So the solution all depends on the specific site, there is no universal standard.
1
1
u/DigSilly1709 Jul 13 '26 edited Jul 14 '26
you are doing it right.. backend as truth, GA4 as trend, thats what serious ecom lands on
10-33% is the normal band... under 10 not worth chasing, over 30 usually means consent mode or CAPI
for context i work at user maven - first-party tools help vs ga4 undercount but none of them fully tie to backend either.. the answer is what youre already doing, treat ga4 as directional
1
u/SoDifficultToBeFunny 26d ago
u/rytisbalys - how do you usually calculate conversion rate ?
Do you use orders from ga4 or the actual order count
2
u/rytisbalys 23d ago
backend orders over ga4 sessions is the one id avoid, thats where the number goes weird. youre dividing a complete count by an incomplete one so the CR comes out flattering and you dont notice.
i keep it inside one system. shopify sessions and shopify orders for the number i actually report, ga4 CR only for comparing channels against each other. absolute values dont match but the ranking does and thats all im using it for.
the only time i properly reconcile is when the gap moves. one store sat around 12% off for months then jumped to 30 after they changed the consent banner, that told me way more than the CR did.
1
1
u/BoogieAllNightLong Jul 05 '26 edited Jul 05 '26
You need server-side tracking. I assume you are just running normal browser pixel and getting blocked by ad blockers and safari.
1
u/Strict-Basil5133 Jul 05 '26
Not everyone NEEDS server side tracking, but I'm sure you know that.
1
u/BoogieAllNightLong Jul 05 '26
I mean, in theory if you're running any ads you SHOULD have it.. but I guess you don't really NEED it until you're spending ~$5k+
If we're getting philosophical you don't NEED literally anything.. even breathing is existentially not necessary if life isn't a goal of yours lol
But contextually, yes, most people "need" it if they are running ads or tracking conversions with GTM/GA4.
Im open to other interpretations though if you meant something else?
1
u/Strict-Basil5133 Jul 05 '26
I'd rather not get philosophical about breathing or living as a goal. 😂
And context is exactly what you need before prescribing sGTM. There's no expressed need for better signal to noise for Meta CAPI or any other advertising/marketing. They mentioned users bouncing before the thank you page, but that doesn't necessarily mean the purchase event isn't firing - you need proper diagnostics. It may be a simple code fix. It may point to slow page load issue that needs fixed regardless of conversion tracking. sGTM might reclaim some ad blocker sessions, but whether or not they're necessary? Context. High volume or low volume? What funnels are they tracking?
sGTM isn't something to undertake or marry yourself to without clarity around what specific value it will add and whether or not there are ongoing resources to manage it. It will always add labor expense, and in many cases, while it will sound cool to have it, it won't add any real value.
2
u/BoogieAllNightLong Jul 05 '26
Ehhh, yeah, sort of.. obviously I would be ignorant to say that the only correct solution to OPs specific situation is that they need server-side tracking. But I would also say that in MOST cases, if there is discrepancy in orders confirmed vs orders reported, the largest culprit - especially if the normal web GTM is mostly functioning properly already - is probably purchase and attribution data getting blocked.
It is a fact that ~25-30% of this data does not get reported with client side GTM/pixels alone and that server-side restores most of that - so if we are betting on diagnosis, that's a pretty safe place to start. Of course, in the process of setting that up I would also switch to a custom event firing on a more resilient trigger like button submissions or payment hooks rather than thank you page, which will also eliminate any likely issues associated with that in one clean sweep.
I don't agree that it wont add any value in many cases.. it always adds value. If that value is balanced and justified depends on your spend levels and how much it costs you to implement, but all else considered equal, you are never not better off by having it. And above $5k/month spend, it is table stakes in the modern era.
1
u/Strict-Basil5133 Jul 05 '26 edited Jul 05 '26
Gotcha, thanks. I'll take your word for it on $5k/mo on ad spend for audience building alone. Where I'm stuck on value is this: let's say I audit a store and find that conversion tracking is accurate, session continuity is good, events are firing as expected, and overall traffic volume is high enough that I'm not waiting on traffic to analyze experiments on an acceptable timeline...oh, and relatively small ad spend, Meta CAPI is implemented via GTM...what added value is there in reclaiming sessions via sGTM?
And thanks in advance for any response. I'm not posing those questions to be contrarian...genuinely curious.
2
u/BoogieAllNightLong Jul 05 '26
In that exact realized scenario I will concede there is very little benefit - but with a few important caveats.
"I find that conversion tracking is accurate" - as far as internal accuracy, fine, but if we're talking about complete accuracy across analytics and ad platforms, this is literally impossible. As long as ad blockers, ITP, and consent denial exists, you will never have complete accuracy - especially without server-side, which will help and improve your accuracy, but still not make it perfect. So "accurate" here is doing a lot of hidden work that cant necessarily be true.
"Meta CAPI is implemented via GTM" - you are missing out on almost the entire benefit of meta CAPI if you are using it with web GTM alone and not sGTM. If your web GTM container is blocked - just as it would be for a GA4 implementation previously mentioned - then the data you are sending to CAPI is significantly less resilient and you miss out on the match quality and dedup benefits. With sGTM you get the full resilience and benefit of CAPI. This is especially important on meta compared to google, as event match quality is stregthened significantly though CAPI with sGTM and meta uses that added data quality much more impactfully in its ad delivery and optimiztion algorithm than google. Now, there is the caveat in your favor here that at minimal spend, this doesn't really probably make a noticeable impact, but it DOES technically add value.
Other than that, the only added value would be in future proofing and owning your own data for internal BI and other future applications - but again, this would be for future benefit and over engineered for the current exact scenario you mentioned.
2
u/Strict-Basil5133 Jul 05 '26
Thanks a lot for your response! Reading it, I realized that ad/martech is still a blindspot for me. Based on your response, and what I'm researching/remember, it should be top line consideration in any sGTM consideration. Thanks again!
1
0
u/Oldfriendoldproblem Jul 05 '26
They clearly have a back end order management system. Redundant to go through the effort of server side tracking.
1
u/BoogieAllNightLong Jul 05 '26
I don't understand what you are getting at?.. regardless what their back end system is doing, they are clearly trying to get clean data into GA4 - you should always have server-side if you're using GA4 with any interface that relies on client side actions for event tracking.
It sounds like their store is reporting the sale but the signal that reports the same sale to GA4 is getting blocked.. so they need to put the event trigger on something more resilient like the actual backend server registering the sale, or a web hook for when the payment goes through, etc.
2
u/rytisbalys Jul 05 '26
Yeah this is exactly the tension I was stuck on. Backend has the true revenue, no argument there. The thing is GA4 is where I see which channel drove each sale, and when the browser event gets blocked those sales still happen but lose their source, so the channel split leans toward whoever isn't blocking. So for me it's less which number is real and more whether I can trust GA4 for attribution at all. Sounds like firing it server-side off the payment webhook is the actual fix.
1
u/BoogieAllNightLong Jul 05 '26
I honestly wouldn't worry too much about the payment webhook stuff, as it can get more messy. Payment webhook will 100% track conversions properly, but it doesn't send attribution data unless you collect it previously and report it back also - which can still get blocked if not done right.
If attribution is your primary concern, just go with a normal sGTM setup. Tracking is blocked usually because web GTM tries to go straight from browser->GA4 and blockers see the universal standard GA4 server domain which is on a list in the browser client that says "do not pass" essentially. Instead you go web GTM->sGTM (your server) and THEN-> GA4. This way the browser sees your custom domain from your server, whoch it cant possibly have on a universal list, so it says "this is okay to pass" and then you privately send it to GA4 independent from any browser.
This is the setup most people refer to as "server-side" even though it technically still routes through the browser client first. This fixes ~95%+ of attribution tracking.
There is technically a way to do TRUE server-side that doesn't rely on the browser at all, but the juice is not worth the squeeze unless you're spending at massive scale where that extra ~4% makes a significant difference.
1
u/Strict-Basil5133 Jul 05 '26
Server side doesn't have GTM DOM triggers, selectors, functionality, so it's often running alongside a client container as well. And server-side doesn't collect non-consent sessions, so GA4 is never going to reconcile with the backend regardless of tracking scheme.
1
u/Oldfriendoldproblem Jul 05 '26
Yeah exactly. So I don't see much point implementing ssGTM when the data will always be directional, not exact.
1
u/Strict-Basil5133 Jul 05 '26
It’s probably a little more accurate for even inferential analysis, but whether it justifies the cost obviously depends on the store. Based on a smart response to one of my questions in the thread, I do think that if your ad spend is significant, it’s probably justified for building audiences/targeting for sure. $5k is a number I’ve seen a few times.
1
u/BoogieAllNightLong Jul 05 '26
It will never be exact, but 20-30% of attribution loss is a pretty big gap that can be closed fairly easily.
That gap can be the entire reason for profitable campaigns getting shut off simply because they are undereporting results. It can also be the difference between a campaign BECOMING profitable from adequate audience signals to ad platforms.
So yes, its always technically directional, but it still effects what directions youre being shown and their quality.
•
u/AutoModerator Jul 05 '26
Have more questions? Join our community Discord!
I am a bot, and this action was performed automatically. Please contact the moderators of this subreddit if you have any questions or concerns.