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

There are two basic javascript constructs for sending information to Omniture’s tracking servers: “t” and “tl”. T stands for “tracking”, and tl stands for “tracking-link”. The tracking call was built to go on every html page of your website, while the tracking link call was made for the in-between times when visitors clicked on something important within a page that you needed to capture as well.
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.
The reason: Omniture’s S object is no longer readable at the global level, at least not if you’re using the current appMeasurement library. If you try running the clearVars function, you’ll get a “RefenceError: s is not defined” message in the javascript console. The data is still there, still being cached, but now the s object is absconded deep within DTM’s catacombs.
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')[0].getS();
s.clearVars()

Hands-on Example

I know this has been a very tech-heavy blogpost, but if you’re interested in seeing what happens when you ignore the cache-clearing step in between AJAX calls, take a look at this interactive demo I built:
See it for Yourself: Omniture Caching
One remarkable element that I hadn’t realized now is that the data layer caching issues are not causing the problems in the actual reporting. I don’t pretend to understand it all fully, but if you go to that site and enable the Omniture cache-clearing solution without enabling the data layer cache-clearing solution, that the Omniture data being sent ends up correct. It would seem that DTM is set up to handle the data layer caching issues already. Now if only Adobe will just fix its own legacy caching issues, the entire problem would become history.

Related Content

There are a lot of challenges in marketing & advertising - don't let data be one of them. Find out how Claravine helps with what you just read (and more). See why The Data Standards Cloud is the only solution to true data quality.