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:

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.


First of all, that was only half the truth. There is a second method that can send tracking into Adobe Analytics. It is called (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.


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!


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.

28 thoughts on “The s_code.js file – s.doPlugins()

  1. Pingback: The s_code.js file – Configuration | Web Analytics for Developers

  2. Pingback: The s_code.js File – Overview | Web Analytics for Developers

  3. Pingback: The s_code.js file – Plugins | Web Analytics for Developers

  4. Pingback: The s_code.js file – Core Javascript Code | Web Analytics for Developers

  5. Pingback: The Thank You Page – Tracking Purchases | Web Analytics for Developers

  6. Pingback: Versioning Your Tracking | Web Analytics for Developers

  7. Pingback: Tracking Apps vs Web Pages | Web Analytics for Developers

  8. Pingback: The s.abort Flag | Web Analytics for Developers

  9. Pingback: Tracking w/o Javascript | Web Analytics for Developers

  10. Pingback: Redirect Tracking | Web Analytics for Developers

  11. Pingback: How to track the ‘Like’ button | Web Analytics for Developers

  12. Pingback: How to Use Merchandising Variables | Web Analytics for Developers

  13. Pingback: A Short History of Processing a Hit | Web Analytics for Developers

  14. Pingback: Visitor IDs & Visitor Profile | Web Analytics for Developers

  15. Pingback: TDD for Analytics, please | Web Analytics for Developers

  16. Pingback: Tagging Forms (w/o Losing Money) | Web Analytics for Developers

  17. Pingback: With DTM you don’t need Plugins! – Part 1 | Web Analytics for Developers

  18. Pingback: Quick Tip – One s_code.js for Multiple Sites | Web Analytics for Developers

  19. Pingback: Plugins: New/Repeat vs VisitNum | Web Analytics for Developers

  20. Pingback: Reference – DTM Load Order | Web Analytics for Developers

  21. Pingback: DTM and the doPlugins Callback | Web Analytics for Developers

  22. Pingback: The s_code.js File – Where is it now? | Web Analytics for Developers

  23. Pingback: DTM – How to Amend an Existing Analytics Setup | Web Analytics for Developers

  24. Pingback: How to monitor campaign performance in the Real-Time reports | Web Analytics for Developers

  25. Pingback: When exactly does doPlugins run? | Web Analytics for Developers

  26. Pingback: Discussion – Customize Analytics in DTM | Web Analytics for Developers

  27. Pingback: Bad Data – Prevention & other Aspects – Web Analytics for Developers

  28. Pingback: With Launch, you don’t need doPlugins! – Part 4 – Web Analytics for Developers

Leave a Reply

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

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