Skip to content

WooCommerce or Shopify: where tracking data gets lost

Both lose purchases when the browser never reaches the confirmation page, when consent isn't given and when a blocker stops the script. Each platform documents where, and each has a server-side route for part of it.

By , Founder & CEOPublished 6 min read

Run the numbers for your store: the free server-side tracking ROI calculator.

Both platforms document three ways the browser loses a purchase: the buyer has to reach the confirmation page, consent has to be given, and nothing may block the script. Shopify says its checkout_completed event is not triggered at all if the page fails to load, and WooCommerce's Google Analytics extension says purchase tracking requires a payment gateway that redirects to the order-received page. How many orders that costs you is a number you can measure: compare GA4 purchases with store orders for one closed week.

Where does Shopify lose purchases in the browser?

Shopify's checkout_completed event fires once per checkout, typically on the Thank you page. If the page where the event is supposed to fire fails to load, the event isn't triggered at all, and the order still sits in your admin. Consent is the second route. Shopify's pixel manager loads a pixel only when the visitor has given permission for every setting the pixel declares as required, and for app pixels the callbacks run only after consent is given where it is required, with the events that already happened on the page replayed afterwards. Blockers are the third: Shopify's own explainer on conversion APIs describes a server-to-server connection as avoiding issues like ad blockers, which is the exposure of a browser pixel.

Where does WooCommerce lose them?

WooCommerce's Google Analytics extension says purchase tracking requires a payment gateway that redirects the buyer to the thank you or order-received page after payment. An off-site payment that doesn't send the buyer back is a sale GA4 doesn't see. The same page warns of a discrepancy between your store and Google Analytics or Ads data where consent is required, and lists browser extensions and ad blockers among the things that can stop tracking. Self-hosting adds a layer you run yourself: WooCommerce documents that some web application firewalls flag the cookies behind its order attribution feature and return 403 Forbidden errors to visitors.

What does Safari add on either platform?

Safari's Intelligent Tracking Prevention deletes cookies created in JavaScript, and other script-writeable storage, after 7 days without interaction with the site, and caps them at 24 hours when the visit arrived through link decoration (WebKit documentation). A buyer who returns after a longer gap looks like a new visitor to any tag that depends on those cookies. That is reasoning from a documented rule, not a measured loss rate: none of the documentation cited here states a tracking-loss rate for either platform.

Which server-side options exist, and what do they leave out?

On Shopify, the data-sharing settings of the Facebook and Instagram channel include a Maximum option that turns on Meta's Conversions API, sending purchase events between Shopify's servers and Facebook's. Shopify's own explainer says that because the exchange is server to server, browser-based ad blockers can't block it, and that the setting also shares the buyer's name, email and phone number so Facebook can match ad interactions to buyers. On WooCommerce, the Meta for WooCommerce extension has the Conversions API built in and deduplicates it against the pixel with a unique event ID. Google's server-side tagging isn't tied to either platform: it processes data on a server you control instead of in the browser.

Server-side sends leave two things open. One is consent: the Maximum setting sends personal data, and moving a send from a pixel to a server doesn't answer the consent question that gates the pixel (reasoning, not a legal opinion). The other is the join: a purchase sent from your server still has to be matched to the visit that produced it. Google documents that Measurement Protocol events are joined to online interactions by client_id, and that the protocol is meant to augment tag-based collection, not replace it. Read plainly, the order gets counted, and its source is known only where the browser recorded the visit.

How do you measure the gap on your own store?

Pick one finished Monday-to-Sunday week and run these steps.

  1. Count the store's orders. Use the Orders export by date in Shopify, or the Orders report in WooCommerce Analytics. Decide once which statuses count (canceled, test, draft) and write the rule down.
  2. Count GA4 purchases for the same dates and time zone, with Transaction ID as the row and Ecommerce purchases as the value in an Exploration. GA4 deduplicates purchases that share a transaction ID, but only in web streams, and an empty transaction ID makes it treat all such purchases as one.
  3. Match the two lists by order ID. Orders missing from GA4 are the gap to explain. Transaction IDs in GA4 that match no order point at test orders, duplicates or an ID format mismatch.
  4. Group the missing orders by payment method, country and browser. A cluster on one off-site payment method points at the gateway return, a cluster in EEA countries at consent, a cluster on Safari at storage limits.
  5. Repeat after every change to the theme, a plugin, the consent banner or the checkout.

Pass: every missing order sits in a group you can name and test. Fail: a gap you can't group, or a ratio that moves when nothing changed on your side. The ratio of GA4 purchases to store orders is your baseline: a shift after a change is a measurement change, not a change in demand.

Sources, 30 September 2026: checkout_completed (Shopify, 2026); Pixel privacy (Shopify, 2026); About web pixels (Shopify, 2026); Conversion API: what it is and how it works (Shopify, 2026); Google Analytics for WooCommerce (WooCommerce, 2026); Order Attribution Tracking (WooCommerce, 2026); Facebook for WooCommerce (WooCommerce, 2026); Tracking Prevention in WebKit (WebKit, 2026); An introduction to server-side tagging (Google, 2026); Measurement Protocol overview (Google, 2026); Minimize duplicate key events with transaction IDs (Google, 2026); Data API schema (Google, 2026).

Frequently asked questions

  • Why do my GA4 purchases come in below my store orders?
    Purchases drop out of GA4 when the buyer never reaches the confirmation page, when consent isn't given, or when a blocker stops the tag. Match GA4 transaction IDs against your order list for one closed week, then group the missing orders by payment method, country and browser.
  • Does server-side tracking fix the gap on Shopify or WooCommerce?
    Partly. A server-side send such as Meta's Conversions API doesn't depend on the buyer's browser, so blockers can't stop it. Consent is still a question, and the order is tied to its source only where the browser recorded the visit. Measure the gap before and after any change.
  • Why does GA4 show more purchases than my store?
    Check three things: an empty or repeated transaction ID (GA4 deduplicates purchases only when they share an ID, and only in web streams), test orders counted in GA4, and different time zones on the two sides. List the GA4 transaction IDs that match no order.

Go deeper: Causal attribution, explained.

Sixty-second versions of these ideas: Causality Engine on YouTube Shorts.

Keep reading

Terms in this article

Browse the full glossary

Your platforms guess.
We run the math.

Upload a GA4 export and see what each channel caused, next to last-click, in 1–2 minutes. The read is yours to keep.

Free, in your browser: your file is not uploaded. The full read is €99, refundable within 30 days. Prices exclude VAT.
Or book a 30-min call.