Today we’ll discuss one of the big questions of all times: when tracking links or actions, is it necessary to call
If you don’t know what I’m talking about, go and read the article on Tracking Links & Action while I wait.
At the heart of it is this piece of code:
As I wrote in the other article, the call to
s_gi() is meant to instantiate the “s object” which will a) carry the “variables” and b) define the
s.tl() method used to trigger the tracking call.
So how come you will find sites that use link tracking without
Let’s find out what
s_gi() method has two jobs: 1. instantiating an “s object” for a given list of report suite IDs and 2. retrieving that “s object” at any point.
Think of the Singleton pattern —
s_gi() works like the standard
The actual “s object” is implemented as a property of the window object, meaning when you call
s_gi(), the method will either create an “s object” and attach it to the window object, or it will return the “s object” that is already attached there.
In the context of link tracking, it is pretty safe to assume that when a visitor clicks the link to be tracked, there will already be an “s object” attached to window from back when the page loaded, so
s_gi() will just hand it back.
And that is it.
Contrary to popular belief,
s_gi() does not clear all “variables” or otherwise modify the “s object”.
So why do so many sites use
s_gi() in their link tracking?
In cases where a page is initially not tracked, maybe because the visitor clicks before the tracking has a chance to fire, there might be a race condition and the “s object” might not be ready. Yes, it could happen, but it is sort of unlikely.
I think this is one of those cases where at some point, documentation was written and people followed it. Since everything worked, noone questioned the documentation or the implementation. It became part of “Omniture folklore”, so to speak.
But Adobe Consulting are in recent times omitting it. I guess the days of this particular part of the Omniture legacy are numbered.
Sometimes, you might want to track page loads into one report suites and (some) links or actions into another one.
Do you need a new “s object” for those links? Can you even have more than one “s object” active at a given time?
No, you don’t have to, but yes, you can.
Sometimes sites will be double-tagged — say with an old version of tracking code and a new, fresh one in parallel during a transition period — and the way to achieve that is to rename one of the two objects. This would normally been done in the
s_code.js file, most likely by an Adobe consultant.
On your pages, you would then refer to those by their different names, say “s” and “s_legacy”.
More likely, though, you will use the
s.sa() method to just change the report suite ID for the next tracking call. Much easier and will almost always do the trick.
s.sa() with the report suite ID(s) that you want to use for the next call, before you call
s.tl(), like so:
s.events="event21,event22"; s.prop31=s.eVar31="Link Tracking White Paper"; s.eVar32=page_name; s.eVar33="+1"; s.linkTrackVars="events,prop31,eVar31,eVar32,eVar33"; s.linkTrackEvents="event21,event22"; s.sa("YOUR_NEW_RSID"); s.tl(this,"d","Link Tracking White Paper");
So what about all the “variables” that have been set earlier?
Well, for starters,
s.tl() will only transmit those “variables” that are referenced in
s.linkTrackEvents. As an example,
s.pageName will not be sent in the example above, even though it will have a value in the “s object” at the time when
s.tl() is called.
Secondly, if you use a “variable” both on page load and in link/action tracking and it sometimes should be empty for the latter, make sure you manually clear it by setting it to an empty string.