Fix Duplicate E-commerce Transactions in Google Analytics
Although Google Analytics is an amazing service that helps in tracking e-commerce, many times it counts a transaction more than once. These duplicate transactions are caused because there is the possibility of logging the same transaction more than once. Such issues are to be addressed manually because Google Analytics doesn’t try to fix this error but considers that transaction more than once. This error could lead to many problems such as seeing excessive number of transactions. It can also have an impact on e-commerce conversion rate, sales quantity, and revenue totals. In addition, it will show a higher average order value than it is in reality. All the issues will then lead to questioning the credibility of data, and with incorrect data, the probability of making bad decisions increases massively.
How to Prevent Duplicate Transaction?
Duplicate transactions can be prevented by one of the following methods:
A.Using Google Tab Manager (GTM)
As of now, Google Analytics doesn’t have a solution for differentiating repeat transactions, but the issue of duplicate transactions can be resolved by using appropriate codes.
- Catch the ongoing transaction ID from the Data Layer
- Verify the “transactions” cookie
- If it does not exist, then it has to be created with the ongoing transaction ID
- If it does exist, then verify the ongoing transaction ID, and if the ongoing transaction cannot be found, then add it.
Use only one cookie for all transactions that are joined using a pipe ( “|” ) symbol in order to avoid assigning a cookie to each transaction. Now, the ongoing transaction ID will be added to this newly created transaction cookie every time a transaction is sent to Google Analytics.
A first-party variable will also be required to grab this newly created transaction cookie in the following way:
- Observe that the first two lines of the code searches for a transaction ID because in this example Enhanced E-commerce feature is being used, which populates the transaction info from Data Layer. Also note that in the example, the other page views are not being dealt with. It only deals with the thank-you page and therefore one may have to tweak it to suit their needs.
- The next step would be to add a customJS variable to verify whether the ongoing transaction has been grabbed by the cookie. Then use that variable to create a blocking trigger for the tag.
- The rigger in the example has been named “Should I Track Transaction” for simple understanding of the functionality of the trigger.
- Now add this blocking rule to page view tag.
This tracking flow will now do the following:
- If the ongoing transaction ID exists in the tracking cookie, then “Should I Track Transaction”, will return “Block Transaction.” Page view tag firing will be blocked by “Block Transaction” if the above step is true. It will be fired if both the above statements return false.
- Once the transaction has been received by Google Analytics Endpoint, the hitCallback function will be executed after the page view tag is fired.
- The hitCallback will execute the function returned by the variable “transactionCallback”, which will be in charge of creating the cookie if it doesn’t exist and adding the ongoing transaction ID to it.
- Although it may not be functional in some cases because there are a number of different implementations, you will have to customize it to suit your requirement.
B. Using Server Side
Although GTM is an efficient way to handle such issues, if one has the time and energy to handle it, server side will reap better results. Some sort of server-side logic can be invoked to ensure that the e-commerce analytics code is sent only once to a particular page. One of the ways would be to use a database record to verify if e-commerce info has been sent. Another way could be deploying a server-side variable that could be checked in a similar fashion. Then there is the option where a user is redirected to a different page after the e-commerce information has been sent to Google Analytics and then not allowing the user to return to that page.
When Do Duplicate Transactions Occur?
Duplicate transactions can occur because of a myriad of reasons. The following are the most commons causes for a duplicate transaction:
- Whenever a user revisits an e-commerce website through an emailed or bookmarked link
- Whenever a user refreshes an e-commerce website
- When a user browses to a different website, and then returns to the e-commerce website using the back button
- When a user restores an e-commerce website from an incorrectly closed browser session or on a Smartphone
In a nutshell, such behavior by customers wherein they visit the same website multiple times is one of the major causes of duplicate transactions. Consequently, there will be a rise in the number of transactions because every time such websites are visited, they trigger an e-commerce script. The following examples can help to better understand that concept.
- A user visits a website. They liked some items and made a purchase. They will be able to see the inventory of purchased items on a confirmation page. Now once they have completed their transaction, those users often receive an email thanking them for their purchase and providing them a link to view their order. If that link again redirects to the same confirmation page, then Google Analytics will track those visits also as a transaction.
- A user bookmarks the confirmation page and views it again sometimes later. Google Analytics will again count this visit as a transaction.
Thus, using these methods, you can successfully de-duplicate identical transactions. And by fixing duplicate e-commerce transactions, which is the most common issue with e-commerce sites, you can prevent revenue from inflating and your attribution reports from being altered, thus protecting data integrity.