Where do the differences in data on conversions and transactions come from? 

An everyday occurrence in the life of a marketer/analyst: while running reports in Google Ads, you notice that the conversion/transaction data is dramatically different from what you can observe in GA4. When comparing with other marketing tools or (worse) the company’s CRM, you may find that each tool reports “in its own way”. What are the reasons for these differences in data? Which numbers are correct, and how do you not go crazy in such a mess? As data analysts, we are often faced with the problem of discrepancies in conversion and transaction figures. This article aims to explain the causes of these differences. It will focus on the differences between GA4, Google Ads and CRM, but most of the conclusions are universal to other tools. The order does not reflect the validity of each reason.  

Different reports in GA4 = differences in data    

Let’s start with a key problem. Even within one tool (Google Analytics 4), different reports show dramatically different numbers.   

For example, we’ll see a different number of users from Google Ads in the User Acquisition report (which tells us the number of NEW users a source/channel has brought to the site), another in the Traffic Acquisition report (which shows the number of sessions a source has brought) and another in the Ads tab (which shows event-level data).   

Finally, you will get different results in the explorations, which not only have a different collection period (maximum 14 months in the free version), but also take data from a different set, pre-aggregated to speed up report generation.   

To add to the confusion, we get different results depending on whether the data is downloaded via the API or in the BQ – where we can see the raw data. The differences between data in GA4 and BQ are well illustrated in the article HERE.  

While this all sounds extremely chaotic, it’s worth noting that everything described above is perfectly normal (if unintuitive).   

Different attribution models = differences in data    

The tools can use different attribution models, meaning that conversions can be attributed to different campaigns/marketing channels/advertisements or keywords.   

In GA4 we can choose between data-driven attribution and last-click model attribution in the settings.    

NOTE: Despite changing the settings, some reports will use different models, for example the User Acquisition report (simplified as First Click model) or the Traffic Acquisition report (simplified as Last Click model). We can change the attribution model in the administration. This change works retroactively, so we can choose a different model, see the historical data and then return to the previous settings.     

In Google Ads, counting conversions works differently. They work on the basis of impressions and clicks on ads. If a customer visits a page from an ad in Campaign A, then returns to a page in Campaign B, and finally converts by subscribing to a newsletter, Google Ads will attribute the conversion to:    

– Campaigns A and B (in the data-driven model, the proportions are assigned by the algorithms)   

– only to Campaign B in the Last Click model.     

Note that in Google Analytics, the same conversion will be attributed differently – depending on the attribution model, it will include email marketing campaigns.   

In the Google Ads system we have 2 possible settings for these conversions – data-driven and last click. It’s important to remember that they don’t work retroactively. If we change the settings, we have to wait for the data to be collected again.     

You can read more about attribution in Google Ads HERE. 

Differences in data vs. conversion assignment date   

GA4 attributes the conversion and transaction to the day it occurred. This is different with Google Ads, where the conversion is attributed to the day the ad was clicked. In other words, if a customer clicks on an ad on Monday and then returns on Wednesday from another source (e.g. organic results), the conversion will be attributed to Monday in Google Ads and to Wednesday in GA4.    

The sources will also be different – Ads will attribute conversions to a specific campaign that generated a click on Monday. In GA4, depending on the report, a conversion may be attributed to Google Ads (User Acquisition report), Google/Organic (Traffic Acquisition report) or partly to Google Ads and partly to SEO (Conversion report or some Exploration reports).      

In the store’s CRM/CMS, the transaction can be assigned completely differently. I have seen situations where it has been assigned: after acceptance by customer service, after receiving payment confirmation, immediately after submission to the system, after a change in the status of the transaction, etc. I don’t need to tell you how this affects the final result of the comparison.    

Conversion count settings   

In GA4 we can choose one of two methods for counting conversions. These settings allow us to track conversions once per event or once per session. For example, if our goal is for a user to go to the contact page, it’s worth counting 1 such event per session (in most cases it doesn’t matter if a user goes to a particular subpage 5 times during a session).    

It’s different in the case of e.g. sending a form/transaction – here we want to know about all forms sent or all transactions, so it’s better to choose the “once per event” option.    

The same settings can be found in Google Ads, just make sure that the settings for specific conversions are consistent in both tools. 

Technical aspects of measuring conversions    

When we count (either in GTM or via code) a given conversion can make a difference. Often a conversion is sent to Google Ads at a different time than it is sent to GA4. For example, a form submission conversion may be sent when the user clicks submit, when the form passes validation, or when the thank you page is displayed. Often even a seemingly small difference can result in a large divergence in data.  

Conversions can include specific actions as well as others, such as measuring conversions based on YouTube channel subscriptions (more HERE).  

In addition, different marketing systems may count additional actions as conversions, e.g. liking a post, sharing on FB, etc. In this case, we may see that the number of actions defined by us or additional activities in GA4 is different in the Conversions column.   

Data differences with different identity settings in GA4 

There’s one other setting worth noting that can affect the numbers and comparisons – identity for reporting purposes.  

Depending on whether we choose device-based, blended, or observed identities, Google will recognize users differently and it will also have a different approach to the topic of data modeling (i.e. based on artificial intelligence – adding data that was not collected due to lack of consents in our CMP tool).  

This setting works retroactively – we can check how identity changes affect the data and go back to the previous version. Each setting has its pros and cons, which you can read more about HERE.    

We also recommend that you create a file called “conditions for analysis”, which contains the settings you need to check before starting the analysis. This will ensure that those reporting have the same tool settings, which will affect the quality of the data.      

Consent mode vs. data differences 

The hottest words in analytics in 2024 are: modeled data and Consent Mode v2. The law requires site and store owners to collect consents for data processing. If a user doesn’t consent to tracking, GA4 can send anonymous pings to their sites to model that data using AI.   

Needless to say, modeled data can be our ally (they provide more data for other algorithms, which can use it to better understand potential users and show them more relevant ads). They can also increase the number of conversions/transactions in GA4. Unfortunately, we cannot check which transactions were modeled. We can partially work around this by switching identities for reporting and analyzing the differences.      

Data processing   

The counted data needs to be sent to the server and processed. This can take anywhere from a few to 48 hours (the GA4 360 version processes the data much faster). Unfortunately, we can’t see when the last synchronisation took place, or whether all the data has been processed correctly.     

As a result, when we run comparisons over the last 2 days, we may see discrepancies because some data is already processed and visible in the report and some is not. The solution to this problem is, of course, not to include the last 2 days of data in the analysis.    

Cross-market comparison   

For companies operating in multiple markets, the problem can also arise when comparing data between markets. Checking the data in CRM and Google Analytics may show that the discrepancies between markets are large. This is because we use the default Country dimension for such comparisons.    

Google recognizes user’s location based on their IP address and other signals indicating their location. In some cases, this location may not be accurate.    

The solution here is to pass the custom “market” parameter to the data layer, which allows you to be independent of how Google recognizes a user’s location and assign specific sessions and, subsequently, conversions to the appropriate market.    

Technology, browsers, and adblocks  

GA4 tags and Google Ads (but often other marketing tools as well) work based on codes injected into the page using Java Script. Technological considerations can cause problems in properly counting each user activity.    

For example, users using the Brave browser, or various types of adblockers, can block JS scripts, and in the case of some of them (adblock plus) also the entire GTM container. Of course, in such a situation, no data will be transferred to the tracking tools, while transactions/conversions can be properly sent to the CRM. In such a case, it’s a good idea to pass browser information to the CRM – so as to be able to compare it to GA4 data later.    

Payment gateways vs. differences in data 

 Users often do not return to the “thank you” page after paying, and some forms of payment take the user out of the domain – this can cause problems:     

• after returning from the gateway, the traffic will be attributed to a different source (e.g. a particular bank’s referral source 

• the transaction may not be properly recorded 

The solution may be to fire an additional event: purchase without payment, which is triggered before going to the payment gateway. Of course, this solution will give us information about the entire process, not the final transaction – we will often see a few percent more realizations of such a goal than will be completed.    

GTM settings and configuration errors   

A common error is a configuration error, such as deleting data that appeared in the data layer the day before, or blocking it during changes to the site, application or system. Another category of errors are changes to identifiers, classes, visible elements, html selectors – if we’ve based our implementation on them, it’s more likely to be affected by the page changes.      

The final sub-category is changes to the tools themselves: GA4 and GTM or other marketing tools. These may also cause some items to be counted incorrectly.     

Cyclical checking of the configuration, correctness of the data layer, testing of scenarios, triggers, variables in the GTM – this is the basis. Maintaining the implementation is one of the key elements for correct data counting and effective analysis.    

Summary 

Differences in conversion and transaction count data between analysis tools can be… a completely normal occurance. Often the differences are not due to configuration errors.    

To be consistent in your analysis, it is worth preparing:       

• Reporting assumptions – a document that shows which reports are key to evaluating certain situations. For example, we might state that we evaluate Google Ad campaigns based on conversions from the Google Ad Panel and the number of new users from the User Acquisition report. Writing down the settings for each tool/report will save us a lot of time explaining and checking the reasons for discrepancies.    

• Definitions of specific reports/metrics/dimensions – so that specific people know what they mean, as often “conversion” is a term meaning diametrically opposed things in different tools. A database of definitions is a useful tool for any data team.     

• The process of maintaining the implementation – we want to make sure that we check the implementation so that something that worked yesterday will still work tomorrow, and more importantly, so that we’ll know if it stops working. It’s useful to have implementation documentation – a description of how we’ve configured the tool. 

Another problem is finding configuration errors and where they occur. Often such a conundrum is like looking for the proverbial needle in a haystack – in my next article I will describe how to approach this problem and how to structure the search for that needle.