First of all, I know you hardcore users already know this old issue, but there might be new Analysts and since we did a little experiment, I want to share the results by writing a small blog post about this.
We wanted to investigate is every single hit sent to Adobe’s server when visitors click on a link that forwards to another page on the same browser tab. Originally this idea came from coder who wasn’t too happy what he saw when debugging some custom link tracking. I knew already that there have been some discussions around this topic for many years that sometimes the analytics hit doesn’t have enough time to populate because browser moves user to another page on the same tab. I assumed this data loss would be very minimum and also I wasn’t really concerned because all of these hits were “nice to know” metrics.
How to investigate the data loss and/or get a detour for this problem? You can make a segment where visits goes from page X to page Y and that way you can compare the results with that segment using page views vs link clicks with default link tracking. I’m sure you get the idea? Of course if user clicks on a link and then immediately closes browser or clicks back button etc then you might get link click but that wouldn’t be counted on the segment because page Y never loaded. I know, data is never 100% accurate, we all have to deal with it.
What is causing this link tracking problem? Maybe slow internet connection or is it a browser issue? We wanted to test this and that’s why we hardcoded two different tracking methods for custom link tracking.
1) Default link tracking by Adobe, populated asap when link is clicked.
2) Default link tracking by Adobe, but hit information is saved to browser’s local storage and populated on the next page view. This way hit isn’t terminated when browser is moved to another page, because hit is populated after page Y is loaded. This way we get all the hits counted! Note: Information is saved for long period of times and if user terminates browser after the link hit and page is not loaded then this hit is populated next time user comes to the site, so we surely will get the hit if user returns. However, if you look pages where this hit has been populated then you might get some strange pages that are not including the link itself. I know, every time there is a detour, there is also new thing to pay attention.
Our results for the test
Data for 1 month.
58,000 hits with default tracking and with our “local storage” method we got 69,000 hits. Yep, the difference was much bigger than I assumed. Any test is not 100% perfect, there are many things that can affect starting from where the coding is done (hardcoded to site, on s_code script, using DTM etc). Anyway, with these results there is surely some data loss if using default tracking methods. But what is the reason, is it on all browsers or what?
If we look results with different browsers:
Now it goes interesting. Amount of hits is pretty much same with browsers from Google, Microsoft, Samsung and Opera. There are two top manufactures that are showing this tracking issue. Mozilla (Firefox) and Apple (Safari). Both are losing almost half of the clicks with default tracking method. I guess those two browsers are handling http(s) request differently when moving to another page or something like that.
Surely Adobe has something to offer for this problem? Yes, looks like so. Although, I haven’t still got results is this 100% perfect. I guess it should be, but of course there is a fine line to balance with analytics tracking and making visitors to wait link to work etc. Every millisecond is important as Adobe stated on one Summit. 😉
To be honest, again blog post or should I say memo is just for myself. After writing this, I’m sure I will never forget this one either. For you, my fellow Analyst, if these kind of custom hits are important KPI metrics for you then please make sure you are tracking those correctly, no matter what your solution to the problem might be. And again great reminder why data is never ever 100% accurate, keep calm and carry on.
Please share if you know something about this issue that I didn’t, but I believe Adobe’s help documentation makes sense and will help to fight this issue.