How we can improve ecommerce tracking in google analytics with a hybrid browser / server approach
Transaction and revenue tracking is the most useful data you can have about your customers. It tells you all sorts of useful tidbits about who and what your customers bought, the time it took them to commit, what worked and what didn’t, which campaigns to push on with and where to cut back.
But the accuracy of such data has always been questioned within google analytics, part of that is because there are so precious few of these compared to the total site traffic that even missing one stands out, another is that for transactions there is a source of record in the form of your order management system so its easy to compare.
The traditional way to do transaction tracking for most people is by placing a javascript code on the order confirmation page. The javascript snippet is wonderful for most cases with the ease of use it offers but its accuracy has traditionally been lower than something running on your server. Thats generally because the browser is something you’ve less control over versus your own backend.
One of the main reasons for this is there isn’t a standard way to do tracking on the server; each backend is different using different platforms and programming languages. With the browser you have this set way, drop some javascript code on each page + drop this other code on the order confirm page and you’re done regardless of whatever you used to build the store you can always rely on javascript to track behavior.
The second reason is identity; the transaction data is only useful in Analytics if its tied to the behavior of the customer that did the transaction. Without what the user did or how the user found their way to purchase this is useless.
Universal Analytics has been a revelation in terms of ease of use, its main benefits are hidden from plain view, what it offers is a very lean api resulting in an easy standardized way to send data into Google Analytics from any system (browser, server, pos, crm).
The identity collection have also been made easier previously with Google Analytics Classic a part of data lived in a cookie on the browser (traffic source, number of sessions, visitor level data etc) now most of it has been moved to Google’s server to show its data crunching prowess. Leaving us with just a single client identifier. Using the identifier we can append more information to the record that GA has been keeping.
With this lower barrier the question becomes: why is a critical piece of information thats available on the server not being sent directly to google analytics? Doing so would boost not only the accuracy of tracking but also data that can be gleaned (think profit tracking and refunds instead of just gross revenue).
Javascript is a wonderful for tracking on page activity but I would advocate rethinking the browser only approach and replacing it with a hybrid of browser and server. Especially for critical pieces of data where higher accuracy justifies some more work.
Mind you Google Analytics isn’t meant to be used as the source of record for sales but the barrier to doing so is becoming so low why not improve the marketing attribution?
The general idea is track whatever is actually happening in the browser or is being done by the user on the page track them using js but things that require server’s involvement in validation / approval should be done directly from the server. Ditto for any recurring or time delayed tasks (tasks requiring interaction from site admins). This way we not only increase the accuracy of tracking these actions we also get a fuller picture of users experience with the brand.
I have been thinking of this issue for a while initially starting with accuracy issues with Paypal tracking in 2012 and since then solving similar issues for a lot of clients over the years. At the end of day I think the way to really solve it at scale.
We are now building something to solve the issue once and for all starting with Magento and Paypal.
Still 2 years Paypal as one of the largest payment processors (last relevant one with a dated offsite payment flow) has the same issues I originally outlined.
If you are using Paypal as a payment processor (regardless of your ecommerce platform choice) please signup here.
If you are a Magento user (with any payment processor) interested in beta testing, please signup here.
