How to Fix Inaccurate Shopify Conversion Tracking Caused by Third-Party Apps

 

We have seen a growing number of Shopify apps that overpromise and underperform when it comes to conversion tracking accuracy. Over the past year, while actively working on solutions based on Google Tag Manager and purely server-side tracking, we have identified a range of issues that often remain undetected, unexplained, and effectively a black box for Shopify merchants.

To solve this, we developed Anowave Conversion Tracking  (ACT): A zero-code solution designed to eliminate the tracking black box and automatically fix discrepancies across 9+ major advertising and analytics platforms.

 

Conversion Tracking Issues We Have Observed

Through our work with Shopify merchants, we have observed several recurring conversion tracking issues, including:

• [1] The black box problem: Uncertainty about how conversion data is collected, processed, and transmitted
• [2] Data Discrepancies: Discrepancies between Shopify order data and GA4 purchase data
• [3] Unassigned Traffic & Attribution: Unassigned traffic and conversion data that cannot be reliably attributed
• [4] Event Duplication: Duplicate transactions and purchase events
• [5] Visual Discrepancies: Differences between Shopify and Google Analytics 4 reporting
• [6] Missing conversions: Completely missing transactions & conversions
• [7] GDRP/Consent: Not sending or ignoring customer consent

 

1. The Black Box Problem: What Is Your Tracking App Actually Sending?

One of the less obvious problems with conversion tracking apps is the lack of visibility into the data being sent.

A merchant may see an add_to_cart event in Google Analytics 4 and assume everything is working correctly. But what was actually sent? Which product information was included? What value and currency were reported? Was a customer or session identifier available? Was consent granted? Which event ID was used? And was the event sent once or multiple times?

Without access to the underlying event data, these questions can be difficult to answer.

This is why we built complete event logging into Anowave Conversion Tracking (ACT). Instead of simply showing merchants that an event was detected, ACT exposes the actual event payload being processed and sent.

For example, a single event can show:

• Client and user identifiers
• Consent status
• Event name
• Transaction or event UUID
• Currency and conversion value
• Session ID and session number
• Engagement data
• Product and variant information
• Product price and quantity
• Product URL and brand
• Google-specific parameters
• Debug information

This level of visibility makes it possible to investigate tracking discrepancies instead of simply guessing what happened.

For example, if a merchant reports that GA4 shows a different number of purchases than Shopify, the question should not be limited to “Is the tracking app working?” A more useful question is: “What exactly did the tracking system receive, and what exactly did it send?”

With detailed event logging, the entire path can be inspected and potential problems such as missing parameters, incorrect values, duplicate events, consent-related restrictions, or incorrectly triggered events become much easier to identify.

In other words, conversion tracking should not have to be a black box.

 

 

2. Data Discrepancies

Discrepancies between Shopify order data and GA4 purchase data can occur when third-party apps interfere with, modify, or duplicate the purchase tracking process. Apps that implement their own tracking, inject scripts, modify checkout behavior, or send purchase events independently can cause GA4 to receive transactions that do not correspond exactly to Shopify orders. This can result in missing purchases, duplicate transactions, incorrect revenue, or differences in transaction IDs.

Another common issue is that multiple apps may attempt to track the same purchase using different methods, such as Shopify Web Pixels, Custom Pixels, app embeds, Google Tag Manager, or server-side APIs. Depending on how these implementations interact, a single Shopify order may be reported to GA4 more than once or not at all. Differences in attribution, consent status, event timing, and the order data available to each tracking method can further increase the discrepancy.

For reliable reporting, the purchase event should have a clear source of truth and use a consistent transaction ID and order value. Store owners should also check whether other installed apps are sending purchase events to GA4 and ensure that only the intended tracking implementation is responsible for reporting the transaction.

One of the issues we frequently encounter is that merchants have the native Google & YouTube app installed while also using a third-party app for additional tracking. This is not necessarily a problem by itself, but discrepancies can occur when the third-party app implements Shopify events differently from the Google & YouTube app. Google itself recommends taking care to avoid duplicate or conflicting implementations and notes that third-party tag management solutions may behave differently from the Google & YouTube app, particularly on checkout and post-checkout pages.

For example, product information in the GA4 items[] array can be represented differently by different tracking implementations. One implementation may use the Shopify product ID, another the variant ID, while another may use a combined identifier such as shopify_ZZ_<product_id>_<variant_id>. Although these values may all identify the same Shopify product or variant, GA4 treats different item_id values as different items. As a result, reports comparing product-level data between events or comparing data generated by different tracking implementations can show apparent discrepancies even when the underlying Shopify order is identical. GA4 requires a consistent item_id or item_name for item identification, but does not require a particular Shopify-specific ID format.

 

3. Unassigned Traffic & Attribution

One of the major challenges with conversion tracking on Shopify is that the accuracy and reliability of tracking can depend heavily on how a tracking app is implemented.

Shopify has significantly restricted what apps can execute directly on Checkout and Thank You pages. In practice, app developers can no longer simply inject arbitrary JavaScript into these pages and use it to capture purchase information.

Instead, Shopify provides an alternative mechanism called the Web Pixel. Apps can register a Web Pixel that Shopify executes in a controlled, sandboxed environment. The pixel can subscribe to events dispatched by Shopify such as product views, cart activity, checkout events, and purchases and use the information provided by those events for further processing and tracking.

This architecture provides Shopify with greater control over what third-party code can access and execute. However, it also introduces an important distinction between tracking implementations.

A conversion tracking app is not simply "tracking Shopify orders." It is relying on the events, data, identifiers, consent information, and execution environment made available through Shopify's Web Pixel APIs. What the app does with that information and how it combines Web Pixel tracking with other mechanisms can have a significant impact on the resulting data.

This is one reason why two conversion tracking apps can produce different results even when they are installed on the same Shopify store.

Understanding where an event originates, what information Shopify makes available, how the app processes it, and where it ultimately sends it is essential when evaluating conversion tracking accuracy.

 

Pros & Cons of sending data via Web App Pixel

Registering a Web Pixel through a Shopify app is relatively straightforward. Listening for events such as checkout_completed is also straightforward. The difficult part begins after the event has been detected.

Some tracking implementations assume that detecting a checkout_completed event and firing a purchase event to GA4 - or pushing the purchase data into a dataLayer - is enough. It isn't always.

The reason is that the Web Pixel operates in a sandboxed environment and does not necessarily have access to the complete browsing and attribution context that existed before the checkout.

Think of the Web Pixel as another train running alongside yours.

It can see your train. It may be able to see its paint, how many carriages it has, and some of the information written on them. In tracking terms, it can receive information about the event, products, value, currency, and other data Shopify makes available.

But it may not know where your train came from, where it is going, or how it got onto the track in the first place.

This is what we can describe as attribution detachment.

The tracking system knows that an event occurred:

A purchase happened.

But that does not necessarily mean it knows the complete context behind that purchase:

• Which session generated it?
• Which visitor was responsible for it?
• Which advertising click or campaign brought the visitor to the store?
• Which attribution identifiers were available before checkout?
• Can the purchase be reliably connected to the original marketing interaction?

This distinction is critical.

A tracking app can successfully receive checkout_completed and successfully send a purchase event to GA4, while the resulting conversion can still be unassigned, incorrectly attributed, or disconnected from the original acquisition source.

In other words, event tracking and attribution tracking are not the same thing.

Knowing that a conversion happened is only one part of conversion tracking. Knowing who converted, how they arrived, and which marketing interaction should receive credit is the much harder part.

Properly implemented apps use a combination of a Web Pixel and an App Embed Script to bridge this gap and pass attribution data to the Web Pixel. Make sure the app you choose uses both, as this helps ensure that attribution data is correctly sent to the selected advertising platforms.

 

 

4. Event Duplication

Event Duplication means that the same ecommerce event is sent multiple times to a tracking platform. Advertising and analytics platforms have mechanisms for identifying duplicate events, but the exact rules vary by platform. For example, GA4 uses the transaction_id parameter to help prevent duplicate purchase events, while advertising platforms may use an event identifier together with other event properties to deduplicate browser and server-side events.

Even a well-designed tracking app cannot guarantee that an event will be deduplicated if multiple apps or tracking implementations are involved. A purchase, for example, may be sent through a client-side pixel, a server-side Conversion API (CAPI) request, Google Tag Manager, another tracking app, or the native Shopify/Google integration. If two implementations send what is logically the same event but use different identifiers, the receiving platform may not recognize them as duplicates.

Things to watch for when testing conversion tracking apps

Are they adding an event identifier to each event?
Each event should have a stable identifier that can be used to identify that particular occurrence of the event. Shopify's Customer Events API provides an id for each customer event, described by Shopify as the ID of the customer event. When an app forwards the same Shopify event to multiple destinations or through multiple channels, we strongly recommend preserving this identifier where the destination platform supports it.

Are they using a combination of client-side and server-side tracking?
Using both client-side and server-side tracking can provide better coverage because different channels have access to different information. However, when both channels report the same event, they must provide a consistent deduplication identifier supported by the destination platform. Otherwise, the platform may treat the browser and server requests as two separate conversions.

Are they preserving Shopify's event ID?
When an app receives an event from Shopify's Customer Events API, preserving the Shopify-generated event ID can help maintain a consistent identity for that event as it moves through the tracking pipeline. This is particularly useful when the same event is sent both client-side and server-side. However, the Shopify event ID should not be treated as a universal deduplication key: each advertising or analytics platform has its own requirements. For example, GA4's purchase deduplication relies on transaction_id, so an app must also use the appropriate destination-specific identifier.

 

 

5. Visual Discrepancies

Transaction ID Visibility: This is not directly related to conversion tracking accuracy, but it can be very important from a merchant's perspective. Most conversion tracking apps use Shopify's internal numeric order ID as the transaction_id. However, when merchants look at the Shopify Orders page, they typically see the order name, such as #1001, rather than the internal numeric ID.

This creates a visual discrepancy that can make troubleshooting and verification unnecessarily difficult. A merchant may see a transaction in GA4 or another analytics platform with a numeric transaction_id and have no obvious way to determine which Shopify order it corresponds to. Ideally, a tracking app should provide the option to use either Shopify's numeric order ID or the customer-facing order name, such as #1001, as the transaction_id. This makes it significantly easier to trace a conversion back to the corresponding Shopify order.

 

6. Missing Conversions

There are edge cases where conversions can be completely missed. For example, Web Pixels may not fire when consent is not granted, meaning the entire conversion tracking request is never generated.

Another possibility affects server-side apps that rely on webhooks to send conversion events. Webhooks are not guaranteed to arrive immediately or even at all. They can sometimes be delayed by several hours, and in rare cases may never arrive. When this happens, the conversion event can be missed completely.

 

Conversion tracking isn't a single request. It's a chain:

One particularly important distinction in conversion tracking is the difference between a missing transaction and a missing conversion. These are not necessarily the same problem. A Shopify order can be successfully created and paid for while the conversion tracking process fails at a completely different stage.

App never receives event → transaction missing

App receives event → attribution missing → conversion can't be attributed

App receives event → destination API rejects it → conversion missing from advertising platform

Event generation → event delivery → app processing → attribution enrichment → destination API → destination acceptance

A failure at any point can result in a conversion not appearing where you expect it.

No app can realistically guarantee a 100% failure-proof system or 100% conversion-tracking accuracy. If an app makes such a claim, it should be treated with caution and independently monitored.

The goal is not to collect 100% of events - this is simply not possible given browser restrictions, consent requirements, network failures, webhook delays, API errors, and other factors outside the app's control. The goal of a proper conversion-tracking solution should instead be to recover and capture as much data as possible, using multiple mechanisms and fallback strategies. The more reliable the data collection, the more useful the resulting data is for ad networks to optimize campaigns and for marketers to make informed decisions.

 

Ad-Blockers & ITP (Intelligent Tracking Prevention)

This has become one of the major challenges in conversion tracking in recent years. Modern browsers are increasingly implementing native tracking protections that can identify known advertising and analytics networks and block or restrict requests to them. As a result, conversion events may never reach the intended platform, even when the tracking implementation itself is technically correct. In some environments, this can contribute to a significant amount of missing conversion data potentially reaching 30% or more depending on the browser, user settings, and tracking setup.

The problem is particularly relevant on iOS, where Apple's Safari browser and its privacy protections impose additional restrictions on cross-site tracking, cookies, storage, and requests to known tracking domains. This means that simply firing a browser-side pixel or sending an event to an advertising platform is not enough to guarantee delivery.

A robust conversion tracking setup should therefore not rely exclusively on client-side browser requests. Server-side tracking, first-party infrastructure, proper event deduplication, and a combination of browser and server signals can help reduce the amount of data lost to browser-level tracking protection. However, no implementation can completely bypass a user's privacy settings or guarantee 100% event delivery.

 

 

7. GDRP Compliance

Consent is an important part of Shopify conversion tracking, particularly for merchants operating in the EU and other jurisdictions with privacy requirements. A tracking app should not simply collect and send customer data without considering the consent state provided by Shopify and the merchant's configured consent solution. Ignoring consent can create both compliance risks and inaccurate tracking.

A common issue is that some tracking implementations treat every checkout or purchase as trackable, regardless of whether the customer has granted the required consent. Others may fail to pass the consent state to the advertising or analytics platform, leaving the destination platform unable to distinguish between consented and non-consented data. This can result in either inappropriate data collection or unreliable conversion signals.

A properly designed tracking solution should therefore make consent part of the tracking pipeline. It should respect the customer's consent choices, pass relevant consent signals to supported platforms, and use appropriate fallback or modeling mechanisms where available. The objective is not simply to track more events, but to collect and process conversion data in a way that respects privacy requirements while preserving as much useful measurement data as possible.

 

 

Summary: Stop Guessing, Start Tracking Accurately

Conversion tracking doesn't have to be a black box or a constant maintenance headache.

With Anowave Conversion Tracking (ACT), you get high-quality server-side tracking, enriched first-party data, transparent payload logging, and automated deduplication across 9+ ad networks - set up in under 5 minutes without touching code.