DTM and the doPlugins Callback

Today, I’d like to tell you about a little gotcha I ran into.

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

The doPlugins callback is called every time the Analytics Javascript code has almost finished its job and is just about to send the tracking request off into the clouds.

What’s great about the callback is: it allows you to modify the tracking before it goes out. The most common use case for this would be everything that can potentially happen on any page of your site, like grabbing a campaign tracking code and tracking it.

Ok.

So now you have followed the crowd and moved over to a tag management system. You are no longer including the Analytics JS code into your pages or templates at all. The TMS handles that quite nicely. And let’s assume you are actually using DTM.

Here’s the big question: where does the code from s.doPlugins() go now?

And the funny thing is: I used to get it wrong until very recently. Well, not that funny. This post is a “note this down so I won’t forget it” post.

Where does it go?

My naive approach, based on the assumption that “hey, this is DTM, everything is done somewhere in the UI!”, was to use the editor under “Customize Page Code” in the configuration of the Adobe Analytics Tool.

My assumption was that this customized code would be called every time any rule would fire.

Let’s test that… let’s put a call to _satellite.notify() into that editor…

Unfortunately, it’s a negative. The code is executed on page load, all right, but not when I click the link on my test page, as you can see in the last 4 lines.

How had I never noticed that before?

The truth is that what we have the code do in doPlugins mostly matters on page load, and I therefore only ever saw things work just fine.

But if you really need something to work on each tracking call, you need to do it differently.

(Examples? Sure: a kill switch using s.abort, conditional choice of report suite ID using s.sa(), measuring “engagement” that takes into account actions on the site, …)

Good old doPlugins

You could put code into all of your relevant rules. Put something into your “Generic” Page Load Rule, plus all the Event-based Rules that matter for your particular use case.

Problem: for the first two use cases listed above, that would be every single rule. Not good. Guess how often you would forget to put it in…

The answer, of course is to use — wait for it — s.doPlugins()!

Shocker!

And where do we put it?

I think there are two places where it makes sense to define s.doPlugins(), both of them in the settings of the Analytics Tool:

1 — if you are using a custom library, just define s.doPlugins() where you define your custom library code.

2 — if you use the “Managed by Adobe” option, you should define s.doPlugins() in the editor under “Customize Page Code”.

In both cases, your code will be loaded on every page, leading to the s.doPlugins() callback being defined, which in turn means the base code will execute it on every tracking request.

Bingo.

Here is an example for use case 2:

Note lines 47 and 52! Don’t forget them!