How to Fix Duplicate e-Commerce Transactions

Saurabh Kumar — November 10, 2018 Follow @ineptikus

— November 10, 2018

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 a unique 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.

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.

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.

One of the simplest ways is to set up a tag so that every time a user visits a confirmation page or thank-you page, a cookie is written out. Although it isn’t a bad approach, it wouldn’t provide a surety of whether the transaction was tracked by Google Analytics or not. Therefore, we would suggest deploying the “hitCallback” feature of Google’s Universal Analytics. This feature sets the cookies after Google Analytics successfully receives the data. To utilize this feature, in Google Tag Manager, set the value of hitCallback to “Tag to a Custom JavaScript Variable.” Now that JavaScript should return a function that does the following:

• 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.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
    • 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 changes

• • 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 which adds a timestamp when a new transaction confirmation page is served. With this, the next time such a page is called, the ecommerce tag is skipped.
  • Several web analytics software also complement their Web Analytics JS data with a backend feed. Transaction information can be sent using such a feed.

If you have read so far, I hope there has been something of use that you have found above. In case you have any questions or suggestions, or have another way of de-duplicating transactions in web analytics reports, please share them with me in the comments.

This article was first published by me here.

Digital & Social Articles on Business 2 Community

(112)