With Launch, you don’t need doPlugins! – Part 4

Wait? What? How can this be part 4? Where are parts 1 through 3?

I am very liberally counting things, disregarding slight differences in titles, and tools, so the previous parts are:

1. With DTM you don’t need Plugins! – Part 1
2. With DTM you don’t need Plugins! – Part 2
3. With DTM you don’t need Data Elements

Behind all these articles hides my ultimate goal: deploy Analytics in a way that is as simple as possible (KISS), as lightly customised as needed (customisation, in general, is evil), and still as powerful as possible.

I believe that a tag management system is the enabling technology that will allow me to get there, and I am pretty sure that Launch will get me a lot closer to that goal than DTM.

Btw, Discussion – Customize Analytics in DTM falls into the same category, and I am by now sure that Jenn hasn’t responded because I am right. Ha!

Towards Standards

The articles listed above show that it is possible to replace some old-ish ideas and mechanics with built-in functionality. They are all working with DTM.

Now that we have Launch, I suggest we forget about little things and go big: let’s try to deploy Analytics without touching s_code.js or AppMeasurement.js at all. Let’s not customise those, and let’s absolutely try to get rid of the s.doPlugins() callback. Let’s, in fact, limit our use of “Custom Code” to Data Elements, only.

Tall order? Maybe.

But the rewards are too compelling, too great to be ignored!

Customisations are evil because every little thing that is customised trails in its wake future issues or at least effort. Sometimes customisations can stand in the way of making things better. A potential migration, say from DTM to Launch, would be just one example off the top of my head.

Stay close to standard functionality, and your life is going to be easier.

But… you say, but what about all those cool things I want to do?

Well, do them!

Do them in a way that is simple, using what the tools can do. And know that some customisations are more evil than others.

Personally, I think using customised code for Analytics is neither necessary nor desireable.

Example: Report Suite IDs

Report Suite IDs are important. They tell Analytics where to put the data.

In the olden days of embedding Javascript code we either specified the s_account variable, or we used the “dynamic report suite ID” functionality in the s_code.js file.

Then came DTM, and we either simply specified Report Suite IDs in the Analytics Tool, or built some custom logic with s.sa() and Data Elements (to cite Gary Oldman’s character in The Fifth Element: “my favourite”).

Launch (, by Adobe) went pretty much all in on the concept of using Data Elements, and the Analytics Extension in Launch allows us to use Data Elements for the Report Suite IDs, which is great, because it eliminates the need for Custom Code anywhere except in the Data Element(s).

This is what I have in mind when I say “using what the tools can do”.

It is certainly possible to use some Javascript code somewhere in one of the many Editors in DTM and Launch, but if there’s an ootb way, I’d always prefer that.

No doPlugins – Manual

Next challenge: let’s eliminate the doPlugins method altogether.

Not familiar with doPlugins? Read The s_code.js file – s.doPlugins() while I wait. Or, if you are in a hurry: The doPlugins method is executed like a callback whenever Analytics thinks something worth tracking might happen. That includes page loads, but also clicks on links or even white space.

I still think that doPlugins is was “spectacularly useful“, but I also think that nowadays, we can do better.

What we (used to) do in doPlugins falls into two categories:

1. at page load, and
2. on user interaction

In both cases, the Analytics core Javascript code calls s.doPlugins(s) just prior to actually sending the tracking call.

What do we need in Launch to do something like that?

Turns out very little.

The doPlugins() method itself can be emulated with a Rule, or a bunch of Rules.

Launch has a “Direct Call” Trigger in the Core Extension that works somewhat like DCRs in DTM. The difference is that you can use a Trigger multiple times, i.e. call multiple Rules with a single _satellite.track() statement.

So, you have a choice:

• Create one Rule that does all the things that your doPlugins used to do, or
• create a bunch of Rules that each do part of what doPlugins used to do.

Configure the Rule(s) to use a “Direct Call” Trigger, and give that trigger a good name (like “doPlugins”).

Note: this Rule or these Rules will contain “Set Variables” Actions from the Analytics Extension, but under no circumstances do you want it/them to contain a “Send Beacon” Action!

Instead, you find all existing Rules that have a “Send Beacon” Action, and change them so that before the “Send Beacon”, they have a “Custom” Action, which is nothing but a single command in Javascript: _satellite.track("doPlugins");

And we’re done.

The big drawback: if you have a lot of Rules with “Send Beacon” in them, this is a lot of work.

No doPlugins – Semi-automatic

So let’s make this easier. A lot easier.

In order to replace a custom doPlugins method with a Rule, all we have to do is:

1. Replace any existing doPlugins method with the code below
2. Create a Rule called “doPlugins” as below
3. Make Data Elements that mirror plugin functionality

Here is the code for the new doPlugins method, to be pasted into the “Customize Page Code” editor in the Analytics Extension.

function s_doPlugins(s) {
    _satellite.track('doPlugins', s);
}
s.doPlugins = s_doPlugins;
s.usePlugins=true;

Then we create a Rule that listens to that Trigger.

As said above, the Rule must be built using the “Direct call” Trigger provided by the Core Extension, like so:

The rest of the Rule is unspectacular, but one thing is crucial, and so I will repeat it: You must not add any “Send Beacon” Action to this Rule! That would lead to an endless loop, likely breaking your site.

Note: except for passing s into the Rule, this technique works perfectly well with DTM, too!

No doPlugins – Automatic

The real solution™, of course, would be for the Analytics Extension to provide a Trigger that would work just like trigger instead of doPlugins.

I submitted a request on the forum: Analytics Extension should provide a “doPlugins” Trigger, feel free to vote that up.

Or someone could write a Launch Extension. Anyone? Bueller?