The s_code.js file – Core Javascript Code

This article is part of the mini series about the s_code.js file. You can find the other articles here:

• Overview
• Configuration section
• The s.doPlugin() callback method
• Plugins
• Core Javascript code (this article)

Core Javascript Code

The biggest portion of the s_code.js file is the core Javascript code underneath the “DO NOT CHANGE” line.

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.

Most importantly, s.t and 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:

Data points like screen size (URL parameter “s”), browser width and height (“bh” & “bw”), colour depth (“c”), Javascript version (“j”), local time (“t”), the URL of the page (“g”) and others are automatically appended.

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…

Closing Thoughts

The s_code.js file is the heart of all Javascript-based, client-side tracking in Adobe Analytics.

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.

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

Two reasons:

1. The file really has two broader purposes, and those should be separated.
2. Tag Management is on the rise, fortunately.

We can broadly group the four parts of the s_code.js file into two: core Javascript code versus the rest.

The core Javascript code gets an update every now and again. Adobe Engineering is driving these updates. While a year ago or so they shipped version “H.24.2”, we are now on version “H.25.4”.

Note: there is a change log available for the core Javascript code.

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!