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:
- Configuration section
s.doPlugin()callback method (this article)
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.
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.
s.t() only does about 20% of the work. The rest is done within the
s.t() method takes the “s object” that was defined when
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.
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!
With power comes responsibility.
I know a (very capable) implementer who used the
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!
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!
s.pageName variable uniquely identifies content in Adobe Analytics. That means two things:
- Two different pages with the same
s.pageNameare treated as the sane content in Adobe Analytics.
- If you change the
s.pageNamefor 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.