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.

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.

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, Plugins
26 comments on “The s_code.js file – s.doPlugins()
  1. […] definition of a useful callback method called […]

    Like

  2. […] Most retailers use “scAdd”, “scOpen” and “scView”. Very few use “scRemove”. It is good practice to set “scOpen” in the s.doPlugins() method in the s_code.js file. […]

    Like

  3. […] definition of a useful callback method called […]

    Like

  4. […] web sites, you can very easily track this, see Email Tracking. The automation in the s.doPlugins() method makes it an integral part of the […]

    Like

  5. […] that is a good idea?), as much of the work done by Javascript code as possible should sit in the s.doPlugins call back method. And this is where you would use […]

    Like

  6. […] variables that would usually be set within the doPlugins method in the s_code.js […]

    Like

  7. […] “normal”, Javascript-based tracking (plus plugins), tracking w/o Javascript, tracking links & actions, tracking apps, Context Data & […]

    Like

  8. […] let’s treat it that way, grab the fb_ref parameter using the getQueryParam plugin within the s.doPlugins method in the s_code.js […]

    Like

  9. […] eVar to “search” on the results page. You might even be able to do that in the s_doPlugins() method in the s_code.js file. Check where you are setting the “Searches” event (usually event1 […]

    Like

  10. […] next step is for the core code to call the s.doPlugins callback which allows you to automate things that should happen on every […]

    Like

  11. […] time when they land. You store that in the s.campaign “variable” (or rather a plugin in s.doPlugins() does that […]

    Like

  12. […] are multiple points that tests could hook into. The simpler tests could look at (or live in) the doPlugins method in the s_code.js file, whereas more involved scenarios would have tests that looked at the […]

    Like

  13. […] rolling your eyes now, then you might have forgotten about the developer’s best friend, the s.doPlugins […]

    Like

  14. […] in the s_code.js file make it more difficult to move to DTM. If my s_code.js had no plugins and no doPlugins method, it would be much simpler to remove it from my page code and load it via […]

    Like

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

    Like

  16. […] getVisitNum plugin is exactly as hard or easy as that of the getNewRepeat plugin. Both go into the doPlugins section, both are fairly small, both use a single […]

    Like

  17. […] reason for that: this code works a lot like the old doPlugins() method, it gets called just before the tracking request fires. And if you look closely, you can see the […]

    Like

  18. […] If you have ever worked with Omniture SiteCatalyst Adobe Analytics before, you will have come across the spectacularly useful s.doPlugins() callback. […]

    Like

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

  20. […] don’t we copy all the values from DTM into the page-level s object using the s.doPlugins […]

    Like

  21. […] steps mentioned above can be easily handled by changing the doPlugins() method. Which is good, […]

    Like

  22. […] a refresher, the doPlugins method is defined inside the s_code.js or AppMeasurement.js file. It is a callback method that […]

    Like

  23. […] that you’re moving to tag management, and you have so many useful lines of Javascript in your s.doPlugins() that it’d take ages to rebuild everything properly. So you’d rather just transport it […]

    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,377 other followers

%d bloggers like this: