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…

[Screenshot]

Output of notify in Chrome

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.

[Screenshot]

Editor for Custom Lib Code

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

[Screenshot]

Editor for Custom 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:

[Screenshot]

Code Sample

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

 

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 DTM, Plugins, Principles
5 comments on “DTM and the doPlugins Callback
  1. […] I mentioned about a month and a half ago, the s.doPlugins() method is alive and well, even if you’re using a […]

    Like

  2. […] let’s see: DTM does actually execute the PLRs… we also still have the s.doPlugins method… […]

    Like

  3. […] _satellite.settings.isStaging attribute, or whatever else is needed, then computes an rsid. Make a doPlugins method and in there, use s.sa to set the rsid. Much more […]

    Like

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

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

%d bloggers like this: