March 7, 2023

Debugging Incorrect & Missing Google Analytics 4 Transactions

Updated: March 7th, 2023

The main goal of digital analytics is to measure the success of an organization and 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.

Businesses must be able to measure transactions/ purchases with analytics tools correctly. However, doing so can become tricky when dealing with web tracking tools like Google Analytics. Missing or incorrect transactions are more common than we would expect.

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

I’ve split this article into two large sections:

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

Here’s what you will learn in this article

 

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.

The best way about this situation is not to consider Google Analytics an accounting system with 100% precision. Instead, think of it as a platform that shows you data trends so that you can make data-informed decisions.

If you miss several transactions in the backend system, that isn’t good. The customer will likely not get their services/products, etc.

The end of the world isn’t upon us just because you miss some transactions in Google Analytics. GA can still help you identify various factors, like the highest-converting traffic sources, best-performing products, etc.

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

With the current digital analytics changes, we receive lesser 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 Google Analytics, but it messes up the attribution), privacy regulations, etc.

Of course, you can use tools like Tracedock that help businesses mitigate various blockers and still capture visitor data on your website. But on the other hand, if someone has explicitly blocked your tracking, that’s a preference we should respect.

From my latest experience, I’d say you’re lucky if you have less than 5% of missing transactions in GA. However, 10% is an amazing number to hit.

And that number will continue to drop even lower in the future.

And if your business is affected by a regulation like GDPR, then even 50% of data loss is normal (because half of your visitors might not consent to analytics tracking). That’s the reality we’re getting.

 

And if you’re thinking, “But I can send all transactions via Measurement protocol or server-side tagging and have 100% accuracy“, I think this approach is not as good as you might think.

There’s a fairly high chance that you will be missing acquisition data and other events in the session (like where users click, etc.), unless, of course, you build some very custom solution and handle a lot of edge cases in the backend (but the question is does the benefit really covers the high costs of implementation).

Plus, the GA4 measurement protocol now lets you send data only to existing (already tracked) user sessions. So if something on your website blocks GA tracking, you won’t be able to “attach” your purchase event (sent from MP) to a GA4 session.

Another option is to combine client-side tracking with server tracking. But this method will require a lot of effort from your team, and you would still need to get consent from every EU visitor/user, and I’m sure you will not have a 100% success rate here either.

In this case, a better approach would be aiming to get pretty accurate data rather than pursue a perfect 100% score.

Remember, improving accuracy from 60% to 85% (or 90%) is much easier than changing from 90% to the perfect 100%.

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

You can fix the issues if your inaccuracy is a byproduct of technical glitches. But 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 troubleshooting and fixing missing transactions in Google Analytics, it’s essential to set the right expectations beforehand. Achieving 100% transaction accuracy is impossible, and you must educate the stakeholders about this.

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

  • If you’re dealing with European traffic, expect users to refrain from giving consent to track their website activity. Result: you will lose some data
  • Some users could use Brave browser (that blocks all trackers by default) or strict privacy settings in other browsers. Result: you will lose some data.
  • You should also expect users to use 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, it becomes difficult to explain why your tracking setup misses X% of transactions.

Suppose this conversation about inaccuracy happens around the end of the project (not before it). In that case, your reputation might suffer, and people might think 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 explain why your Google Analytics reports miss transactions (or maybe it collects incorrect data). The list also includes various uncontrollable reasons and issues you or your developers cannot fix.

 

#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, try a solution like this or this.

 

#2. Browsers with strict privacy settings

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

Some visitors could prefer to configure their browsers to block trackers (including Google Analytics) strictly or may have switched to Brave, a browser 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 4.

I could not find recent statistics, but it looks like there is ~1% of users have Javascript disabled (this varies by region). So the impact of this should not be significant (but a theoretical possibility remains).

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

However, my experience is that many current online checkout pages/steps heavily rely on JS and will not even process the transaction properly if JavaScript is disabled.

 

#4. A visitor did not opt-in to analytics tracking

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 significant chance of getting 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 not properly 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:

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

Data Layer must be formatted just as Google requires in its documentation. So, the Data Layer should include the data structure, the names of attributes, the format of values, etc.

For example, here’s the example from the E-commerce documentation that contains a sample dataLayer.push code:

Although you won’t need to use all of these parameters, you must NOT COMPROMISE the naming convention and structure/format as displayed in the example.

Another example is monetary values. You must pass the values precisely as in the documentation. Adding a currency sign before the number (e.g. $12.00) is invalid.

All in all, keep an eye on the following:

  • Format (e.g., is a value is a string (a.k.a. text) and surrounded by quotation marks, keep it that way)
  • Incorrect quotation marks: Don’t use rich-text editing tools like Word or Google Docs to edit code. They can automatically change the quotation marks and make your code invalid. For example, transactionI_id:′123456′ may convert 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 necessary and which are optional.
  • Incorrect prices. For example, do not use a currency sign (e.g., $13.00).

Another possible problem is that the ecommerce data appears in the Data Layer after you send the data to Google Analytics. For example, let’s say you fire your GA4 Purchase event tag on DOM Ready, but the actual transaction data is pushed to DL a bit later.

If so, you are not sending transactions to Google Analytics. Solution: delay your transaction tag and fire on that custom event.

Take a look at the screenshot above. Create a custom event trigger and enter the name purchase (as displayed on the left side of the Preview and Debug mode), and that’s it. Then, save the trigger, and replace your current trigger in the GA4 Transaction tag with this new custom event trigger.

 

#6. The purchase-related data layer does not activate on a “Thank you” page

Consequences: missing transactions in Google Analytics.

When the purchase is complete (and if you are using GTM + GA4 to track transactions), it’s necessary to push the purchase-related information to the Data Layer. But if the user gets redirected to a “Thank you” page, that’s where you must activate the dataLayer.push.

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 has passed to the Data Layer after completing the purchase. Also, double and triple-check whether the format and values are correct.

Suppose you’re not working with GTM but have a hardcoded GA4 tracking implementation. Then, the hardcoded tracking code must also send the purchase data. Use browser extensions such as Tag Assistant to verify if this is the case.

 

#7. 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 enormous. However, you can implement JavaScript error tracking in Google Tag Manager. Also, ask developers to log JavaScript errors happening on checkout or “thank you” page views.

That might give you and them some ideas about what needs fixing.

 

#8. You did not publish the 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 transaction tracking via GTM, remember to publish the container. Otherwise, you will see several test transactions in GA reports, but the rest of the data will be missing.

 

#9. Tracking codes are activated right before the redirect

Consequences: missing transaction data in Google Analytics.

Let’s say a visitor makes a purchase, a tracking code is activated, and then almost immediately, they are redirected to another page.

The sudden redirection can cause issues as sometimes your tracking code will not have enough time to properly send the request to Google Analytics.

Even though Google Analytics 4 is using sendBeacon API by default (to increase the chances of sending data right before the redirect), it is still not 100% reliable (actually, it’s fairly unreliable).

Your best option is to ask a developer to push transaction data to the data layer (or activate the tracking code) AFTER the visitor is redirected to another page (e.g., Thank you page).

 

#10. Issues with currency

Consequences: incorrect transaction data in Google Analytics.

In GA4, you must send a currency parameter with a purchase. Otherwise, purchase data will not be displayed in the reports. This is a common mistake among those who migrated from GA3 to GA4.

Also, here are several other possible mistakes you must avoid:

  • Instead of passing the currency code as a currency parameter, 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, if the user completed the purchase in Canadian dollars (30 dollars), but the Data Layer did not capture the currency in the request. Google Analytics will then treat 30.00 Canadian dollars as 30.00 US dollars.

 

#11. Internal traffic is not excluded

Consequences: incorrect transaction data in Google Analytics.

If you do not exclude your coworkers’ traffic from Google Analytics (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 colleagues to identify those purchases.

Here are several ideas on how to do that (but don’t limit yourself to those ideas):

  • All call center employees should enter a coupon code to identify their team made that particular sale.
  • If call center employees purchase with their account, maybe a developer could push a parameter user_type (with value call_center_employee) to the Data Layer, and you could use that as a custom dimension in GA.

 

#12. The tracking code is activated even if the transaction is unsuccessful

Consequences: incorrect transaction data in Google Analytics.

Remember: GA should only track successful transactions. For all other transactions, treat it as a separate event.

A rule of thumb: Test your developer’s setup of the tracking codes thoroughly.

Through thorough testing, you must test successful purchases and non-sensical actions to break the setup. For example, suppose you are redirected to the payment provider page, cancel everything, and see what happens next. Where are you redirected? Was the tracking code fired?

 

#13. 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. You must give the additional time needed for GA to process your sales. Usually, it takes 24-48 hours for the data to be processed.

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

 

Part 2: Troubleshooting incorrect or missing Google Analytics 4 transactions

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

 

#1. Thoroughly test 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, do your best to test it. Here are some general tips on how to do that:

  • Check what happens in the GTM preview and debug mode (if you use GTM in your stack). If you make a purchase, check the following:
    • Whether the Data Layer receives all the data points you requested.
    • Check whether the data structure is just how Google requires
    • Check whether quotation marks are correct
    • Check whether the data format is correct (e.g., quantity must be an integer, product ID must be a string (text), etc.)
  • Use plugins such as GTM/GA Debug, GA Debugger to check whether the Data Layer sent the request data correctly. For example, double-check whether Google Analytics received the correct values for all three products if you purchased three products. This is tedious but necessary work.
  • When you get the desired result in Google Tag Manager’s preview mode, confirm that it is being sent to Google Analytics. For this, head over to Admin > DebugView and perform the same actions again. It will appear within a few seconds of completing the action if implemented properly. You should read this guide to learn more about DebugView.
  • Finally, wait a while and then check that data’s final destination, Google Analytics ecommerce reports. Go to Reports > Monetization > Ecommerce purchases and check the data there.

 

#2. Comparing backend data with GA

A minimum requirement for troubleshooting is seeing the data of at least 50 transactions. For example, if you run a low-volume online store/website, you’ll need to choose a period that contains more transactions. If you can check more than 50, do so.

Your sample size must be tangible. For example, if you have three transactions and are panicking because 33% is missing, you must calm down and wait a little longer.

 

2.1. Get the transaction data from the backend

Ask your developer or client to provide a spreadsheet with the transaction data. The key to success here is to ask for 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 status
  • User ID/GA client ID (if you store such information in the database)
  • Date and time when that transaction occurred

This list is not final, so if you think something else is valuable, go ahead and ask for it.

 

2.2. Get the list of transactions from Google Analytics

In GA4, the way to do this is by creating a new exploration report. Use Transaction IDs as rows and Purchase revenue as values. Additionally, you could add Date as columns to see which transactions happened on which dates.

You can create an exploration report by heading to Explore > Choosing a blank template.

To find the list of transaction IDs, Click on the plus icon located next to the Dimensions option. The complete list of metrics that you can use inside GA4 reporting will open here. Search for Transaction ID and import it into the table.

Let’s add another perimeter to the report – event count. Head to the plus icon near the Metrics option, search for Event Count in the search, and import it into the table.

Now, drag the Transaction ID option to the Rows section and the Event Count option into the box inside the Values section.

You’ll see a list of transactions captured by Google Analytics. Select a date range that you’re interested in (to increase sample size). If you plan to check 1000 transactions, then select to show 1000.

We are going to export that list. The number of transactions exported will depend on how many you display. You must have at least 50 transactions, but if possible, more is better.

Then at the top right corner of the screen, click the Export data option in the top right.

And select Google Sheets.

Follow Google’s instructions, and you will have a list of all transactions displayed in that Google Analytics report. Then, rename the sheet to GA4 transactions.

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

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

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 captured just by Google Analytics (but not in the backend’s list) and transactions not captured by GA (but 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 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 GA4”.

Your transactions list should start from the 2nd row. In B2 cell (of the 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 the comma on your keyboard, go to the GA4 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 will take the value of the A2 cell (containing a transaction ID from the Backend transactions sheet) and check the entire column A of the GA transactions sheet.

The formula will return the actual transaction ID if it finds the exact value, and if not, it will return #N/A.

You can see that Google Analytics does not capture every transaction that returns an #N/A value. Mark such rows with red (manually or in a more clever way).

Double-click the corner of the cell containing the VLOOKUP formula, which will repeat for the rest of the transactions. Mark all missing transactions (that return #N/A) as red.

Next step: Apply the same principle in the GA4 transactions sheet and check which transactions are captured by Google Analytics and not in the Backend transactions list. I will not show how to do that because the principle is the same as in the 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 find why certain transactions are missing.

Things like ad blockers or strict browsers will stir things up, but if you have technical issues in your setup, you may notice clues in your Google sheets.

The more attributes you 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 happens quite often that GA4 does not track transactions using a particular payment method. For example, credit card payments are followed correctly, while all Paypal payments are 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 where GA did not track all orders containing free products (samples that visitors could order).
  • 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 that coupon code means. Dig deeper, and you’ll find your answer.

But why did we check whether some list items from the GA4 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 were not supposed to appear in Google Analytics (but unfortunately, they did). And that’s another task for developers to fix.

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

 

#3. Check how many visitors are blocking your tracking

To understand the scope of ad blockers, you can implement this solution (together with developers) or this to identify the percentage of your traffic blocking GA tracking. That might explain the transaction discrepancy between Google Analytics and your backend system.

 

#4. Keep the timezones in mind

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

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

 

#5. Check the browser/device for missing transactions

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

There may be a bug in tracking that occurs only for specific browser versions. To fix this, you’ll need to cooperate closely with developers here.

 

#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, create an exploration report with the User ID as the row.

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

If Google Analytics did not track such a user, they probably blocked your tracking. However, you must ensure the User ID feature is configured correctly in Google Analytics.

But if you find a user with a matching ID in Google Analytics, click and see the other interactions it tracked.

  • Were there other interactions GA tracked on the day of the noted transaction? If not, maybe that visitor started blocking your tracking at some point.
  • But if you find that visitor was browsing your website and started checkout, but Google Analytics did not track the transaction, then most likely, there is some technical issue.

 

#7. Track errors as GA events.

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

#1. JavaScript error tracking may help you identify uncaught errors. This will allow you to catch errors not seen/handled by any block of code on your website.

#2. You could ask a developer to push other errors: The developer could push errors to the Data Layer, like,

  • bad responses from payment providers
  • handled/caught errors

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

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

Attribute names error_category or error_description are arbitrary and you can choose any other naming convention.

With the help of Custom Event Trigger and Data Layer Variable, you can 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?

Using the User ID feature in Google Analytics, you can open the user’s profile (in User Explorer) and see whether GA4 tracked an error during the checkout/purchase.

From my experience, it was common to see a visitor complete all the checkout steps, and GA tracked them but not the final transaction. By implementing error tracking, I started seeing cases where all checkout steps were followed by an error (instead of a transaction). This is despite the transaction being tracked properly in the backend.

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

 

#8. 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 suspect that your transaction tags are not firing at the right time, you could implement a tag monitoring solution. This will then check whether the tag fires after a successfully completed transaction
  • 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 4 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 an impossible mission due to the growing popularity of ad blockers and privacy-focused browsers (or their configurations).

So my advice here would be to do your best to identify and fix technical issues causing data inaccuracies. But if visitors have explicitly shown 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.

You should never forget that these platforms’ data accuracy will worsen over time.

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 find a pattern of why you are missing transactions. What are the common characteristics of that missing data? Maybe the missing transactions used the same payment method? Or perhaps purchases for a particular product category are missing?.
  • If necessary, implement additional tracking to get more data to help you identify possible issues, e.g., error tracking.

If you notice anything crucial 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.

 

Julius Fedorovicius
In Google Analytics Tips Google Tag Manager Tips
8 COMMENTS
Bartek

Wow, very very nice :)

Yoan Yahemdi

Hi Julius,

Great article.

Little not, it is possible to get 100% via Measurement Protocol and having all hits + traffic source information.

You need to get and stock the clientID of the user before he gets to payment platform.

Then realizing a POST from server to GA with the clientID.
GA will automatically attribute the transaction to the last session of the clientID.

Kind regards,
Yoan.

    Julius

    Yes, I know that. I made a remark about that in the post, saying, that you can combine client side tracking with a backend tracking.

    But here's a more realistic scenario:
    User lands on a page with privacy browser extension. GA is blocked. No client ID is set, therefore, a bunch of transactions will still have (direct) traffic.

Brad

I have run into this issue many times. The one thing I would add is that if you can get it in on the same day, you are FAR better off. Otherwise if it is a large order or test order or something, it will forever plague your reporting.

Isaac

What an awesome article Julius, really in depth. I love the solution for tracking payload size as a custom dimension, genius.

Liz

Hi Julius! Im seeing this funny behavior where a single transaction shows a total of let’s say …$100. Yet, GA only shows one product purchased within the transaction for let’s say …$50.

It would seem that my tagging is only picking up one product’s data. Thoughts?

Roberto

Amazing Content! This is the best content about this topic I ever read!

Leave a comment

Your email address will not be published. Required fields are marked *