By Stormly in Knowledge
Published: Sep 18, 2026
Shopify Says One Number, GA4 Says Another: How to Reconcile Your Order Counts
You export your Shopify orders for October. 1,847 completed purchases. Then you open GA4. It says 2,319 purchase events. Different numbers. You look at these two numbers and now you need to decide: what do you tell the team? Which number goes in the weekly report? Which one determines your conversion rate, your paid ROAS, your retention cohort sizes?
This is not a rare problem. It is the default state of analytics for most Shopify stores. The two systems almost never agree. And most teams solve this by picking one number and hoping nobody asks where the other one went.
This post is about why the gap exists, what each number is actually counting, and how to reconcile them into a single source of truth – and what that reconciliation process reveals about the rest of your product data.
Why Shopify and GA4 Are Always Measuring Different Things
The mismatch is not a bug in either system. It is a feature of what each system is built to do.
Shopify counts orders. An order in Shopify is a server-side record: a customer completed a checkout, the payment was processed, and Shopify created an order object in its database. This number is as close to ground truth as you can get for “how many customers paid us.” It includes orders from every channel – direct, organic, paid, email – and it is not affected by browser privacy settings, ad blockers, or JavaScript failures.
GA4 counts purchase events. A purchase event in GA4 fires when a piece of JavaScript on your thank-you page sends a measurement request to Google’s servers. This happens client-side, in the customer’s browser. If the browser blocks the script, the event does not fire. If the customer closes the tab before the page fully loads, the event does not fire. If the pixel is on a checkout domain that is not your primary domain, the event may not fire correctly.
These two methods of counting will always produce different numbers. The question is how different, and why.
The Five Structural Reasons for the Gap
1. Shopify’s checkout subdomain
If you are on a standard Shopify plan, your checkout happens on checkout.shopify.com, not your store domain. This is a cross-domain tracking problem. When a customer moves from yourbrand.com to checkout.shopify.com, GA4 treats it as a new session from a direct source unless you have explicitly configured cross-domain measurement. Many stores have not. The result: the purchase event fires on the checkout domain, but the attribution context (what channel brought the customer there) is lost or misreported, and sometimes the event itself is dropped.
2. ITP and consent variations
Safari’s Intelligent Tracking Prevention limits first-party cookie lifetimes. Customers who visit your store on Safari, add to cart, and return days later to complete the purchase may be treated as new sessions by the time they buy. Their purchase event may fire, but the user match to the original session fails. For stores with significant iOS traffic – common in fashion, beauty, and lifestyle categories – this accounts for a meaningful share of the gap.
3. Ad blockers and tracking prevention
uBlock Origin, Brave browser’s native blocking, and iOS/macOS tracking prevention all suppress GA4’s measurement protocol calls. These are disproportionately used by certain customer segments: tech-aware buyers, European customers on stricter browser defaults, and heavy mobile users on privacy-forward devices. The suppression is not random. It systematically undercounts specific demographics. A store with a 4% ad-block rate in its traffic will not see a 4% uniform undercount. It will see a larger undercount from specific segments.
4. Order edits, cancellations, and test orders
Shopify’s order count includes every order that was created, including orders subsequently cancelled, refunded, or flagged as test orders. GA4’s purchase event fires at the moment of checkout completion and does not retroactively reverse when an order is cancelled 48 hours later. Depending on your return and cancellation rate, this alone can explain a 2-5% gap in either direction. Test orders run during store development show up in both systems but can be filtered from Shopify’s reports – while they may persist in GA4 unless you explicitly exclude known internal IP ranges.
5. Cross-device and cross-browser journeys
A customer discovers your product on their phone. They save it and complete the purchase on their laptop. GA4 sees two sessions from two different devices, two different browsers, with no user-linking mechanism unless you implement client-side user IDs. The phone session shows as abandoned. The laptop session shows as a direct purchase with no prior touchpoints. The purchase event fires, but the user journey data is fragmented. For stores with high browse-on-mobile, buy-on-desktop rates – typical for higher-AOV products – this creates significant session-count and attribution distortion on top of the order-count gap.
For a broader picture of how these tracking gaps compound across channels, why your channel numbers never add up – and the product-level truth underneath attribution covers the full attribution chaos problem, including how Pinterest, Meta, and email numbers regularly contradict each other and what to do about it.
Which Number to Trust, and for What
This is the question most reconciliation guides avoid answering directly. Here it is plainly:
For revenue, orders, and financial reporting: use Shopify. Shopify’s order data is server-side. It does not depend on browser JavaScript, privacy settings, or cross-domain tracking. If Shopify shows 1,923 orders at an average order value of $87, you sold $167,301 that month. This is the number that matches your payment processor.
For traffic, channel attribution, and acquisition analysis: use GA4, with adjustments. GA4 is where you understand which channels drove visitors, which landing pages converted, and which traffic sources produced sessions that eventually purchased. The purchase event count in GA4 will be lower than Shopify’s order count, but the relative proportion of those purchases across channels is still informative for deciding where to allocate acquisition spend.
For conversion rate: neither number alone is correct. Your Shopify order count divided by your Shopify session count is not your real conversion rate. Your GA4 purchase events divided by GA4 sessions is not your real conversion rate either. Both denominators (sessions) and numerators (orders and events) are undercounted in different ways and for different reasons. Why the average eCommerce conversion rate hides more than it tells covers this in depth – but the short version is that blending all traffic into one CVR produces a number that moves with your traffic mix, not your store’s actual performance.
The mismatch between Shopify and GA4 also has a sibling problem that is separate from this discrepancy: Shopify’s own analytics sometimes reports zero purchases when orders clearly came in, even when GA4 shows the event fired. If you have hit that problem, what Shopify Analytics gets wrong and how to reconcile the numbers goes into the specific mechanics of why Shopify’s built-in analytics layer loses data even before GA4 enters the picture.
A Reconciliation Workflow That Actually Works
The goal is not to make the two numbers equal. They never will be. The goal is to understand the size and composition of the gap so you know when each system is reliable.
Step 1: Pull comparable date ranges from both systems.
In Shopify, export orders by created date for your reconciliation window. In GA4, pull purchase events for the same window. Note: GA4 timestamps purchases in the user’s local timezone by default; Shopify uses UTC. Adjust for this before comparing, especially if your store has meaningful traffic from multiple time zones.
Step 2: Calculate the gap percentage and direction.
If Shopify shows 1,923 orders and GA4 shows 1,541 purchase events, the gap is 382 orders, or about 20%. GA4 is undercounting. This is the more common direction – GA4 undercounts Shopify – but the reverse can happen when test orders, cancelled orders, or pending-payment orders inflate the Shopify count.
Step 3: Audit your checkout domain configuration in GA4.
Check your GA4 data stream settings for cross-domain measurement. If checkout.shopify.com is not listed as a cross-domain partner, your sessions are being broken at every checkout initiation. This single configuration error can account for a 10-20% undercount on its own. Fixing it requires adding checkout.shopify.com to your GA4 cross-domain list, reviewing referral exclusions, and testing with a real transaction.
Step 4: Filter Shopify for fulfilled orders only.
Remove test orders, cancelled orders, and orders placed by known internal users. This gives you the fulfilled order count that most closely represents real customer transactions. If the gap narrows significantly after this filter, internal order pollution was contributing to the discrepancy.
Step 5: Build a weekly tracking table.
The single most useful reconciliation artifact is a simple weekly table: Shopify fulfilled orders, GA4 purchase events, gap percentage, and a note column for any known events that week – a sale, a new product launch, a tracking configuration change. Tracking this weekly lets you detect when the gap widens suddenly, which usually signals a tracking breakage rather than a real drop in purchases.
What the Reconciliation Process Reveals About Your Product Data
Running this reconciliation teaches you something broader: session-based analytics and order-based analytics are fundamentally different measurement systems, and the gap between them cannot be fixed by finding a better pixel.
GA4 and similar tools were designed to track behavior in the browser. eCommerce stores generate their most important data server-side: orders, products, repeat purchases, refunds, categories, order values. Browser-based tracking can observe intent (a product page view, an add-to-cart), but it misses a meaningful share of outcomes (completed purchases) and nearly all post-purchase behavior (did this customer come back? which product did they buy next?).
This is why eCommerce analytics tools organized by the decision you’re trying to make draws a sharp line between tools built for traffic and channel analysis and tools built for product decisions. The Shopify vs. GA4 reconciliation problem illustrates that line clearly. GA4 is where you understand your traffic. A product-native analytics layer is where you understand what your customers bought and whether they came back.
Stormly connects directly to Shopify order data. The purchase count Stormly uses is the Shopify fulfilled order count, not a JavaScript purchase event. Product-level analytics – checkout conversion by SKU, repeat purchase rate by first-order product, cart abandonment by category – are based on the same data that matches your payment processor, not a pixel that dropped 20% of your buyers before they were counted.
The specific issue of GA4 systematically missing Shopify purchases – and which structural causes are responsible in each case – is covered in detail in why GA4 is inaccurate for eCommerce stores. If you are trying to diagnose which of the five causes is driving your specific gap, that post has the diagnostic steps for each.
The Number That Actually Matters
After running the reconciliation, most teams arrive at the same conclusion: Shopify’s server-side order data is the source of truth for anything that touches revenue, product performance, and customer behavior. GA4 is useful for understanding which traffic sources drove visitors and which campaigns deserve attribution credit.
The reconciliation process matters not because it produces a single unified number – it does not – but because it forces clarity on what each system is actually measuring. Once you know what each system counts, you stop building conversion rate targets and product decisions on top of the one that measures the wrong thing.
The stores that get this right build their product and merchandising decisions on order data. They use GA4 for acquisition. And they stop trying to make a browser-event tool do the job of a server-side order system.
Connect your Shopify order data and see product-level decisions that do not depend on pixels. Try Stormly free.