Uliana Lesiv
AuthorKey takeaways:
The first signal of data discrepancy (e.g., Google Analytics discrepancy) is a mismatch between your source of truth (e.g., Shopify, WordPress, backend) and your analytics tool (GA4).
In one Shopify + GA4 case of our client, a store captured about 95% of orders in GA4 compared to Shopify. In another client's case with WordPress setup, the data discrepancy reached ~30% missing purchase events in GA4.
So, the basic comparison of conversions recorded on different platforms has helped our client to spot a data discrepancy.
If you are a data tracking specialist, you must face the questions from product and marketing teams:
| Why is the number of conversions different in CRM, GA4, and Google Ads? |
If the difference isn't huge, you've probably answered: "Because platforms don’t measure performance the same way, and have different attribution models", and you could be right.
Each platform has its own logic for when a conversion is counted and how a session or user is counted. The platforms also have different attribution models (the logic, a platform decides who gets credit for a conversion).
If you set the same attribution model across platforms, you still can see the difference in conversions. It happens because platforms usually offer similar naming for models ("last click" or "data-driven"), but the way they calculate and attribute transactions differ under the hood:
Different platforms process and update data at different speeds, which can create temporary mismatches in your reports. For example, in GA4, you should always pay attention to whether your data is sampled or not. Analyze only unsampled data.
Some tools offer real-time or near-real-time reporting, but most web analytics platforms rely on processing pipelines that take time. This means that if you compare data too early, discrepancies are almost guaranteed.
So, when to check the data, so it isn't too early? If you’re analyzing data from yesterday, you’re often analyzing incomplete data. Use and analyze data that’s at least 2-3 days old.
Hidden data sources are usually transactions from physical stores. They can create data discrepancies that are easy to misinterpret if you’re only looking at frontend tracking.
The transactions that come from offline touchpoints are recorded in your backend system (CRM, CMS), but never pass through your website tracking if you don't have offline conversion tracking configured.
When some data comes from frontend tracking (browser) and some from backend/webhooks, you’re effectively combining different sources of data.
If you or your client has an offline store besides an online one, it can be a case. To start resolving data discrepancies, you need to configure webhooks that send data from your backend to GTM. There are numerous ways to do it; the easiest one is using Stape Conversion Tracking apps for CRM/CMS platforms.
Among the most popular platforms we support are Shopify, WordPress, HubSpot, HighLevel. We constantly add new apps; for the up-to-date list, please refer to the page with CRM/CMS apps.
Even with a technically correct setup, some share of your data can be lost due to ad blockers and browser restrictions. That was a case in multiple Stape clients - tracking worked perfectly in debugging mode, but still showed gaps in real reports.
In the case with WordPress and GA4, mentioned above, a similar pattern appeared: setup validated in debugging tools, but a portion of real user data never reached GA4.
Successful debugging does not guarantee complete data collection.
Website visitors rely on ad blockers and built-in tracking limitations (like Safari and Firefox have). Some use AI browsers, which in most cases have default configurations to block all the ads and tracking scripts. In such a case, GA4 scripts entirely prevent requests from being sent.
In the case of our client, suggested approaches that helped to reduce data discrepancy were the following:
It will be especially relevant if you target EU countries and/or some states in the USA, since they have adopted strict data privacy laws.
If users do not grant consent for tracking, analytics tools are either limited or completely blocked from collecting data. This impacts the number of users, sessions, and conversions you see in your reports.
Consent is tricky in general; here are some possible ways consent can impact your data collection:
We show in detail how to troubleshoot the problems with Stape Logs in the following paragraphs.
Event duplication is a common problem, especially for platforms like Meta. For example, when you configure Facebook Pixel and Facebook CAPI (as Meta suggests for efficient tracking).
Without setting up a shared event identifier (such as a transaction ID or event ID), platforms cannot recognize that these events represent the same action.
In the article below, we show how to troubleshoot and fix this problem.
Not every mismatch between analytics platforms is a problem. In fact, some level of data discrepancy is expected in any tracking setup.
It's nearly impossible to achieve 100% alignment between CRM/CMS systems and GA4 or ad platforms.
In most setups, a gap of around 10% is generally considered normal. But it will still depend on data quality (client-side or server-side tracking), tracking architecture, and whether you target the countries with data regulations, as we explained earlier.
A data discrepancy is usually totally fine if you can clearly trace its cause, for example:
In such cases, it is not a tracking error but a measurement limitation.
Analyzing logs is an effective strategy to figure out the cause of the problem. Analytics dashboards only show the result, not the process of data collection. When you see a data discrepancy (e.g., GA4 vs Shopify, or GA4 vs Meta), you can confirm that something is wrong, but you cannot tell where or why it broke just by looking at reports.
In this case, Stape Logs will be helpful. It is a feature in your Stape account that lets you monitor all incoming and outgoing requests in your server-side container.
| ❗Note: the feature is available for the Pro or higher plans only. |
The main limitation of many server-side setups is the lack of visibility into outgoing requests. While incoming requests are usually available, outgoing data often requires additional access or support, making it hard to diagnose issues like data discrepancies.
Stape solves this by providing both incoming and outgoing logs in one place (with consent required for outgoing logs due to potential PII). This gives a full view of your data flow and makes it much easier to identify where tracking issues occur.
In the collapse elements below, we show in detail how to troubleshoot the issue for the most popular causes of data discrepancies:
It can be a case if your target audience is from the EU, and you have Google Consent Mode (v2) enabled. In this case, you won’t see any errors in Stape Logs.
To be sure, that’s a case, do the following:
1. Check Incoming and Outgoing requests in Stape Logs. Filter them by conditions that work for the tracking issue you’ve detected. In our case, it is “purchase” in GA4.
2. Compare the number of purchase logs in the Incoming and Outgoing tabs. You may notice that the number of outgoing requests is lower.
3. If the difference in the number of events between two tabs is huge, so that it would be difficult to filter manually, click “Download as CSV”. Download both Incoming and Outgoing logs. Be sure that all the logs are loaded before downloading them - click “Load more” at the bottom of the page.
4. Extract from the URL “transaction_id”.
If you’re doing it manually, click on the arrow next to the request in column “More”. Find the “transaction_id” in the URL.
If you downloaded it as CSV, follow one of the options:
Add the URL from the Incoming and Outgoing CSV docs into one Google Sheets doc in different columns:
Extract the transaction_ids from both columns. We’ve used the following formula for Google Sheets to do it:
={"Transaction ID - Incoming"; MAP(E2:E, LAMBDA(row,
IF(ISBLANK(row), "",
IFERROR(REGEXEXTRACT(row, "transaction_id=([^&]+)"), ""))))}So you can see the IDs that are missing in the column “Outgoing”.
If you open the GA4 report and check the transaction IDs that were received in the specific period of time, you will also see that the IDs of incoming transactions aren’t listed on the dashboard.
To avoid manual work, you can use the GA4 MCP server. Just specify the query for it, list the transaction IDs from logs, and ask the AI bot to check whether these IDs were recorded by GA4.
The GA4 MCP server is compatible with any type of AI agent. If you would like to configure it, follow the instructions from our guide on the GA4 MCP server.
5. Check the GCS parameter for the transactions that are missing in Outgoing requests.
The GCS parameter indicates the consent status (accepted, rejected, or undefined).
The parameter value is stored in the request URL as well:
You can check it manually, using an AI agent, or using formulas in Google Sheets.
Here is the formula we’ve used:
={"GCS Value"; MAP(E2:E, G2:G, H2:H, LAMBDA(url, g_val, h_val,
IF(AND(LEN(TRIM(h_val))=0, LEN(TRIM(g_val))>0),
IFERROR(REGEXEXTRACT(url, "gcs=([^&]+)"), ""),
"")
))}
And the result we’ve got:
6. Check the value of the GCS parameter.
In our case, all GCS had a “G100” value, but your output may differ. Here are possible parameter values:
| Value | Meaning | Description |
| G100 | No consent | Both Ad Storage and Analytics Storage were denied. |
| G110 | Partial | Ad Storage was granted, but Analytics Storage was denied. |
| G101 | Partial | Ad Storage was denied, but Analytics Storage was granted. |
| G111 | Full consent | Both Ad Storage and Analytics Storage were granted. |
So, a logic question arises - if the consent wasn’t given or given partially, why is data still sent to GA4?
You likely see this request in logs because Google Consent Mode (v2) is enabled. When consent is denied, GA4 sends "pings" that do not use cookies. These pings are then used for basic measurement and conversion modeling. So, you won’t see them as conversions recorded, but they will be used by GA4 algorithms to model the data.
Shopify’s checkout runs in a sandboxed environment that does not automatically carry over user consent from the storefront. Without additional configurations, the consent is by default set to “denied”. So, everything that happened on the checkout page won’t be recorded.
To see whether it’s a case via Stape logs, do the following:
Check the orders in your Shopify account over a specific date.
Navigate to your Incoming logs, add the filters:
If you are using GA4, you may see some incoming requests. If you have another client configured, you’ll most likely see zero requests.
Check the request URL to see the consent status of the requests (if there are such). Look for the GCS parameter.
Here are possible parameter values:
| Value | Meaning | Description |
| G100 | No consent | Both Ad Storage and Analytics Storage were denied. |
| G110 | Partial | Ad Storage was granted, but Analytics Storage was denied. |
| G101 | Partial | Ad Storage was denied, but Analytics Storage was granted. |
| G111 | Full consent | Both Ad Storage and Analytics Storage were granted. |
If you see a value G100, then consent wasn’t granted (even if initially a person has provided consent), and the event wasn’t sent from your server GTM container to the platform.
To fix the problem and send the consent status on the checkout page, follow the steps:
Be sure not to check the box “Rely on Shopify Customer Privacy API consent states”.
2. Create a custom pixel within the Shopify account:
3. Check whether consent status is sent to the checkout page.
Some CMPs can transfer the user’s initial consent to the checkout page, while others cannot. In those cases, any events that occur on the checkout page will not be recorded, since consent is denied by default.
To check whether your CMP sends consent status, do the following:
If you see “false” or “denied” in Cookie Values, you need to push the value additionally using Consent Mode (Google + Microsoft tags) by Simo Ahava.
In Stape Logs, you can notice a discrepancy where the number of Outgoing requests exceeds Incoming requests. It is completely expected and not a cause for concern when:
When it is a problem:
To check it via Stape Logs, follow the steps below.
Scenario: You’ve noticed that the number of purchases from Meta Ads Manager is higher than in your CMS.
Navigate to Outgoing requests → use filters:
For easier troubleshooting, click “Download as CSV”. You can ask the AI agent to analyze the file by looking at the event_id and conclude whether they are duplicates.
Another way is using Google Sheets and doing the same task with formulas.
Firstly, extract the event_id from the Request URL. We’ve used the following formula to do it:
=ARRAYFORMULA(IF(H2:H="",, REGEXEXTRACT(H2:H, """event_id"":\s*""([^""]+)""")))=ARRAYFORMULA(IF(I2:I="",, IF(COUNTIF(I2:I, I2:I) > 1, "Duplicate", "Unique")))
To fix the problem, you will need to fix the tags configuration within GTM. We have a detailed guide on how to set up Facebook event deduplication in Google Tag Manager.
Data discrepancies are a normal part of working with analytics, not an exception. Even when your tracking is correctly implemented, differences between GA4, CRM, and other platforms will still appear due to different attribution models, data processing delays, consent restrictions, and incomplete visibility of the user journey. The goal is not to eliminate every mismatch, but to understand what is causing it.
In most cases, a small gap between systems is expected and acceptable as long as it can be explained. Data discrepancies won’t disappear, but the confusion about why data differs can. With Stape Logs, you can see exactly what’s happening behind every conversion. Start by checking your own data flow and finding where the gap really comes from!
Comments