What is “s_code.js”? Do I have to know?

No.

This could be the shortest post, ever. One word.

These days, you really do not have to know what “s_code.js” is, and the only reason I am even writing this is because for some reason that totally eludes me, an old post about it, from back in 2013, keeps being the most or second-most viewed post on this blog, every darn year!

I do not understand why that is, and so I am now trying to change it, actively. First, I am trying to write posts that perform better. Well, I’ve always tried that, tbh. Secondly, this article explains why, in my not very humble opinion, there is no reason for anyone to read that old article. And thirdly, I’ll put a link to this post at the very top of the old article. Ha! That should do it!

What is it?

When people say “s code js”, or just “s code”, they are referring to a file called s_code.js, that used to be the heart of Omniture SiteCatalyst.

I really do not want to link to the old article, so let me just tell you that it had 4 parts: Configuration, a doPlugins() method, plugins, and the core Javascript code for Analytics.

We used to implement Analytics by embedding that s_code.js file into every page of our customers’ sites, then added Javascript into individual pages to collect actual data.

It was tedious, and we’re all glad those times are long gone.

Do I have to know?

Again: no, you really don’t.

When tag managers came into the picture, the file was no longer relevant. I’m talking about real tag managers, not the Adobe Tag Manager v1 or v2, that came before DTM.

The 4 sections above ended up in different places in DTM, then in Launch, or rather in the Analytics Extension in Launch.

On top of that, and this is what really gets to me: the file has not been called s_code.js for ages! The successor, AppMeasurement.js, was released in May 2013, almost as long ago as that infamous article!

The s_code.js file itself was updated to version H.27.5 in May 2013, and that was it.

Since then, noone should have used that file, TMS or not!

And even AppMeasurement.js is no longer something you’ll touch, or refer to.

For starters, the Analytics Extension in Launch does it for you. Or, if you use another TMS, there will invariably be a similar mechanism.

Then, the Adobe Experience Platform Web SDK is rushing in like a strong tide, and part of the job of the AEP Web SDK is to supersede “legacy” Javascript libraries like AppMeasurement.js, at.js, DIL.js, and Visitor.js.

So?

So.

I shall try to figure out why on Earth someone would send you to that article, then show you where you really would want to go.

A — you found a reference to s_code.js on a site you manage, or you’re interested in, and you want to know what that is.

Easy: it’s an outdated Javascript file which is used to send data to Adobe Analytics. The site should really a) use a tag manager instead, or b) at least upgrade to AppMeasurement.js

B — you followed a link on the blog itself.

So, are you saying this is my fault?

Actually, there is a decent possibility that a lot of the traffic is happening because I linked back the mini series about 40 times, since.

Meaning: I have to go through all of those articles, and I have to change that link to point here, instead. Once I have done that, I can even add a link to the original, at the top.

That sounds like a good test!

C — you have a bookmark to this blog, and per chance, it points to that article.

Fair enough, if that is what you want to do. If I read my stats correctly, you are a rare occurrence, so never mind.

D — you – uhm – Idunno … hm … actually, there is no other reason that I could think of.

Here’s wishing you a great 2021!