An Atlantic BT eCommerce Mystery
It began with a typical upgrade. Then the data disappeared.
My marketing team at Atlantic BT had just set up Google’s Enhanced eCommerce for a client who had just upgraded to the latest version of Magento Enterprise (1.14.2). This process involves setting up a Google Tag Manager (GTM) account and creating a container, then defining all the tags and triggers needed to properly run Google’s Enhanced eCommerce tracking in Magento’s platform. By measuring this critical eCommerce data, we’d have insight to guide our client’s online strategy for the long term.
We’re experienced with Google Tag Manager and Magento, so it was easy to get Google Enhanced eCommerce up and running. After testing on the staging site and when we confirmed that all eCommerce data was recording accurately, we copied the GTM container to the live site. For the curious, the setup and testing was done in Chrome and tested in IE. At this point, we should have had everything we needed to record eCommerce data from web users.
But by the second day of live data recording, we noticed 30% lower revenue being reported in Google Analytics from the revenue reported in Magento. While a 1-2% difference could be explained by javascript or cookie blocks, 30% was a major issue. Without accurate revenue reporting, we wouldn’t be able to determine how well the eCommerce upgrade was performing—our ongoing eCommerce strategy for our client would be flying blind.
Searching for An Explanation with Google Tag Manager
To solve this mystery, we began looking for data anomalies that could explain the 30% difference. We found that eCommerce traffic from Firefox users converted to sales at 0.1% while the rest of the client’s site converted at almost 8%. At the same time, we learned there were sales orders in Magento that were completely missing from the sales orders in Google Analytics. Could all of these missing sales orders come from purchases in Firefox?
To find out, we first used Google Tag Manager’s debugger to make sure all tags were working properly on our test site with no traffic filters. In all browsers, including Firefox, we verified the tags were firing and values in the data layer were populating for product impressions, product detail views, add-to-carts, purchases, and other eCommerce metrics. However, while the tags were working properly, the test transactions from Firefox still weren’t appearing in Google Analytics. This was nothing short of bizarre—somehow our tags were gathering eCommerce data only to have the data from FireFox disappear before it could be recorded and analyzed.
To find an explanation, I turned to Atlantic BT’s team of veteran developers. Using each browser’s debugger, our developers explored what was happening when the eCommerce events were supposed to trigger the tags. They found when the gtm.dom event was called— specifically in the purchase confirmation step of the checkout—the data layer was dropped. So while the session data (like page view numbers) remained, all enhanced eCommerce data (transaction, revenue, product, etc) was no longer there.
Developing a Workaround
At this point, the whole team was scratching their heads. There was no obvious explanation for why the gtm.dom dropped the data layer before the eCommerce data could be recorded. Somewhere between the Google code and the Firefox javascript, the data just got lost. After all the time spent on this issue, we now needed to choose between continuing to investigate or creating a workaround.
We decided to put curiosity aside and focus on a workaround. While the gtm.dom is a standard event for Google Tag Manager, it was not the only event we could use to trigger the tag. For that very specific event—the order submission click leading to the order success page, and only in Firefox—we fired the tag on the Purchase event (which is pre-built into Magento) instead of the gtm.dom event.
It worked. Google Analytics now records all transactions and enhanced eCommerce data from all browsers, including Firefox. This gives us a variety of insight into how our client’s online store performs and how our marketing team can better support this eCommerce strategy.
Focusing on Resolution over Explanation
We have a solution, but no explanation for why the issue happened in the first place. Perhaps the best lesson from this experience is to be solution-oriented, not just explanation-oriented. While we’d still love to know exactly what caused Firefox to drop our eCommerce data, the time needed to find this explanation could take us away from more valuable tasks that could benefit our client (such as analyzing the data we could now collect from Firefox).
As digital problem solvers, we at Atlantic BT love a good data mystery. But ultimately, our primary goal is to resolve our client’s challenges, not just research the causes of them. By focusing on a fix with the help of our expert developers, we rerouted the client’s essential data to better inform our eCommerce strategy.
