When exactly does doPlugins run?

In a meeting a couple of months ago, André Urban (a seasoned colleague of mine) and I got into a sudden and unexpected argument about when exactly s.doPlugins is called.

I was convinced it was called as a result of calling either s.t() or s.tl(), while he says it was also called everytime a visitor clicks anything on the page.

Funny enough, he was able to show me on a simple page.

Since this was completely against what I thought I knew about how the darn thing works, I decided to dive into this a bit deeper. Let’s see who was right!


As a refresher, the doPlugins method is defined inside the s_code.js or AppMeasurement.js file. It is a callback method that allows for a considerable amount of automation in your tracking setup.

Traditionally (as in: pre-DTM), we used it to put Javascript that would grab campaign tracking codes from URLs, call plugins, or do other useful things. Anything that would potentially apply to all pages on your site, we used to handle in the doPlugins method.

While most of this can be done directly in DTM (or whatever Tag Management System you use), there are still cases where you’d use doPlugins, the biggest one of those being a migration. It is so much easier to keep your doPlugins method when you move everything into DTM, than it would be to avenge it in DTM.

So, where do we start our investigation?

Use the Source

Step 1: let’s look into the code!

Call to doPlugins in H.27.5 s_code
Call to doPlugins in AppMeasurement
The good old H.27.5 code contains exactly one call to s.doPlugins. Given how the H-code is built, I am inclined to first look at the new 1.5.3 code, which is much more easily readable. The three occurrences I find in there contain a comment, a clause in an if-statement, and a single call.

Cleaning up the Javascript a little bit shows that the call sits within the t() method, and that tl() ultimately calls t(), too. Sounds like I was right!

Call to doPlugins in AppMeasurement (beautified)
Then again… I am assuming that t() & tl() only ever called explicitly, either on the page itself, or by some code injected into it. What if I’m wrong?

A short burst of hectic CTRL-F’ing shows me that there are indeed calls to track() inside the AppMeasurement.js file itself! What on earth?

But it makes sense.

Remember that you can configure whether you want automatically track exit links, downloads, and normal links for clickmap? Well, somehow, the code needs to be able to do that. And so it installs event handlers, and inside those, it calls track() (which is an alias of t()). Makes perfect sense, in fact.

I’m still thinking I’m right at this point. And I’m not going to go into all the methods that I find. Some of them are beyond my grasp. I’m not a programmer, after all.


So, let’s look at a page through the debugger or the Console.

We’ll make this easier by making a doPlugins method which outputs something into the Console:

function s_doPlugins(s) {
	// purely for testing purposes
	console.log("doPlugins has been called!");

Then we’ll load the page, maybe click on it a couple of times, and check the Console.

Call to doPlugins due to click
Oops… doPlugins does indeed get called when I click on the text!

So there are clearly circumstances under which doPlugins is called even though no actual tracking call is being made. Sounds like André was right, then.

Although I could still claim that because t() is called, I was “sort of right”, right? Right?

Also, setting


makes no difference!


I don’t like finding out that something I took for granted for years was utterly wrong. So maybe this is an AppMeasurement.js thing? Maybe the old H-code did/does it differently? Let’s test…

No call to doPlugins
Ha! It does not call doPlugins on clicks!

This is a very good illustration of why it is dangerous to trust an expert, isn’t it? Some experts (like my colleague André) keep up with the changes and adjust their internal model, while others (like me in this case) don’t.

Actually, I suggest that experts shouldn’t trust themselves, ever. Always go back on your assumptions and your experience when you work with technology!

Update: André can easily reproduce the “doPlugins called everytime” behaviour with H.27.5 code, so this is even more a reason to double-check on your deployment! Seems like we haven’t found out exactly what is going on, yet.

Update 2017-08-14: The behaviour is normal and “works as designed”. Just want to document that here (because it came up on a project recently 😉 )

4 thoughts on “When exactly does doPlugins run?

  1. Yes I experienced same behavior doPugins calling everytime when there is a interaction on the page 🙂


  2. If you add the s_code into the body, it will add an onclick to the body (s.bc) and thus capture any click on any link and(!) whitespace. This handler is added to detect downloads, exit links, etc.
    If the body is not yet available (since you have the s_code in the head) it will add onclick handler to any link once the page has finished loading.
    Be careful with your test-page, it’s only 1 line long and thus the rest of the whitespace is not part of the body.

    Code in doPlugins can be pretty tricky since it’s executed more often than you think.


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 )

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.