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;

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:

doPlugins Replacement Rule in Launch
Event Configuration for doPlugins Replacement Rule
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?

6 thoughts on “With Launch, you don’t need doPlugins! – Part 4

  1. I still think doPlugins has it’s uses, as long as some suggested features aren’t implemented in Launch, like: https://forums.adobe.com/ideas/9600
    We have about 30 eVars some of them mirrored to props that should be sent with every rule within two different properties. So I created a js file in our source control (to have a diff view and code support of the IDE) where I added the plugins and all these eVars and props. For each release I copy its content into the custom code section of the Analytics Extension of the two properties and I am set.
    If the Global Variables of the Analytics Extension would also work for s.tl() I could move 80% of the eVars in my doPlugins there. Though with your idea I could probably combine this and have a rule triggered where I could use the GUI of Set Variables. But then again, some eVars would be set with the GUI and some with code and you don’t have an overview anymore.
    The only thing I am currently trying to figure out is to have a return at the beginning of doPlugins if it wasn’t an actuall tracking call but just a click on a text (as you investigated here: https://webanalyticsfordevelopers.com/2016/04/05/when-exactly-does-doplugins-run/). For Custom, Exit and Download Links I can check s.linkType but for s.t() I don’t have any indicator and would probably have some custom code in these rules that set a boolean. Or do you have a better idea?


    1. Hi Thomas,

      How do you set those “variables”? Why would some be set in custom code? Couldn’t you use Custom Code Data Elements and set all in the UI?

      In Launch, you can have an Analytics – Set Variables Action that is triggered on multiple Events. If you make that Rule set your 30 eVars, why would you still need doPlugins?



  2. It is really a puzzle to me why the Adobe Analytics Extension in Launch has “global variables” and “Custom Code” right on top of each other, and “global variables” get set on every Hit. But Custom Code only gets executed on Pageviews.
    Executing that Custom Code on Event Calls as well would probably make s_doPlugins and this workaround you are describing (thanks, still better than setting all variables in every Event-based Rule again) completely useless.


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.