Debugging Incorrect & Missing Google Analytics Transactions

The main goal of digital analytics is to measure the success of an organization, provide suggestions on how to improve and drive changes. The definition of success may vary depending on the type of business/organization.

Most often, success = revenue.

To properly measure revenue with analytics tools, businesses must track transactions/purchases and with web tracking tools like Google Analytics, this part can become tricky. Missing or incorrect transactions are more common than we want. And that’s what causes headaches to many digital analysts in the industry.

That’s why today, I decided to write this guide on why you might have incorrect or missing Google Analytics transactions, how to troubleshoot them and why you will (almost) never reach 100% accuracy in a tool like GA.

Although some tips are GA-specific, you will definitely find something useful here even if you’re working with a different setup.

I’ve split this article into two large sections:

1. Reasons why you have incorrect or missing Google Analytics transactions
2. How to troubleshoot (& possibly fix) such issues

Table of contents

+ Show table of contents +

• You’ll (almost) never reach 100%  and the death of <5% accuracy
• Setting the right expectations
• Part 1: Reasons why you have missing  (or incorrect) Google Analytics Transactions
  • #1. Adblockers and other privacy-related browser extensions
  • #2. Browsers with strict privacy settings
  • #3. JavaScript disabled in a browser
  • #4. A visitor did not opt-in in your cookie-consent banner
  • #5. The purchase-related data layer is incorrectly configured
  • #6. The purchase-related data layer is not activated on a “Thank you” page at all
  • #7. No mechanism is implemented to prevent duplicate transactions
  • #8. Too many products were purchased in a single transaction
  • #9. Errors in browsers might prevent tracking code from working
  • #10. Too many interactions are tracked in the same GA session
  • #11. You did not publish GTM container with Ecommerce tracking
  • #12. Tracking codes are activated right before the redirect
  • #13. Multi-currency tracking is not implemented properly
  • #14. Internal traffic is not excluded
  • #15. Tracking code is activated even if the transaction was unsuccessful
  • #16. Reminder: there is a delay in GA
• Part 2: Troubleshooting missing (or incorrect) Google Analytics transactions
  • #1. Test thoroughly before you launch the transaction tracking
  • #2. Comparing backend data with GA
    • 2.1. Get the transaction data from the backend
    • 2.2. Get the list of transactions from Google Analytics
    • 2.3. Compare transaction list (from the backend) with the list of captured transactions in GA
    • 2.4. Try to find patterns among missing transactions
  • #3. Check how many visitors are blocking your tracking
  • #4. Keep the timezones in mind
  • #5. Check the browser/device of missing transactions
  • #6. Know user IDs?
  • #7. Track errors as GA events
  • #8. Check if your GA requests are too large
  • #9. Identify duplicate transactions
  • #10. Logging tag execution and Data Layer
• Final words

You’ll (almost) never reach 100%  and the death of <5% accuracy

Before we dive deeper into the practical stuff, I wanted to emphasize that you should not blindly pursue the 100% accuracy between Google Analytics and your backend system that processes transactions.

Google Analytics is not meant to be an accounting system with 100% precision. It is meant to show trends so that you could make data-informed decisions.

If you miss several transactions in the backend system, that’s bad. The customer may not get his/her services/products, etc.

If you miss several transactions in Google Analytics, that is not the end of the world. You can still identify the highest-converting traffic sources, best-performing products, etc.

Speaking of those “several missing transactions”, what is an acceptable threshold of missing transactions? In some guides/videos, you might learn that it’s acceptable to have less than 5% of missing transactions (in other words, go for at least 95% accuracy). Sadly, I think those happy days of high accuracy are long gone.

With current changes in the digital analytics landscape, we will be missing more and more data about our website visitors. And even if we still manage to capture it, the accuracy will be poorer.

I’m talking about privacy-related initiatives: the growing popularity of Brave browser or privacy-related browser extensions, Intelligent Tracking Prevention – ITP (currently, it does not cause your transaction to go missing in GA but it messes up the attribution), GDPR, etc.

Of course, you can try to use tools like Tracedock that help businesses mitigate various blockers and still can capture visitors on your website. But on the other hand, if someone is specifically blocking your tracking, maybe that’s a preference that should be respected?

From my latest experience, I’d say that if you have less than 5% percent of missing transactions in GA, you’re lucky. 10% is still pretty good and I believe that in the future, that number will drop even lower.

I remember Simo Ahava mentioning in some conversation (couldn’t find a link to it, sorry), that he had a project where ~30% of transactions were missing because visitors/users were blocking trackers on a site.

That’s the reality we’re getting.

And if you’re thinking “But I can send all transactions via Measurement protocol and have 100% accuracy“, i think this approach is useless. What’s the point if you have every transaction captured via measurement protocol?

You will still be missing acquisition data and other hits in the session (like what was clicked, etc.). Sending transactions via Measurement protocol means that you will just have a bunch of purchases that all came from the (direct) source. And that isn’t very helpful.

Of course, you can combine client-side tracking with backend tracking, but that will require too much of your team’s effort + you would still need to get consent from every EU visitor/user and I’m pretty sure you will not have 100% success rate here either.

All in all, in this case, I think it’s better to get quite accurate data rather than pursue a perfect 100% score.

Remember, it’s much easier to improve accuracy from 60% to 85% (or 90%), than from 90% reach the perfect 100%.

P.S. When I’m talking about accuracy, I mean the ratio of captured vs missing transactions.

That in any way does not involve incorrect transaction data (like missing coupon code or incorrect order total). If you manage to capture a transaction, then its data (order attributes, list of products, their attributes, etc.) must be 100% accurate.

If your inaccuracy is a byproduct of technical glitches, then go ahead and fix the issues. If you have missing transactions due to explicit blocking from a visitor, maybe that’s how things are supposed to be.

Setting the right expectations

When it comes to troubleshooting and fixing missing transactions in Google Analytics, it’s very important to set the right expectations beforehand. You need to explain to your client, colleague, boss, etc., that reaching 100% transaction accuracy is next to impossible.

10% of missing transactions is still OK in the current context. Explain that over the last several years, the landscape of digital analytics changed drastically and they are far from being over.

• If you’re dealing with European traffic, people may not give consent to be tracked. Result: you will lose some data
• Some users might be using Brave browser (that blocks all trackers by default) or strict privacy settings in other browsers. Result: you will lose some data.
• Some users might be using privacy-enhancing browser extensions that block Google Analytics and Google Tag Manager. Result: you will lose data.

Education of a customer, stakeholder, colleague, boss, etc. is crucial, otherwise, you will find hard times explaining yourself why X% of transactions are missing. And if that conversation about inaccuracy is happening at the end of the project (not before it), your reputation might suffer and people might think that you are not competent enough (although the reality might be different).

—

Part 1:
Reasons why you have incorrect or missing Google Analytics Transactions

In this part, I will take a closer look at the reasons why your GA reports are missing some transactions (or maybe the data is incorrect). The list includes various uncontrollable reasons and also issues that can be totally fixed by you or your developers.

#1. Adblockers and other privacy-related browser extensions

Consequences: missing transactions (and other data) in Google Analytics.

Browser extensions such as Ghostery or Adblock with strict configuration can block first-party trackers like Google Analytics.

If you want to find out how many visitors are blocking your tracking efforts, you can try a solution like this.

#2. Browsers with strict privacy settings

Consequences: missing transactions (and other data) in Google Analytics.

Some of your visitors might prefer to configure their browsers to strictly block trackers (including Google Analytics) or may have switched to Brave, a browser that is focused on privacy and blocking various tracking tools by default.

#3. JavaScript disabled in a browser

Consequences: missing transactions (and other data) in Google Analytics.

I don’t have evidence to back this claim, but I think that this is a quite rare case when you have a missing transaction in GA due to the fact that a visitor has disabled JavaScript in his/her browser.

Anyway, Google Analytics and Google Tag Manager tracking codes are purely based on JS and if it is disabled, no tracking code will be activated, hence no data will be captured (unless you try to implement a workaround with image pixels).

However, I have a feeling that a lot of current online checkout pages/steps are heavily relying on JS and will not even properly process the transaction if JavaScript is disabled.

I haven’t found a single best source but it looks like the number of users online who have disabled JavaScript is probably around 1% of the entire traffic.

#4. A visitor did not opt-in in your cookie-consent banner

Consequences: missing transactions (and other data) in Google Analytics.

If your business (or your client’s business) has implemented a consent popup asking for consent to track a visitor, there is a large chance that you’ll get rejected.

Now, let’s move to reasons where you will have more control and will be able to solve the issue (at least in most cases).

#5. The purchase-related data layer is incorrectly configured

Consequences: incorrect data or missing transactions in Google Analytics.

If you have implemented GA ecommerce tracking via Google Tag Manager, you should know the main principle:

1. An ecommerce data is pushed to the Data Layer
2. You fire a tag (via GTM) that takes that data and transfers further to Google Analytics

It’s super crucial that Data Layer is formatted exactly how Google requires in its documentation. This includes the data structure, the names of attributes, the format of values, etc.

For example, here’s the example from the Standard Ecommerce documentation that contains a sample dataLayer.push code:

Although not all of these parameters are required it is absolutely NECESSARY to keep the naming convention and structure/format as it is displayed in the example, e.g. transactionId must be exactly included as it is. With the uppercase I. orderId, purchaseID and other variations are not accepted. It must be exactly transactionId.

Another example: monetary values. They must be passed exactly as you see in the documentation. A currency sign before the number (e.g. $12.00) is invalid.

All in all, keep an eye on:

• Format (e.g. is a value is a string (a.k.a. text) and is surrounded by quotation marks, keep it that way)
• Incorrect naming convention (don’t use your own names for parameters. Follow Google’s requirements for fields like transactionId, transactionProducts, etc.)
• Incorrect quotation marks. Don’t edit code with rich-text editing tools like Word or Google Docs. They might automatically change the quotation marks and make your code invalid. E.g. transactionId:’123456′ may be turned into transactions: „123456“ (which is incorrect)
• Not all required fields are used. Just keep an eye on Google Analytics and GTM documentation to learn which parameters are required and which ones are optional.
• Incorrect prices. For example, do not use a currency sign (e.g. $13.00).

Another possible problem is the fact that the transaction data appears in the Data Layer after you send the data to Google Analytics. Let’s say that you fire your GA Transaction tag (needed for the Standard Ecommerce) on DOM Ready but the actual transaction data is pushed to DL a bit later.

If that is the case, you are not sending transactions to GA. Solution: delay your transaction tag, fire on that custom event.

Take a look at the screenshot above. Create a custom event trigger and enter the name ‘transaction’ (because it is displayed on the left side of the Preview and Debug mode) and that’s it. Save the trigger, replace your current trigger in the GA Transaction tag with this new custom event trigger.

#6. The purchase-related data layer is not activated on a “Thank you” page at all

Consequences: missing transactions in Google Analytics.

When the purchase is successfully completed (and if you are using GTM + GA to track transactions), the purchase-related must be pushed to the Data Layer. If a user is redirected to a “Thank you” page, dataLayer.push must be activated there.

If you’re working with a single-page application, then the dataLayer.push must be activated when the success message is displayed.

Use the GTM Preview and Debug mode to check whether the purchase data is passed to the Data Layer after the purchase is complete. Also, double and triple-check whether the format and values are correct.

If you’re not working with GTM but have a hardcoded GA tracking implementation, the purchase data must be activated from the hardcoded tracking code. You can use browser extensions such as Tag Assistant to check.

#7. No mechanism is implemented to prevent duplicate transactions

Consequences: incorrect transaction data in Google Analytics.

When a visitor lands on a “thank you” page and the transaction data is pushed to the Data Layer (or is sent directly to GA via hardcoded snippet), refresh the page one more time.

Is the request with transaction data sent to GA one more time? If yes, you need to prevent that. Google Analytics is pretty weak when it comes to transaction deduplication, therefore, you need to implement the solution on your website’s end. Two options:

• Ask a developer to activate the tracking code (or dataLayer.push) only once per transaction
• Prevent duplicate transactions yourself (if you are using GTM)

#8. Too many products were purchased in a single transaction

Consequences: missing transaction data in Google Analytics.

The limit of a single request to Universal Analytics is 8192 bytes (8 kilobytes). If your visitors are purchasing a lot of products in a single purchase (or you are tracking a lot of additional data about the products (custom dimensions), you might hit the limit of maximum request size.

If you reach that limit, the request/transaction will not be sent to Google Analytics.

In order to find out whether you are close to limits, you can implement this solution. If you are indeed reaching and sometimes hitting the limit, here are several options for you:

• Automatically reduce the GA payload length if it exceeds 8 kb
• Split ecommerce transaction to multiple requests (applies to Enhanced Ecommerce only)

#9. Errors in browsers might prevent tracking code from working

Consequences: incorrect or missing transaction data in Google Analytics.

I cannot give more specifics here because the variety of possible errors is huge. However, you can definitely implement JavaScript error tracking in Google Tag Manager. Also, ask developers to log JavaScript errors that are happening on checkout or “thank you” page views.

That might give you and them some ideas about what could be fixed.

#10. Too many interactions are tracked in the same GA session

Consequences: missing transaction data in Google Analytics.

In Google Analytics, there are some data collection limits. One of them is 500 hits per session (this applies to both free and paid GA versions). If you are tracking A LOT of interactions, there is a chance that transactions will occur after 500 hits are processed in a single session of a visitor/user.

Such hits will not be processed by Google Analytics and you will lose that data that exceeds the limit.

It is quite difficult for us to count the number of hits in a single session (because GA processes hits server-side (and there are many things that can influence the session)) thus I don’t have a verified solution.

I have seen workarounds like this one but I haven’t tried them myself, therefore, I leave this for you to judge.

#11. You did not publish GTM container with Ecommerce tracking

Consequences: missing transaction data in Google Analytics.

This one is a rookie mistake but still very possible. If you implemented a transaction tracking via GTM, don’t forget to publish the container. Otherwise, you will just see several test transactions in GA reports but the rest of the data will be missing.

#12. Tracking codes are activated right before the redirect

Consequences: missing transaction data in Google Analytics.

Here is a scenario that’s possible. A visitor makes a purchase, a tracking code is activated, and then almost immediately the visitor/user is redirected to some other page.

This might cause issues that sometimes your tracking code will not have enough time to properly send the request to Google Analytics.

There are several solutions/options you can choose from:

• Ask a developer to push transaction data to the data layer (or activate the tracking code) AFTER the visitor is redirected to some other page (e.g. Thank you page). The best option.
• Add an additional field to your GA tag that sends the transaction data (if you’re using GTM) with the following configuration
  
  This setting allows the browser to complete the request even if the browser window closes or you navigate from the site.
• Ask a developer whether it’s possible to give an additional 1 or 2-second timeout before the redirect (to give more time for the tag to send the request). This option is my least favorite.

#13. Multi-currency tracking is not implemented properly

Consequences: incorrect transaction data in Google Analytics.

If your website/online store is handling sales in multiple currencies, you can implement the multi-currency tracking.  Together with the transaction, you need to pass the currency code and GA will convert the currency. Read this guide on how to do that properly.

Here are several possible mistakes:

• Instead of passing the currency code as a separate parameter or custom dimension (depends on the type of Ecommerce setup), developers pass the currency code or sign together with the monetary value, e.g. “30.00 USD” or “$30.00”.
  
• A developer sends the correct amount but in a different currency. For example, the order was made in Canadian dollars (30 dollars) but if the currency was not set in the request, Google Analytics will treat 30.00 Canadian dollars as 30.00 US dollars.

#14. Internal traffic is not excluded

Consequences: incorrect transaction data in Google Analytics.

If your coworkers’ traffic is not excluded from GA (especially test transactions), your transaction numbers will be incorrect. Here are some tips on how to exclude your internal traffic in GA.

If your business also owns a call-center that makes the purchases, you could cooperate with developers and other colleagues to identify those purchases. Here are several ideas on how to do that (but don’t limit yourself just to those ideas):

• All employees in the call center should enter a particular coupon code that will let you identify that a sale was made through a call center
• If call center employees are making a purchase via their account, maybe a developer could push a parameter “call center employee” to the Data Layer and you could use that as a custom dimension in GA?

#15. Tracking code is activated even if the transaction was unsuccessful

Consequences: incorrect transaction data in Google Analytics.

Remember: only successful transactions must be tracked in GA. If a transaction was unsuccessful, track it as a regular event, not as a transaction.

A rule of thumb: when a developer informs you that tracking codes were implemented properly you must test the setup thoroughly.

This means that you test not only successful purchases. You should also do some non-sensical actions trying to break the setup. For example, when you are redirected to the payment provider page, cancel everything, and see what happens next. Where are you redirected? Was the tracking code fired even after you canceled the transaction?

#16. Reminder: there is a delay in GA

Consequences: transaction data in Google Analytics does not appear in reports immediately.

Keep in mind that transaction data in Google Analytics is not real-time. This means that additional time is needed for GA to process your sales. Sometimes it is quick (like 15-30 minutes), sometimes it will take longer.

Officially, Google needs up to 24-48 hours. But usually, things happen much faster.

That’s it for part 1 of this guide. I tried to enter the most common issues but if you spotted that something’s missing, let me know in the comments and I’ll update the blog post.

Now, let’s move to the next big part – how to troubleshoot your incorrect and missing Google Analytics transactions?

Part 2:
Troubleshooting incorrect or missing Google Analytics transactions

#1. Test thoroughly before you launch the transaction tracking

The better you test your setup before the launch, the less time you will spend debugging later. Mindblowing, right?

If you are working on a new setup, try to give your best efforts to test it. Here are some general tips on how to do that:

1. Check what is happening in the GTM preview and debug mode (if you use GTM in your stack). If you make a purchase, check:
   1. Whether all data points you requested are passed to the Data Layer
   2. Check whether the structure of the data is exactly as Google requires
   3. Check whether quotation marks correct
   4. Check whether the data format is correct (e.g. quantity must be an integer, product ID must be a string (text), etc.)
2. Use plugins such as GTM/GA Debug, Google Tag Assistant, GA Debugger to check whether the request data was sent properly. For example, if you purchased 3 products, double-check whether all three products were sent to GA with correct values. This is tedious but necessary work.
3. Finally, wait for a little and then check the final destination of that data, Google Analytics ecommerce reports. Go to Conversions > Ecommerce and check the data there.

#2. Comparing backend data with GA

First of all, troubleshooting is done best when you are checking at least 50 transactions. If you run a low-volume online store/website, you’ll need to choose a longer period of time to pick more transactions. If you can check more than 50, do so.

Your sample size must be tangible. If you just have 3 transactions and are panicking because 33% is missing, you’ll need to calm down and wait for a little longer.

2.1. Get the transaction data from the backend

Ask your developer or your client to provide a spreadsheet with the transaction data. The key to success here is to ask as much additional information (about those transactions) as possible. You’re not looking just for transaction IDs. You need more.

That additional information might help you identify patterns causing incorrect or missing transactions in Google Analytics (I’ll explain them in a minute).

Here is the information you could ask for in that spreadsheet (but don’t limit yourself to it. If you can think of more, get more.):

• Transaction ID
• Purchased products (+ product information)
• Order total
• Order coupon code
• Product coupon codes
• Order notes
• Payment method (very important!)
• Order/payment status
• User ID/GA client ID (if such information is stored in the database)
• Date and time when that transaction occurred

This list is definitely not final. If you think that something else is valuable to you, go ahead and ask for it.

2.2. Get the list of transactions from Google Analytics

If you’re using Standard Ecommerce, go to Conversions > Ecommerce > Transactions (in Google Analytics).

If you are using Enhanced Ecommerce, go to Conversions > Ecommerce > Sales performance.

You’ll see a list of transactions that were captured by Google Analytics. Select a certain date range that you’re interested in (in order to increase sample size).

Select to show display more rows. If you plan to check 1000 transactions, then select to show 1000.

We are going to export that list. The more you display, the more transactions will be exported into a spreadsheet. You must have at least 50 transactions but if possible, more is better.

Then at the top right corner of the screen, click Export and choose Google Sheets.

Follow Google’s instructions and you will have a list of all transactions that were displayed in that Google Analytics report. Rename the sheet to GA transactions.

Remove the first several rows. Make sure that the first row contains the labels/titles of each column.

In that very same spreadsheet, create a new sheet called Backend transactions and paste all the transactions that you received from the backend of your ecommerce website.

End result: you have a spreadsheet with two sheets: GA transactions and Backend transactions. Your next step is to compare both sheets and find transactions that were captured just by GA (but are not in the backend’s list) and transactions that were not captured by GA (but are in the backend’s list).

2.3. Compare transaction list (from the backend) with the list of captured transactions in GA

There are many ways how to achieve this but we’ll stick with one.

Make sure that transaction IDs in both sheets are the first columns. In the Backend transactions sheet, insert a 2nd column (B) and call it “Tracked by GA”.

Your transactions list should start from the 2nd row.

In B2 cell (of Backend transactions sheet), start entering the following formula:

=VLOOKUP(

Then select the cell where the ID of the first transaction is placed (cell A2). Then press comma in your keyboard, and then go to the GA transactions sheet and select the entire column of transaction IDs (if IDs are in the first column, choose A:A).

Then enter a comma, enter “1” (without quotation marks), enter “false” (without quotation marks) and close parentheses. If you named the sheets exactly as I instructed, the final formula should look like this.

=VLOOKUP(A2,’GA transactions’!A:A,1,false)

It means that it will take the value of A2 cell (that contains a transaction ID from the Backend transactions sheet) and it will check the entire column A of the GA transactions sheet.

If it finds the exact value, the formula will return the actual transaction ID. If such ID does not exist in the GA transactions sheet, the formula will return #N/A.

Every transaction that returns an #N/A value is not captured by Google Analytics. Mark such row as red (manually or in a more clever way).

Double-click the corner of the cell that contains the VLOOKUP formula and it will be repeated for the rest of transactions. Mark all missing transactions (that return #N/A) as red.

Next step: Apply the same principle in the GA transactions sheet and check which transactions are captured by GA and are not in the list of Backend transactions. I will not show how to do that because the principle is the same as in the several chapters above.

2.4. Try to find patterns among missing transactions

Once you have identified missing transactions in both sheets, it’s time to play detective and try to find patterns why certain transactions are missing.

Things like ad blockers or strict browsers will stir things up but if you have some technical issues in your setup, there is a high chance that you might notice clues in your Google sheets.

The more attributes you’ll have in the Backend transactions sheet, the better chances you’ll have to identify the issue.

Here are several ideas of what you should be looking for:

• I always check payment methods. In my experience, it happened quite often that transactions using a certain payment method were not tracked. For example, credit card payments were tracked correctly while all Paypal payments were missing. If you notice this, notify developers and they’ll dig deeper.
• Check whether there are common products among missing transactions. I had a situation were all orders containing free products (samples that visitors could order) were not tracked by GA.
• Product categories are also worth checking. I had another situation where a business had two main product categories. Even though the checkout process visually looked similar for all products, it turned out that each product category’s checkout was using a different codebase and one of them didn’t have dataLayer.push codes implemented. I was not aware of that until I explicitly started digging deeper.
• Coupon codes. Maybe the majority of missing orders were using the same coupon code? If yes, ask your colleagues/client what does that coupon code mean. Dig deeper and you’ll find your answer.

But you might be wondering, why did we check whether some list items from the GA transactions sheet were missing in the Backend transactions sheet? Because you never know what you might find. I remember one case where I found a bunch of transactions tracked by GA that were not in the backend transactions list.

I asked my client to provide more information on those missing transactions. It turned out that all those transactions had status failed. They were not successful transactions and they were not supposed to appear in GA (but unfortunately, they did). And that’s another task for developers to fix.

This process may (and most likely) will require a lot of time. But you’ll get better at it eventually.

#3. Check how many visitors are blocking your tracking

In order to understand the scope of ad blockers, you can implement this solution (together with developers) to identify the percentage of your traffic that is blocking GA. That might explain the transaction discrepancy between GA and your backend system.

#4. Keep the timezones in mind

When you get the list of all transactions (with date and time), ask what timezone is used in that list/sheet. Now check what timezone is used in Google Analytics view you’re working on (by going to View settings).

Ideally, timezones should be identical. If not, calculate the time difference between GA data and backend data. When you are looking for missing transactions in both sheets, make sure that the timeframe is identical.

#5. Check the browser/device of missing transactions

If possible, ask your colleagues/clients to also provide browser/device category of all transactions you’re checking (if that information is available). Maybe you’ll notice that certain browsers or devices perform much worse in terms of accuracy.

Maybe there is a bug in tracking that occurs only for specific browser versions. You’ll need to cooperate with developers here quite closely.

#6. Know user IDs?

If you have implemented the User ID feature in Google Analytics, ask for user IDs in the Backend transactions list.

Once you have identified missing transactions, go to your User ID view (in Google Analytics) > Audience > User Explorer.

In the search field, enter the User ID of that missing transaction.

If no such user is tracked in GA, he/she is probably blocking your tracking. Obviously, you need to make sure that the User ID feature is properly configured in GA in the first place.

If on the other hand, you find a user with such ID in GA, click it and see what other interactions were tracked by Google Analytics.

• Were there other interactions that GA tracked on that day when the transaction was made? If not, maybe that visitor started blocking your tracking at some point.
• But if you find that visitor indeed was browsing your website, started checkout (this is visible if you have implemented Enhanced Ecommerce) but the transaction was not tracked, then most likely, there is some technical issue at.

#7. Track errors as GA events

Another thing that you could implement is error tracking in Google Analytics.

#1. JavaScript error tracking may help you identify uncaught errors. This means that you’ll catch errors that were not caught/handled by any block of code on your website.

#2. You could ask a developer to push other errors to the Data Layer that occur in the checkout, e.g.:

• bad responses from payment providers
• handled/caught errors

Here’s an example of the dataLayer.push (that should be activated by developer’s code):

<script>
window.dataLayer = window.dataLayer || [];
window.dataLayer.push({
 'event' : 'error',
 'errorCategory' : 'checkout error',
 'errorDescription' : 'some description about the error'
});
</script>

Attribute names errorCategory or errorDescription are arbitrary and you can choose any other naming convention.

With the help of Custom Event Trigger and Data Layer Variable, you’ll be able to catch this information in the Data Layer and send it further to Google Analytics. Here’s an example of the GA tag that will send that error.

Once you start tracking those errors, what’s next?

If you are using the User ID feature in Google Analytics, you will be able to open the user’s profile (in User Explorer) and see whether an error was tracked during the checkout/purchase.

From my experience, it was quite common to see a visitor complete all the checkout steps (and they were tracked by GA) but the final thing (transaction) was not captured. By implementing such error tracking I started seeing some cases where all the checkout steps were followed by an error (instead of a transaction), even though the transaction in the backend was tracked properly.

By identifying those errors, you will have a chance to increase the accuracy of your tracking. Most likely, developers will be the ones who’ll need to fix it.

#8. Check if your GA requests are too large

As I have mentioned before in this blog post, the maximum size of a request to Universal Analytics is 8kb. If it’s possible for visitors to purchase A LOT of products for the same time (and they actually do that), you might have a problem of missing too large transactions.

How do you know whether this problem exists in your case at all? You can implement this solution. Few important notes:

• After implementing this solution, you won’t see requests that exceeded the 8kb threshold (because if the request is too large, it is dropped).
• But if you see a lot of requests reaching the limit of 8192 bytes (8kb), then you are at risk.
• The best way to check whether your transactions are close to the limit is to open the transactions report and add a secondary dimension (which is a custom dimension “Payload length”). This custom dimension will appear in your reports ONLY if you implement the solution explained in this guide.
  

If you find out that you’re indeed at risk of missing Google Analytics transactions due to large requests, there are several options you can choose from:

• Reduce the number of additional parameters you’re tracking. Maybe you have a bunch of custom dimensions and some of them are not needed anymore?
• Split the same transaction into smaller transactions (works only with Enhanced Ecommerce)
• Automatically reduce payload by dropping parameters from the request. Keep in mind that as a result, you’ll lose some dimensions and your report data will not be consistent

#9. Identify duplicate transactions

Here is an easy way to identify whether you are tracking duplicate transactions in GA.

Go to Customizations > Custom reports. Create a new report.

Choose Transactions as a metric and Transaction ID as a dimension.

Save the report. You will see a list of all transactions that were tracked in a certain period of time. Click on the Transactions column (to sort it from largest to smallest value). If you see numbers larger than 1, you have a duplicate problem.

P.S. but keep in mind that if you implement splitting large transactions into multiple transactions solution, seeing numbers >1 is expected.

#10. Logging tag execution and Data Layer

Here’s some food for thought. Usually, it’s enough for me to use previously mentioned techniques to find issues but if you still struggle, consider the options below:

• If you have a suspicion that your transaction tags are not firing when they should, you could implement a tag monitoring solution (and then check whether the tag was fired when the transaction in the backend was captured)
• Another option – you can monitor your data layer and if something important is missing, you’ll get a slack notification.

Final words about missing Google Analytics transactions

It’s essential to have as precise transaction data in Google Analytics as possible. However, don’t be blinded trying to reach 100% accuracy. It has become a mission impossible due to the growing popularity of ad blockers and privacy-focused browsers (or their configurations).

Of course, you can reach 100% accuracy by sending transactions directly from your backend to Google Analytics (via Measurement Protocol) but that won’t be very useful (because you’ll still be missing all other hits + traffic source information).

So my advice here would be to do your best in order to identify and fix technical issues that are causing inaccuracy in your data. But if visitors have explicitly showed they don’t want to be tracked (by using privacy enhancements like browser extensions or Brave), let that be.

Remember, you should use Google Analytics to see and analyze data and identify trends but it should not be treated as the source of absolute truth. There will always be inaccuracies and having “good enough” data can still bring value to your business.

Your data accuracy is going to be even worse in the future so keep that in mind.

Speaking of troubleshooting and debugging missing Google Analytics transactions, here are some of the key takeaways:

• Thoroughly test your tracking implementation before it goes live
• After you launch it, compare your backend transaction data with Google Analytics transactions. Google Sheets or Excel will be your best friend.
• Identify missing/incorrect transactions and try to find a pattern why are you missing transactions. What are the common characteristics of that missing data? Maybe all missing transactions were paid by using the same payment method? Or maybe a certain product category was purchased? You’ll need to play detective here and find the murderer.
• If necessary, implement additional tracking to get more data that can help you identify possible issues, e.g., error tracking or custom dimension that shows the length of a Google Analytics payload.

If you notice anything crucial that is missing in this guide, I’m open to improvements and hearing how you deal with this headache. As always, the comments section is at your service.