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.
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.
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.
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.
Why does this work?
s.tl(). 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
Do you put the plugins code below or above
Doesn’t matter. As long as the browser has gone through them before the first call to
doPlugins, everything is fine.
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.
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?
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?”
That is true, but you can always “re-set” the rsid using the s.sa() function and an s.doPlugins() method.
See https://webanalyticsfordevelopers.com/2015/09/01/dtm-and-the-doplugins-callback/ for the latter, and I shall write about the former at some point. For now, http://www.searchdiscovery.com/blog/managing-multi-suite-tagging-implementation-adobedtm/ is a starting point.
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
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”.
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!
Correct. No need to manually deploy s_code if you use DTM (or any other tag manager). Note that you must embed DTM, of course.
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.
If you do decide to go with DTM, may I suggest a small reading list? https://blogs.adobe.com/digitalmarketing/analytics/getting-started-adobe-dynamic-tag-management-part-1/, https://blogs.adobe.com/digitalmarketing/analytics/getting-started-adobe-dynamic-tag-management-part-2/, and https://webanalyticsfordevelopers.com/2015/12/15/basic-tracking-remix-contains-dtm/ might help you get off the ground.
Best of luck!
Thank you so much for your timely response and suggestion. I greatly appreciate it.
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.