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!

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

  1. Hi Jan,
    a happy new year and welcome in 2021! Just my thoughts after reading you blogpost. I can understand you from your perspective…

    …but no, I don’t agree, sorry.

    You’re far too deep in your own business, than in the real world 😉

    The s_code (and btw either the appmeasurement & co) is still important and therefore any information about it, just to better understand what is going on and, of course, why it would be a good idea to move forward to the most current implementation version with Adobe’s TMS, at least in in Adobe’s opinion.

    Things are not as easy as they may look at first sight and the importance of tracking and the need of beeing first in row when it comes to the latest implementation techniques, isn’t given in any company. Especially if the tracking works and fits the needs. And many companies also do not like being somehow patronised in that case.

    So please give us some more time until we are enlightened to prioritize tracking over other business impacts 😉

    Cheers and a wonderful Year 2021,
    Bijan

    Like

    1. Ah… Bijan… there’s always someone who comes in with a nasty reminder of what reality is like…

      You’re right, of course, about not changing things that work. I would wager that aiming for simplicity should will help you kick out the legacy code eventually.

      If that article was just one of many, I wouldn’t even have written this one. I’m just annoyed it manages to stay at the top 🙂

      Like

Leave a Reply to Jan Exner Cancel reply

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

WordPress.com Logo

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

Google photo

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

Twitter picture

You are commenting using your Twitter 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.