The s_code.js File – Where is it now?

Sometimes, I get narcissistic. I log into Analytics and go through the numbers, for no other reasons than wanting to see whether they have gone up again. Then I am pleased.

For about a year or so, I have always seen one specific article at the top of the list, The s_code.js File – Overview. This has always puzzled me slightly. It has often led to me thinking I should write about it some more. But: what else would I write about it? The mini series pretty much covered it all, overview, configuration, doPlugins method, plugins, and the core Javascript code. So, what’s left to say?

Well, there might be a little bit left, and it has to do with — wait for it — DTM! Yay! Another DTM post!

But if you are new to Tag Management, I guess you might have asked yourself the question “where does that stuff go?”, and so I shall try to answer that question today.

This will not be a mini-series, more a mini-article. TMS are cool, they make things easier.


In the s_code.js file, there are configuration settings, where you specify things like the report suite to be used, tracking servers, internal link URLs, or character encoding.

I’m happy to say that your TMS will take care of that stuff. In DTM, to cite an obvious example, you can set all of these in the configuration of the Analytics Tool.

DTM – UI for configuration of Analytics


As I mentioned about a month and a half ago, the s.doPlugins() method is alive and well, even if you’re using a TMS.

If you are not yet using a TMS, you’re bound to have one in your s_code.js file. So where does it go?

I would put it into a place where it is executed (which means it sort of installs itself) once per page load. Your TMS documentation will show you where that would be.

For DTM, I can tell you: put it into the edit box under “Customize Page Code” in the Adobe Analytics Tool.

DTM – where to put doPlugins
Why does this work?

Well, DTM makes the deployment of Analytics more fancy, but under the hood, it still loads the Javascript code and calls s.t() and The core JS code still does what it always did: call doPlugins() before it actually tracks.

So, if you create a function called s.doPlugins(s) and set s.usePlugins = true, the function will be called on every tracking call.


It might make sense to remove some code from the method, though.

Think about it: how much of your code could be replaced with a Data Element? Which part of it could rather be dealt with using an extra rule?

My tip: each bit of code that you migrate from doPlugins and into DTM (or whatever your TMS is) will make your setup easier, at least easier for your friendly marketer.


Now where do the actual plugins go? (That is those that you still need!)

I’m sure you can guess: they go where the s.doPlugins() method goes as well: into the edit box under the “Customize Page Code” section in the Analytics Tool.

Again, we want the plugin code to be called once, at page load, on every page. That’ll define the plugin, so it can subsequently be used in doPlugins.

Do you put the plugins code below or above doPlugins?

Doesn’t matter. As long as the browser has gone through them before the first call to doPlugins, everything is fine.

Core Javascript Code

The core Javascript code is very similar to plugins and the doPlugins method in that it must be loaded once per page. You might copy your existing code, and there might even be a place in your TMS reserved for that. In DTM, that place is under “Library Management”: yet another “Open Editor” button.

DTM – core JS could live here
I have to say, though, that I don’t like that.

Some people just copy their complete s_code.js file into this editor, which totally works, but…

Don’t you want to disentangle things? Make your setup easier?

The easiest, and really the preferred way of handling the core Javascript file, is to not handle it at all, like so:

DTM – core JS should live here!


I’m sure there are good reasons to stray from the path I outlined here.

Actually, no, I am not.

The reality is that if you actually do copy the whole s_code.js file in one go, you bring your old boxes into a new house. Have you ever moved house? Noticed how you never actually open some of those boxes? This is one of those. It’ll stay closed forever. I say open it before you move, throw away the cruft!

I did it along with a German customer, and it took us a day. Down the line, we have a slimmer system, and we’ll get that day back multiple times over because we don’t have to always worry about side-effects of the old stuff.

Absolutely worth it!

13 thoughts on “The s_code.js File – Where is it now?

  1. Nice post … excellent explanation of DTM Adobe Analytics tool configuration …

    One question/clarification in case of single page application tracking I hope custom page code section works same way


    1. Well the code in “custom page code” is executed once, when DTM loads. After that, you will have to trigger rules (EBRs or DCRs) yourself.

      Whether you have an s.doPlugin function is unrelated, but it will obviously work fine if you have one. Still have to trigger EBRs and DCRs on what you deem are “page loads”.


  2. this only works for initial page load. But doPlugins will NOT pop for event or direct call rules! This is because internally DTM, every time a event/dc rule is executed, DTM recreates the s object (internal .getS() method) instead of referencing the initial object! And the getS() object will NOT take into consideration anything within the custom code blocks of the tool!


  3. First let me apologize I sent this message originally on the wrong article. My employer intends to start using Adobe analytics and will install it next week. So I researching best practices for installation. So are you saying that you can use DTM to install the s_code.js, instead of injecting the s_code.js javascript on every single page of the website? If we load each section of the s_code.js into the proper areas of the DTM we can use that to load s_code.js to each page when ever the page is loaded? (accessed)


      1. Ok Thanks. One more question please. What are the pros and cons of using DTM vs hard coding to each page? The head developer is trying to figure out the benefits and consequences of laod the s_code.js through the cloud vs hard coding it directly to each page.


      2. Hi Darius,

        That’s a pretty broad question… very simplistically spoken, an analytics team can have more freedom when they use tag management. Here’s a take from someone else: Note that you won’t have complete freedom, you will still need dev every now and again. You will also likely need someone on the analytics team who can speak Javascript.

        If you do decide to go with DTM, may I suggest a small reading list?,, and might help you get off the ground.

        Best of luck!


      3. This does lead me to one more question. Can you suggest any sources that can guide me as to when its best to use the DTM for tags and java, vs when to hard code it directly into the page? This would really help me out.


Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

This site uses Akismet to reduce spam. Learn how your comment data is processed.