Omniture Page Tracking with AJAX – Clear the Cache!
Watch out for Bridges and Hop-ons
Omniture Page Calls in AJAX, like the Bluth company stair car, are susceptible to hop-ons.
Since my tenure there over a decade ago, Omniture has gone through a series of evolutions in its code and business. Nowadays I’m usually pretty good at saying ‘Adobe Analytics’ instead of ‘Omniture’, but as the caching issues that plague AJAX page-tracking trace all the way back to those early days, for this one article I’m going old school and using the Omniture name almost exclusively.
This is a long article that will eventually boil down to one conclusion: you have to manually clear your “s” object’s cached values between each Omniture tracking call you make if you’re using AJAX. If you’re staying up to date and using the AppMeasurement library instead of Omniture’s legacy “H-codes”, and particularly if you’re running it all through Adobe’s TMS (DTM), this chore just got harder, so this article also provides a couple of workarounds for those situations.
A Tale of Two Functions
The only major difference between these two constructs is that the Page View event is suppressed on the tracking-link calls. Omniture didn’t want to muddy up your Page and Pathing reports with the link-by-link clicks within each page, and that’s why it created the tracking-link call in the first place. But there was a problem: all of the data points that you defined and sent to Omniture when the page first loaded were still hanging around when you fired the link tracking function. As the patriarch in “Arrested Development” would warn, “you’re gonna get some hop-ons.”
To prevent unwanted data from pushing their way into these on-click transmissions, Omniture introduced two bodyguard-variables: linkTrackVars and linkTrackEvents. These two bruisers guard the door to the Omniture party at every track-link entrance. If your name’s not on their list, you won’t make it through the door.
Back to the Present
Fast-forward to the present day, where dynamic sites are becoming the norm. Gone are the days when every new page experience was presented to users by sending them to a separate HTML page. Airline booking sequences, retail purchase funnels, and other major interactive experiences are frequently encapsulated within a single html container.
In these cases, the analytics best practice is to use the tracking (t) function rather than the on-click (tl) function. You certainly would not want to sacrifice fallout and other pathing reports just because these “pages” were not implemented as separate HTML files.
Unfortunately, Omniture didn’t anticipate this scenario; no bouncer mechanisms are automatically deployed to block hop-ons when you fire off a sequence of page tracking calls in a dynamic environment.
On the other hand, Adobe has recently added a popular cache-clearing script (clearVars) into its current code base, so things are beginning to change, albeit slowly and very late. Still, I wonder why they don’t just add a check at the beginning of every page view call and see if the Omniture object already exists, and re-instantiate it if it does. Of course it should a setting option, but I think the new implementations should use that as the default.
DTM Makes Cache-Clearing Harder
I had this post ready to publish a few weeks ago, but then suddenly my solution stopped working inside of DTM, Adobe’s tag management solution.
So I’ve had to discover a workaround to let me clear the cache, yet still keep the most recent version of Omniture code running on my site. (Thanks to Joshua Donley who wrote it, but who also warned that it hasn’t been heavily tested or authorized by Adobe in any way.)
Here it is:
var s = _satellite.getToolsByType('sc').getS();