The s_code.js file – s.doPlugins()

The s_code.js file – s.doPlugins()

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

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

The s.doPlugins() Callback Method

Now this one is a proper subject for developers. So far we have only seen configuration variables and talked about principles behind Adobe Analytics.

This time, though, we’ll dive into the world of automation and code!

Remember when in the post about basic tracking we mentioned that tracking happens whenever you want on a page or, to be precise, when you call the s.t() method.

Well.

First of all, that was only half the truth. There is a second method that can send tracking into Adobe Analytics. It is called s.tl() (for “track link”), and it is used when you want to track anything that is not a Page View. Prominent examples would be download links or clicks on specific buttons.

Furthermore, when you call s.t(), the Javascript code does a couple of things before it actually sends the tracking off. In a usual setup, setting variables on the page and calling s.t() only does about 20% of the work. The rest is done within the s.doPlugins() method.

Collect Data

The s.t() method takes the “s object” that was defined when s_code.js was loaded. It then amends it with a couple of data points, such as the current time, the version of Javascript supported in the browser, whether Java is enabled or not, screen and viewport sizes and a couple of other mostly technical bits and pieces.

Once it has done that, it calls the s.doPlugins() method. Upon return, it finally sends off the HTTP GET request to the Adobe collection servers.

Automate!

The s.doPlugins() method acts like a call back function that hands you the “s object” and allows you to modify it before it is sent out.

Now keep in mind that the s.doPlugins() method is defined in the s_code.js file. This file is loaded on every page that is tracked on the site!

Basically, we can use the s.doPlugins() method to do things that we want to do on every tracked page, without having to put any further code on the pages!

We have already mentioned tracking codes and campaign tracking, where we basically capture a tracking code off the URL and place it into the s.campaign variable. This is a perfect example for something that should be done in the s.doPlugins() method! You never know where exactly visitors will land.

Other examples include tracking how often visitors have been on the site, how many days have passed since their last visit, or how far they scroll on pages.

You can put any code into the s.doPlugins() method, and you have access to all the attributes of the “s object”. Pure power!

Abuse

With power comes responsibility.

I know a (very capable) implementer who used the s.doPlugins() method to bypass the fact that the agency in charge of the web site at a UK client was less than forthcoming with implementing any web analytics. He added Javascript code that would heavily scrape the page and abuse the DOM to get out the data that the client wanted to track.

This is obviously ingenious, and it allowed the client to track things they would otherwise not have had. But.

When spending cuts at the client meant they stopped working with that implementer, it all fell apart very quickly. Noone was able to keep the code in the method up-to-date and on par with the changes that were made on the site, so one by one, reports stopped working, tracking started to fail, and once the actual site itself was impacted.

So be careful!

We’re not saying “don’t be ingenious”, that would be ridiculous. All we’re trying to convey is: be careful and document the living daylights out of your s.doPlugins() method! Make sure there is a process in place that keeps the communication open between core web site development and the people responsible for the s_code.js file! And test! A lot!

Page Names

On a more practical level, please do not use the s.doPlugins() method to set s.pageName, especially not based on the <title> element of the DOM!

The s.pageName variable uniquely identifies content in Adobe Analytics. That means two things:

1. Two different pages with the same s.pageName are treated as the sane content in Adobe Analytics.
2. If you change the s.pageName for an existing page, Adobe Analytics treats the page as a new one, essentially breaking historical reporting.

It is therefore good practise to set s.pageName either on the page itself where it is unlikely to change, or using a specially designated field in you CMS.

Tomorrow we will introduce some of the plugins that are part of any decent implementation of Adobe Analytics.