This article is part of the mini series about the
s_code.js file. You can find the other articles here:
- Configuration section
The biggest portion of the
In this part of the file, all the important client-side functionality of Adobe Analytics is defined. The “s object” creation method
s_gi is declared along with a couple of helper methods.
s.tl are defined here, the two methods that you use to actually send tracking information. We have introduced
s.t and will discuss
s.tl at some point.
A big part of the code handles setting of the so-called “automatic variables”.
If you check with a debugger, you will notice that tracking calls actually contain a lot more than the data you set:
Depending on what browser you are using, you might see more parameters.
Netscape-based browsers send a list of installed plugins in the “p” parameter, while IE sends things like connection speed (“ct”) and whether the current page is the home page (“hp”). How useful those measurements are is a matter of discussion…
It does the heavy-lifting you’d expect from a library. It handles automatic variables. It provides the “s object” container that allows you to store data for transfer. It also provides you with methods to send that data.
On top of that, it contains the very useful
s.doPlugins call back method, which allows you to handle everything that has to be done across the whole site in a central place.
s_code.js file truly is the most important piece in the whole tracking picture.
Now having said that, we hope that in the future it won’t be.
- The file really has two broader purposes, and those should be separated.
- Tag Management is on the rise, fortunately.
We can broadly group the four parts of the
The rest of the
s_code.js file will be updated by you or other implementers.
That raises an obvious question: how to easily integrate?
We will post an article on best practise, but for now let’s just say it would be easier if those two groups would be separate.
Secondly, tag management systems are more and more powerful and more customers are using them for convenience and sometimes enhanced functionality.
It makes a lot of sense to put at least some of the four sections that currently sit inside
s_code.js into a tag management system instead.
So there you have it, our mini-series on
s_code.js concludes. Please feel free to post any questions or remarks in the comments below this or the relevant posting! We’d love to hear from you!