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:

• Overview
• Configuration section (this article)
• The s.doPlugin() callback method
• Plugins
• Core Javascript code

The Configuration Section

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

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.

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 3^rd party cookie implementations.

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

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 3^rd 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 1^st 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.

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.