Missing or Incorrect Transactions in Google Analytics? The Complete Guide

One of the most common problems in e-commerce websites is that the sales data in Google Analytics doesn’t always reflect the correct numbers in the back-end e-commerce platform (Shopify, Magento, etc.). Sometimes these deviations are negligible and shouldn’t bother anyone too much – 1 or 2 transactions out of 100 – but sometimes the numbers are insane.

In this article, I’ll walk you through the entire process of checking what went wrong from start to finish. Keep in mind that it could take five minutes, or even two months, and might involve some work.
Even though we have hundreds of these projects under our belts, not all of them have a fairytale ending.

Before we begin:

• It doesn’t matter which e-commerce platform you’re using – Magento, Woocommerce, Shopify, or whatever. For simplicity’s sake, I’ll just write back-end.
• Google Analytics will always get the short end of the stick. You can’t have a transaction registered in Google Analytics but not show up in your back-end unless your programmer is high.
• “I use (ready-made plugin, Shopify, close-ended platform), so there’s no need to check.” Cool. Still, run the check, and sooner rather than later.

Step One: Check Existing Transactions

Before I rush off to check what’s missing and why, I always run a check on what I do have –the transactions that were registered to Google Analytics.
Sadly, a lot of companies and site owners don’t run this check, which is a real shame. As far as they’re concerned, if it’s there – it must be true. So what do you need to do?

• Log in to Google Analytics.
• Open your Sales Performance Report under the Conversions->e-commerce section. It shows the list of transactions.
• Click the date range display and choose one specific single date, preferably a recent one. The report is sorted by Revenue. We don’t care about that right now. Click Transaction ID to sort entries by their numbers.
• At the bottom of the table, you can choose the number of lines to display. Select the maximum number so you can see all the transactions that occurred on that day.
• It should look something like this:

The first column lists transaction IDs. These numbers should match those in your back-end, and are usually consecutive.
In the picture above, the transaction ending in 33 is missing. And that should probably be looked into – but not right now. Remember, at this point, we’re looking at what we do have, not what we don’t.

You’ll notice that at the bottom of the chart, the number of lines you have is indicated. That’s the number of transactions Google Analytics captured that day. Compare it to the real number in your back-end, and you’ll get an idea of the number of transactions that are missing.
You can take one or two lost transactions out of 100, but nothing more – and you would still check those two.

What do we have so far? We’ve learned how many transactions were ‘dropped out.’

Now look at several random transactions from the report and compare them with the numbers in your back-end. Particularly Revenue, Shipping, and Quantity, which represents the number of items per transaction.

If the numbers don’t match, that’s probably true for all of the transactions, not just one, and the cause is usually improper e-commerce implementation, and that’s for a developer to solve. But before we go there, we have to understand the problem a little better.

What do we have so far? We’ve made sure that transaction-level data is correct.

Step Two: Diving Deeper Into Specific Transactions

Click on a specific transaction to have Google Analytics show you the items purchased – product name, SKU, price, and quantity.

If you can’t see the SKU (like in the image above), Open the “Secondary Dimension” drop-down ad choose Product SKU. In my image, you can see that this pecific transaction includes 6 unique items. Each of them has a different quantity and revenue. Compare these numbers to your backend.

If nothing makes sense, hand it over to your developer. These are the most common scenarios:

• Certain products are registered with the price 0.
• No matter what or how many items the customer bought, the quantity for each item will always be 1.
• All prices for all items are the same.
• No matter how many items the customer bought, you only see up to [X] number of items.
• Whatever the case may be, check the item SKU and names, and make sure they match the backend.
• What are the results? We’ve checked item data for a specific transaction and confirmed that the item name and SKU are valid.

To sum up, the purpose of the first two steps was to make sure that what you have in Google Analytics is 100% correct on the transaction level and that the items in the transaction match. Every scenario I brought up can easily be detected and fixed by your developer.

Step Three: Checking the Timestamp

This is the best part that most people don’t know about.

• Pick a specific day on your backend and export the transaction list to excel.
• Go to Google Analytics for that same day and check the report from Step one, looking at the list of transactions.
• Highlight every transaction that appears in the backend but doesn’t appear in Google Analytics.
• Go back to Google Analytics, but this time, change the date range to include five days, with the problematic day fixed in the middle. So if we’re looking at July 10, the Analytics report should cover July 8-12.
• Search for the missing transactions again.

What are we looking for?

Sometimes transactions are registered in Google Analytics on the wrong date. It could be a day later, a day earlier, or maybe longer. So they’re not missing, but why does it happen?

• The server clock doesn’t match the time set in your Google Analytics ‘View Settings’. A transaction that was made at 11 PM on Sunday could be registered for 1 AM, Monday. Make sure that the server clock and Google Analytics clock match.
• Google Analytics end glitches. Not too critical. As long as the transaction was correctly recorded, it could handle a one-day shift.

If you made it this far and fixed everything that needed fixing, it means that the transactions that do appear in Google Analytics are correct. Now you need to move on to the more complicated end of things: the real missing transactions.

Step Four: Locating Missing Transactions

It’s money time, and the biggest question is, why in the world do some transactions fail to appear in Google Analytics?
Your excel sheet with the exported data should already have the transactions missing from Google Analytics highlighted. The more information you have, the more chances you have of finding the cause.
So the first and most important thing to do is to look for something that all of the dropped transactions share. What I mean is, a quality that only the missing transactions share, and that the correct ones don’t.

So if, for example, all of the missing transactions were paid for using an AMEX card, we have to check if any AMEX transactions made it to Google Analytics. If there are, then that’s not the problem.
Again – look for something that’s not only shared by all of the other transactions, but is also unique to them. For example:

• All transactions were made through PayPal or another specific provider, or a particular credit card
• Coupon code was used
• They all offered free/paid shipping
• They all included a specific item (a gift added at checkout, etc.)
• All of them took place around the same time (at night, or between 8-9, whatever)
• All of them had revenues of over [X]
• All of them were for more than [X] items (this is a very common issue)

Each of these issues (except for the last one) is an excellent issue to have. Why? Because they’re easy to diagnose, and the solution usually comprises a small code fix. It’s easy to show the developer where the issue occurred, and everything can be fixed and re-examined. All of this information is available in every back-end, no matter what platform you’re using.
The last reason I noted is special.

Transactions of More Than [X] Items

Google Analytics limits the volume of data that can be sent per event. The problem is even worse with supermarket websites, where every transaction can include dozens, if not hundreds of items, and for each one, there’re custom dimensions that were added.

How can you tell?

Data sent to Google Analytics in a single hit can’t exceed 8kb or approximately 8200 characters. That should be enough for several dozens of items at a basic level.
If you exceed that quota, you’ll see the message Payload size is too large on your browser’s DevTools console, along with the current weight of the hit. So you’ll know how much you’ll have to reduce it.

There are several ways to do that, but it’s far from trivial, and I really can’t cover it here. One solution, by the way, is to split the transaction into several smaller ones or use other tricks and maneuvers.

Oh, I almost forgot.
Even if you don’t have many items per transaction, but for some reason still cram a lot of data into a small – even 3-item – transaction, this is still a likely scenario.

Other Scenarios With No Information

Sometimes, we might miss the ‘thing’ that all dropped transactions share. Something the back end simply doesn’t know.
If, for instance, all of the dropped transactions come from say, an American IP, or mobile-only, or only from Firefox… this is where it gets complicated because none of these transactions appear in Google Analytics. So when it comes to information like country, screen resolution, device, browser, etc. – it’s just missing. And it doesn’t stop there.

Most backend platforms simply don’t collect this information. So a Firefox transaction might not register – but how can we fix that using our data, if it’s not collected by any platform?
There are two ways to look into that:

• Run a simple VPN test, or use different devices or browsers over and over again, and try to identify what all of these dropped transactions share; if any.
• Upgrade your back-end platform so that it collects technical data such as browser, IP address, device type, screen resolution, etc. for every transaction. It’s complicated. It’s not pretty, and it’s a tough job. But that’s what we have to work with.

More Scenarios!

If you’ve made it this far and are still missing e-commerce transactions, here are a few other reasons why:

• The user blocked Google Analytics, or cookies, or uses an ad blocker. This means that all of their transactions are registered in the back-end, but not by Google Analytics. There are different ways to find out.
• You collected too much data on each user and exceeded the data limit for a single session (500 hits). This happens when you use Google Analytics to collect junk-data, such as mouse clicks, scroll tracking, etc. There are other tools for that.
• You send transaction data while redirecting to the thank you page. Sometimes it just gets ‘dropped’ on the way. That’s hardly recommended, and you’re better off sending all of the information to Google from the thank you page instead of on the way there.
• Performance issues on the thank you page like when there’re too many scripts running and Google Analytics is on low priority for some reason, so the user ends up leaving the page before the script can run. To fix this, you need to clear all the junk from your thank you page and use Google Tag Manager to prioritize the scripts.
• A standard solution to these issues is to avoid sending the transaction from the thank you page, but rather from the server using a measurement protocol. The information you’ll get will be precise, but it comes with more disadvantages than advantages, so I’m only mentioning it as a low-priority solution.
• If you see duplicate transactions, it’s probably because the user reloaded the thank-you page, or access it later on. It happens because of a low standard coding. the thank-you page should be expired after several minutes and cannot be accessed again later (Thanks Mirkka Tajakka for sharing this common scenario)

And… that’s about it. Now bookmark this article and pull it out when the time come. You can add your own insights in the comments section below.