Missing Google Analytics transactions? Here are 10 reasons why!
Missing Google Analytics transactions are on my top list of frequently asked questions via the support forum or email. If you are running an e-commerce store and tracking orders using Google Analytics, most probably you encountered the problem: you see a purchase on your admin backend but you do not see this in your Google Analytics reports. And this is usually not related to the webshop system you are using: WooCommerce store owners face this issue maybe daily just as Magento users or even Shopify store owners. But why is that? Is this a bug? A “feature”? Something you need to live with or something that can be fixed? Let’s get through some explanations and possible fixes. First, let’s go through two reasons around the technology being used:…
Missing Google Analytics transactions are on my top list of frequently asked questions via the support forum or email. If you are running an e-commerce store and tracking orders using Google Analytics, most probably you encountered the problem: you see a purchase on your admin backend but you do not see this in your Google Analytics reports. And this is usually not related to the webshop system you are using: WooCommerce store owners face this issue maybe daily just as Magento users or even Shopify store owners.
But why is that? Is this a bug? A “feature”? Something you need to live with or something that can be fixed? Let’s get through some explanations and possible fixes.
First, let’s go through two reasons around the technology being used:
#1 Your payment gateway does not send the user back to the thank you page
This is one of the most common reasons for not tracking transactions in Google Analytics especially if you are using Google Tag Manager to deploy your measurement.
Some 3rd party payment gateways give the users the option to visit their wallet or other parts of the website without the need to go back to the merchant. Although your webshop will be notified about the successful payment in the background, not forcing the user to go back to the thank you page can be an issue if we are talking about tracking: the Measurement Protocol that I will explain below in more detail can be a solution here as well: when the webshop gets notified about the payment, some plugins can also execute their own codes that can include a server side Google Analytics tracking as well.
Google Tag Manager is however different: it is a purely browser based solution, there is no option (currently) to trigger tags within your container from your server. The user has to visit your order thank you page with the browser used while checking out. Without this, the corresponding tags within your Google Tag Manager container will not fire, your Google Analytics tracking will not be executed and you will miss the transaction in your GA reports.
Most 3rd party payment gateways offer an option that will redirect your customer back to the order thank you page after a payment. You should check this and enable where possible.
#2 Some orders are coming from your mobile app
This could be trivial but let’s just add this to the list: if your webshop also has a mobile app where users can place an order, you should definitely check whether this app has Google Analytics ecommerce tracking as well. If not, you may see the order on your webshop admin but it will be missing from your Google Analytics reports for sure.
If you are using WordPress (and maybe WooCommerce), there can be some additional reasons which can also apply to other e-commerce systems in a similar manner:
#3 A WooCommerce extension alters your default order received page
WooCommerce by default does not include any Google Analytics tracking. You need to use a plugin to achieve this. Most plugins rely on some hooks and functions on the order received page that WooCommerce executes by default. There are some WooCommerce plugins however that alter this order received page allowing you to select a custom-made page instead of the default page. This is shiny and useful in most cases but some plugins do not execute the same hooks and codes on those custom order received pages, preventing other plugins to see that the user just placed an order.
Obviously, you should either avoid using such plugins or contact the plugin author to update the plugin so that it mimics all elements and behavior of the default order received page.
#4 Your Analytics / Tag Manager plugin does not support your ecommerce plugin
Although many native Google Analytics plugins support WooCommerce for example, some of them only put the necessary ecommerce tracking code into the webshop if you purchase the paid version. Some Google Tag Manager plugins does not support any ecommerce plugin at all (not mine of course 🙂 ). If you are using other ecommerce plugins than WooCommerce, you will see that many GA/GTM plugins are not yet capable of tracking ecommerce purchases. You should carefully choose your ecommerce platform and of course your plugin to track the choosen ecommerce platform 🙂
In some cases, you miss a transaction from your GA reports because of user intent:
#5 The user has opted out from Google Analytics tracking
A less known browser extension is the Google Analytics opt out add-on. A link to this page is sometimes put into the privacy policy page of websites to offer users a way to opt out from being tracked. But it is also quite easy to find this extension as most related searches in Google will show this add-on in the first position. Technically this adds some JavaScript code into every website the user visits which will instruct the Google Analytics tracking code not to track the user. This also means that GA will not drop any cookie nor will send any data to its servers.
This kind of blocking can be easily detected thus you may override it programmatically but I would not recommend doing so. Respecting the intent of your user should be more important than seeing the purchase in your Google Analytics reports even if you will not be able to completely evaluate your marketing campaigns.
(If you really want to get your tracking back, you or your programmer should read how this kind of blocking works. It shouldn’t be a problem to re-enable data collection. But again: this is against your user and should not be used)
#6 The user is using an ad blocker or any other privacy related browser extension
A better-known fact is that most popular ad blockers usually also block Google Analytics tracking. That means that if your visitor is blocking ads, you usually do not know much about these visitors. Usually really nothing, not even the fact that this user visited your website/webshop. There are other browser extensions that allows users to take control of websites and website tracking. The main purpose of those browser add-ons are to improve security which also includes the ability to disable Google Analytics or other kind of tracking.
This kind of opt out is a decision of your visitor too therefore overriding this and tracking those users is a no-go decision for you. Some plugins and extensions of popular e-commerce systems gives owners the ability to use a method called server-side tracking. This means that no tracking code is added to you website thus nothing can be disabled or blocked. Instead, the so called Measurement Protocol of Google Analytics is being used to send data to GA while your page loads. The data is being collected and sent in the background, on your server and not in the browser of your user. This also means that some data might be missing this way (like screen size) but many other – and important – data will be available in your reports regardless of what blocking the user is using.
But again: this is against the wish of your user and therefore should be avoided.
Now let’s go through some more technical reasons than can explain a missing Google Analytics transaction regardless of the used e-commerce system:
#7 A script in the page prevents tracking to work on your order thank you page
Most websites nowadays use several scripts to improve user experience and deliver dynamics to your webpage. Scripts and programs can sometimes fail even next to extensive testing. This is because it is nearly impossible to test every website in every browser with every possible options and extensions on every internet connection. Some combinations fail.
A failing module on your “thank you” page of your webshop can start a domino effect, preventing other scripts from executing. This can include tracking codes of Google Tag Manager and Google Analytics. It is very hard to detect such cases as on your computer and in testing environments everything works fine. But there can be one solution to detect and report such errors: JavaScript Error Tracking.
You may ask your programmer to catch any error on your site, check if Google Analytics was loaded and send error details into Google Analytics. This will include the exact error message, the filename and line number within this file where the error occurred. Why will this be useful? Because Google Analytics collects lots of other important technical data next to the error message: browser, browser version, device info, operating system info, screen resolution, etc. This is gold for any developer and can help detecting and fixing unexpected errors. JavaScript error tracking can also improve the performance of other website elements like your category pages or your cart page. I plan to write more about this technique in a separate article later.
#8 The Analytics / Tag Manager tracking code has some errors
This is very similar to the previous reasons but in this case your Google Tag Manager / Google Analytics codes include issues.
For example, in JavaScript you need to surround any text data with a ‘ or ” character. If your product names include such a character and your programmer (or the Google Tag Manager / Analytics plugin author) did not prepared the code to handle this, it can happen that the browsers sees the ‘ or ” in your product name as the “end of text data” character, breaking code execution because it can not handle the characters after the ‘ or ” sign in your product name.
"Cool Product with 4" display"
From the browsers perspective, the text in blue will not be threatened as part of the product name but it can not be evaluated as a command either bringing the browser into an unexpected state where it has to abort the current operation: for example, tracking your purchase data.
There are two reasons related to the limitations of Google Analytics tracking:
#9 Too many products are included in one transaction
This one applies if you are using the so called enhanced ecommerce tracking of Google Analytics. This is the next generation of ecommerce tracking within GA, it has lots of possibilities if you are using this with Google Tag Manager (which I would like to explain in a separate article too).
Now let’s learn something (probably) new: the definition of hit payload.
Think about all the data Google Analytics collects while your page loads. Even if you are not using ecommerce tracking, by just putting the default tracking code into your website, you will see many-many data about your user in your reports: sources, maybe keywords, data about screen size, page title, etc. Now imagine a quite large order on your webshop with either lots of products or with fewer products but with very long product names. Add to this to the data being tracked by default.
Now think of a black paper where you start writing every collected data next to each other. You also write short names next to all data so that you know what numbers and texts belong to certain dimensions. After you’ve written all collected data to this sheet, this will be your so called hit payload, the data being sent to Google while your page loads. If this includes product names, brand names, product category names (with lots of category levels), this can be quite long can’t it be?
Google Analytics will however drop this payload and not send to Google’s servers if the size (length) of this payload grows over 8kB. That is 8192 byte which is usually 8192 characters except for some non-latin (or non-latin1) languages where more than one byte is needed to identify a single character. On a thank you page with lots of products in the order this can be achieved quickly.
But what can you do in such cases?
- Google Analytics allows you to import product data like product names, brand names, category names using a CSV upload or with a programmatic way. Here you send within the hit payload only the SKUs of your products and join other product data on the Google Analytics UI using CSV upload for example. Google Analytics will look at your uploaded CSV product data while processing the incoming purchase data with your SKUs and if it finds the ordered products within this CSV, it will populate ecommerce reports using the data found in your uploaded CSV
- You or your programmer may hook into the flow of Google Analytics data collection and divide all hit payload into smaller parts. A great solution can be found in this article by LunaMetrics.
#10 Too many interactions has been tracked in one session
Another limitation of Google Analytics tracking is that it allows you to send “only” 500 hits per session. A hit is usually a pageload but a click on your product on your category page or on the add to cart button will be also a hit if you track them as those events should be tracked. Now imagine a user that really tries to find the proper products. It searches for lots of products, puts them into the cart and when this user finally reaches your order thank you page, this will be interaction#501 in this session. And in this case, Google drops the hit that includes the purchase data.
Websites with higher pages / session metrics can be affected by this limitation but a lower pages / session next to lots of event tracking can prevent proper tracking too.
Summary
As you can see there can be several reasons for any missing transaction in your Google Analytics reports. You should always respect user privacy at first and then try to fix other possible reasons.100% accuracy and parity can be usually not achieved but you can sometimes improve the ratio of tracked purchases. Accepting this is usually the better choice as to try to track everything and everybody regardless of the choice of your user.
Nice One!
It’s funny thought, that duplicate transactions are just as usual as the above mentioned data discrepancies, so a lot of times the ecommerce tracking is screwed in all directions without a carefull setup.
Cheers,
Transactions are de-duplicated on the transaction level, thus if you send in the same transaction ID with the exactly same transaction content (revenue, item details, etc) – it should not count twice in your reports
After the payment is completed, the service will redirect me to the site back, but the transactions are not included in the analysis.
What should I do if the “Thanks” page was created by us?
If you are using a custom thankyou page, you will need to ensure that some background code tells my plugin and other plugins that this is your order received page. You can do this my hooking into the woocommerce_is_order_received_page filter and return true on your custom page:
https://docs.woocommerce.com/wc-apidocs/source-function-is_order_received_page.html#191-199
Tell me, how is it easier to implement?
Are you managing this custom thankyou page by yourself with your own codes or you are using a plugin for that?
Do it yourself. Maybe you will recommend a suitable plug-in?
In that case you should create a new function in your PHP files and use the add_filter() WordPress function to hook into the woocommerce_is_order_received_page filter. You need to check whether the user is on your own thankyou page. This could be done using the is_page() WordPress function using the post ID of your thankyou page.
You will also need to ensure that the order key is present in the URL of the custom thankyou page like on the default page.
Rules of thumb: you need to exactly mimic the background behavior of the default order received page.
Thank you for your reply. However, I do not have enough skills to do this without the developer’s participation. Maybe there is a solution without the participation of a programmer?
Unfortunately this can not be solved without a programmer.
I plan to review a custom thankyou page plugin this weekend, it might work with my plugin as well. I will let you know if the test worked
Hey, did you end up finding a plugin? I have a custom thank you page as well and I am having the same problem! I have added the woocommerce_is_order_received_page filter but the URL of my thank you page does not append any order ID.
Yes, this seems to work perfectly with my plugin as well: https://wordpress.org/plugins/woo-thank-you-page-nextmove-lite/