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?
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.
A pretty simple approach would be to split the file into 4 pieces following those 4 sections:
- 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!
- 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.
- 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.
- For the
doPluginsmethod, 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
doPluginsmethod. 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.
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?
- if all your sites have identical tracking setup, split in 3
- configuration, plugin code and
- core JS code
- if, however, the setup is different between your sites, split in 4 or 5
- plugin code,
- core JS code
What if you don’t have a TMS?
You should probably still split the
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
- The assignment of
s_accountmust be first
- Defining the s object via a call to
s_gimust be after
s_accountbut before everything else
- 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
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?