Quick Tip – One s_code.js for Multiple Sites

The situation: you are responsible for a couple of sites on different domains. Tracking is pretty much the same on all of these pages, but there are some small differences (e.g. each site tracks into a separate report suite).

A new version of the s_code has come out and you want to update all your sites.

What’s the best way of doing that?

The best way, of course, is to use a Tag Management System, like DTM.

Using a TMS, you can inject the s_code.js file into all your sites, and you can also change it there.

This helps you get around the release schedule, but it doesn’t address the fact that tracking is similar across your sites. What if 95% of the tracking is the same? Do you really have to touch every site just because something has changed in that part of the code?

Slice it!

I wouldn’t ask that question if I didn’t have an answer, would I?

It’s pretty straightforward: slice the s_code.js file, split it into pieces.

You might remember that the file has 4 sections in it: configuration, doPlugins, plugins, and core Javascript code.

A pretty simple approach would be to split the file into 4 pieces following those 4 sections:

1. The section most likely to change for all sites at once (the core JS code) can be split into a separate file. You can use that file across all your sites. Great: only update a single file when the core JS changes!
2. Your settings will be different for each site, so the part of the file that handles the settings can be separated and each site can have a (fairly static) file that contains just the settings.
3. The code that defines the plugins can be split out. It is fairly likely that all your sites use more or less the same plugins. So it makes sense to have one file contain them all, then load that file on all sites. And: if you want to update a plugin, you only have to do it once.
4. For the doPlugins method, you might have a different setup per site. In which case you would have a lot of these, for all your sites. But maybe the method is the same everywhere, in which case you can use one file, like for the core JS code and the plugin definitions. (Btw: it makes sense from an analytics point of view to have a similar doPlugins method. Think standardisation.)

DTM follows this approach partly: it allows you to set configuration directly in the UI, and you can instruct it to inject the core JS code straight from DTM.

The plugin code as well as the doPlugins method can also be defined in the DTM UI, but they’re usually not separated. I guess if you are using the exact same plugins in the exact same ways across all the sites you manage, then why separate those two?

In essence, splitting the s_code.js file in 3 is a good option as well.

Five

And so is splitting it into 5 pieces!

At the very top of the file, you usually set the report suite ID into a variable called s_account. The next step in the file is to call a method called s_gi with that rsid. The result is the “s object” that handles everything else.

The setting of s_account has to be done before the call to s_gi, and the call to s_gi has to be done before we set any configuration variables on the s obejct or define or call any plugins.

It makes sense, therefore, to treat the assignment of s_account separately. In fact, this might be the only difference between two sites, all the rest might be identical!

So… 3, 4, 5, how many pieces do you need?

My advice:

• if all your sites have identical tracking setup, split in 3
  • s_account,
  • configuration, plugin code and doPlugins, and
  • core JS code
• if, however, the setup is different between your sites, split in 4 or 5
  • s_account,
  • configuration,
  • plugin code,
  • doPlugins, and
  • core JS code

Make sure you always have a separate file for the core Javascript code — that’s what’ll allow you to easily upgrade to the latest version!

No TMS?

What if you don’t have a TMS?

You should probably still split the s_code.js file!

One added thing for you to think about then is: in which order do you need to load the three to five JS files? What are the dependencies? Where on the page should you load them?

In principle, you should load the files in the order they appear in the s_code.js file.

1. The assignment of s_account must be first
2. Defining the s object via a call to s_gi must be after s_account but before everything else
3. The configuration can happen parallel to the definition of the plugins and doPlugins. All three must happen after the s object is initialised and before the call to s.t().

Given that it makes a lot of sense to call s.t() at the very end of the page (a raging debate, also within our organisation. I am firmly on the “as far down as possible” side), you can load the others pretty much anywhere.

I have seen sites that inline the assignment of s_account, which to me makes some sense, but obviously makes it more difficult to change the report suite if that should be needed.

Have you split up the s_code.js file? How? Why?