The s_code.js file – Configuration

The s_code.js file – Configuration

This article is part of the mini series about the s_code.js file. You can find the other articles here:

The Configuration Section

The configuration of some of the tracking is defined in the s_code.js file in two locations.

[Screenshot]

code – configuration section part 1

Let’s look at all the settings in detail. We won’t be repeating information from the knowledge base. Instead, we’ll introduce some concepts.

Report Suites

Adobe Analytics is mostly used to track web sites, mobile apps and other online “real estate”. Data gets sent into the system via a couple of different methods, predominantly Javascript-generated HTTP GET requests.

The backend processes and aggregates the data and creates reports that a marketer can look at when they log in.

Companies might have more than single site or app and so Adobe Analytics has the concept of a “report suite”, which is basically like a database for tracking data. When the marketer logs into the system, they can select which report suite they want to look at using a drop down.

[Screenshot]

Report Suite Selection

So how do we configure the tracking code to send data into a specific report suite?

We need the “report suite ID” or “rsid”. An Adobe consultant would usually give you the rsid, but your marketer might actually be savvy enough as well.

Once you get the rsid, put it into the s_account variable on line 10.

Tracking Servers

Adobe currently has 4 data centres around the world and a whole bunch of data collection centres. The data in a report suite resides in one of the 4 data centres (San Jose and Dallas in the US, London in the UK and Singapore), so we need to tell the system where to send it. This is what the s.trackingServer variable is for.

The value could look like any of these three:

  • s.trackingServer="jexnerinc.112.2o7.net";
  • s.trackingServer="janexnerinc.d1.sc.omtrdc.net";
  • s.trackingServer="om.jan-exner.de";

The first one points straight to the data collection servers situated in the data centre. This used to be the standard for 3rd party cookie implementations.

You can see what data centre the traffic goes to: “112” designates San Jose, “122” means Dallas.

[Screesnhot]

s.code – configuration section 2

The second points to a data collection server somewhere near the visitor. This is called “Regional Data Collection” or RDC. Most Adobe Analytics implementations these days should use RDC for 3rd party cookie setups, so this is what you’ll likely find in your file.

Again, you can tell the data centre: “d1” is San Jose, “d2” is Dallas, “d3” is London and “d4” is Singapore. The “sc” tells you that this will go into Adobe Analytics.

The third one is an example of a 1st party cookie setup, where the tracking goes to a domain set up by your company. Technically, this is a CNAME record pointing to one of the Adobe servers.

[Screenshot]

s.code – configuration section 2

If you have an old s_code.js file, you might not have s.trackingServer. Instead, you might see the s.dc variable instead, with a value “112” for San Jose or “122” for Dallas. We’d encourage you to use s.trackingServer instead.

Other Configuration

In a retail environment or when your site tracks any revenue, you will want to define the currency using the s.currencyCode variable. If your company has sites using different currencies, setting this properly is vital as the back end will use it to convert to a standard currency (which can be set up for each report suite).

The variables in lines 18 – 22 configure how some automatic tracking works, specifically tracking of exit links, download links and internal links.

Exit links are links on your site that transport the visitor off the site and somewhere else. Two variables configure how Adobe Analytics treats these links:

  • s.linkInternalFilters defines all URLs that are considered internal, therefore allowing the code to see which links are not.
  • s.trackExternalLinks controls whether the code should automatically track those or not.

The list in s.linkInternalFilters is a list of substrings of URLs which will be matched against the href parameter of any link clicked on the page. If the URL does not match, the system tracks the click as an “Exit Link”.

Fun fact: if you put a “.” into s.linkInternalFilters, the Javascript code will basically treat the whole Internet as internal. You will therefore not see any exit links in the reporting. Good for a development site with changing URLs, bad for production.

“Download Links” work in a similar way, using the s.trackDownloadLinks variable to enable/disable and the s.linkDownloadFileTypes variable to specify which type of content should be tracked. Clicks on links to any of these file types will show up in the “File Downloads” report.

The s.linkLeaveQueryString variable determines whether the URL in Exit Link and File Downloads reports will be truncated (without query parameters) or not (with query parameters).

Some download links do only make sense with the parameters, so this variable allows you to enable them in these two reports.

The other two variables in this section, s.linkTrackVars and s.linkTrackEvents are used by the system to determine which of the custom variables it will send in on link tracking. We shall get to that when we discuss link tracking in general.

About

German expat living in Switzerland (formerly UK and France). Consultant and member of the Multi-Solutions Group at Adobe, working with the Digital Marketing Suite. Father of 4 girls.

Tagged with: , , ,
Posted in Javascript
15 comments on “The s_code.js file – Configuration
  1. […] explain what it does and why you need it. We’ll tell you what you have to configure inside the file. We’ll also give you some tips around using it to make your life […]

    Like

  2. […] in Adobe Analytics is stored in “Report Suites”, we mentioned that […]

    Like

  3. […] of the box, if the configuration in the s_code.js file is right, Adobe Analytics will track downloads and exit links. Your marketer can find reports about […]

    Like

  4. […] a section with configuration variables, […]

    Like

  5. […] the post about s_code.js file — configuration I mentioned that you have to configure the s.trackingServer variable so the data goes to the right […]

    Like

  6. […] suite ID (or “rsid”) in the s_account variable in the configuration section of the s_code.js […]

    Like

  7. […] I have mentioned it a lot but only ever gone into a little bit of detail in the post about the configuration section of the s_code.js file. Let’s go […]

    Like

  8. […] is really easy. In fact, it is almost out-of-the-box. All you have to do is configure it in the configuration section of the s_code.js […]

    Like

  9. […] explained where to find the report suite ID, and the tracking server(s) can be found in the configuration section in the s_code.js file. Sometimes they are hidden away just above the “* DO NOT ALTER ANYTHING […]

    Like

  10. […] might remember that the file has 4 sections in it: configuration, doPlugins, plugins, and core Javascript […]

    Like

  11. […] the s_code.js file? It has a configuration section. In there, you’ll find a variable called s.linkInternalFilters, which you should set to a […]

    Like

  12. […] 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 […]

    Like

Leave a 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 )

Twitter picture

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

Facebook photo

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

Google+ photo

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

Connecting to %s

Enter your email address to follow this blog and receive notifications of new posts by email.

Join 1,398 other followers

%d bloggers like this: