The utag.link callback function or "How can I be sure the tracking requests have gone through"?

[loldenburg]

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.

https://community.tealiumiq.com/t5/JavaScript-utag-js/Tracking-with-utag-view-and-utag-link/ta-p/155...

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?

[craig_rouse]

@loldenburg you are correct about the timing of the callback - it does not guarantee that all tags have finished sending. However, if you are using a utag.js version later than 4.38, there is an additional "execution order" option available in extensions, which you can set to "after tags". Although this doesn't absolutely guarantee that the tags actually reached the servers for your respective vendors (we can't monitor individual pixels), it does guarantee that all the Tealium tags have finished *executing* (basically, Tealium has nothing left to do for this tracking request, but if the vendor tag has a problem e.g. returns a 404, we can't monitor this).

To do specifically what you are aiming for (ensure tracking data is always sent on exit links), there is no totally safe solution, other than delaying the page unload by a fixed amount of time and "hoping" that your tags have finished sending. In my opinion, anything that risks breaking the navigation on your site (if, for example, there is some sort of error in your delayed navigation function), is probably not worthwhile for the extra few tracking hits you will receive. If you really need to track those links, it would be much better to set a cookie temporarily to store the link name, and send the hit on the next page. This obviously only works for internal links, not those where the user navigates to another domain.

I hope this helps.
Craig.

[loldenburg]

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. 

[loldenburg]

added info on cookie solution - not an option for us

[craig_rouse]

@loldenburg I don't think you will ever come up with a solution that covers all cases, especially when you include private browsing modes (every browser has slightly different implementations of private browsing). Definitely localStorage would be more up to the job than a cookie, and the javascript required to make sure that the pageview goes before the event would not be too tricky to set up.

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.

The main reason we don't have this specific functionality is that a one-size-fits-all solution is rarely going to be successful across the many different sites we are implemented on, and because of the many different navigation strategies employed by developers (especially where single page apps are concerned), there's always a chance that we could be responsible for totally messing up page navigation, which would certainly not be good.

All of the above is based on my own opinion and how I would choose to do it on my own site, but of course we'll probably have differences of opinion here :-)

Hopefully this is a useful discussion for others also. Your honest feedback on my suggestions is very welcome.

[craig_rouse]

@loldenburg one more thing to add... for what it's worth, I have seen numerous issues over the years caused by "automatic" exit link tracking in some analytics tools. Generally they are pretty reliable, but as I mentioned before, you just can't account for every use case, and when it goes wrong, it tends to go *very* wrong.

[loldenburg]

"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.

[loldenburg]

btw we also do not use "automatic exit link tracking" functions of Adobe for example as those end up in entirely different reports and are not very useful.

[loldenburg]

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.

[jan_van_damme]

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!

[kathleen_jo]

Indeed @jan_van_damme. Indeed. 

[loldenburg]

Yes, but this sometimes creates additional problems. "click" is the solution that is the least invasive, however we use mousedown as well in some cases where we are certain to avoid side effects.

[kathleen_jo]

Good point @loldenburg. Thank you for following up and letting myself and @jan_van_damme know!

[bill_tripple]

My suggestion is to have the developer code in the delay allowing the image request to go thru.

[kathleen_jo]

Thank you for the suggestion @bill_tripple!