08-02-2017 08:57 AM - edited 08-02-2017 08:58 AM
We want to track clicks on links and make sure that they are only followed after the tracking requests have successfully reached our analytics tools' servers.
says about the "callback" function:
"A function to be executed after the tracking call has completed."
Is this not misleading? Our developers now think they can just use the callback to run a function that executes the following of the clicked that was linked.
But the "tracking call" has not really been completed in the moment the callback runs, it is just a notice that Tealium's Extensions and Tag Code has run through entirely, right?
So if that's correct, what is the best way (other than hard-delaying the following of the link, e.g. a hard delay of 200 ms on every click before following the link) to do this with Tealium?
08-02-2017 09:27 AM - edited 08-02-2017 09:30 AM
Thanks for the fast reply, @craig_rouse.
I don't agree with the "few hits", there is a considerable loss of tracking hits if we don't use a delay, and different tools vary in their speed to receive the request (Adobe is a bit slow, Google is faster usually). And other Tag Managers even offer auto-delay for up to 3 seconds in their interfaces. Tealium doesn't, they leave it up to the client how to handle this.
So I understand you correctly that an "after tags" Extension that does not do anything would increase the likelihood that the tags have all fired? (if we use the callback function to follow the links).
We thought about the cookie solution a lot, and ideally that's how I would like to do it, but first of all, Google Analytics does not accept Events being sent before a Pageview, and we would have to reproduce the whole context of the previous page on the next page (so we'd need to save the whole UDO in a cookie or at least all page-dependent context variables (page_name, page_category, product_category, page_url, product_brand etc... to be able to access them on the next page for tracking). That is too much for a cookie, so some complex localStorage construct would be the only solution. But localStorage is rejected by many browsers in private Mode (Safari), so that's not an option either.
"I think the best solution here is to go with the fixed navigation delay if those exit links are so important to track, but maybe you could come up with a creative solution that doesn't rely on the actual click event? Maybe something like a query parameter on the link to uniquely identify in the pageview reports which link triggered the pageview (or even, fire off an event on the next page that only gets triggered if a specific query param is set). I would argue that this solution should satisfy your reporting needs, and more importantly, it doesn't risk breaking and/or delaying your site navigation."
It is not only Exit Links (I don't care about losing some of those), it is link clicks in Product Lists, but most importantly add to cart clicks, so all interactions that directly lead to the opening of the next page. We would have to transfer the whole product and list context (about 15 UDO variables in it alone), the page context (Section, URL, Path etc...) etc. to the next page, and localStorage, as our reports show, is just not reliable enough (5-9% of our Visitors do not support localStorage, which is too much for sensitive events like Cart Additions), and then map it all twice in duplicate UDO variables to make sure these "carry-over variables are not confused with those of the next page.
BTW a tool that is even more affected by the aborted requests is Tealium's Collect Tag. Which is maybe more lamentable because that one should really contain as much data as possible. But since the request is huge as it contains the whole Data Layer, it is understandable that this may take a while.
A quick hat tip to 'gain' up to 300 milliseconds is to do the click tracking on mousedown instead of on click.
The time between the mousedown event and the actual click event can be enough to give the tags the time to get send.
This won't solve all issues but all little bits help right!