Nitpick: Launch does not support Page Load Rules

I was reading Jim Gordon’s excellent article on Adobe DTM vs. Launch a while back. If you haven’t read it, do. It is excellent.

While reading it, I started to think about one aspect, and how I think there is an awesome opportunity for a nitpick in it: Jim (and most people I know) say DTM and Launch, by Adobe both support Page Load Rules.

It is totally true that with Launch, you can make Rules that fire when pages load, no doubt about that, but …

DTM — Automatic Tracking & Multiple Rules on a Trigger

DTM had has some embedded logic geared towards making tracking of pages as easy as possible but still flexible enough so you can have multiple PLRs fire on a page that sort of “stack up”.

The generally accepted way to set up Analytics tracking with DTM is to have a somewhat generic PLR that fires on all pages and sets the important “variables” that all pages provide (such as s.pageName, see Basic Tracking).

Then we create template- or page-specific PLRs that set more “variables” and events.

At the end, a normal DTM deployment can have anywhere between a couple of and dozens of PLRs.

The clever part is that DTM knows how to handle that situation seemlessly.

For each page load trigger (“Top of Page”, “Bottom of Page”, “DOM Ready”, and “Onload”), DTM goes through all the PLRs, sets everything as instructed, but only fires one tracking call!

There are flags in DTM that keep track of which triggers have already happened (e.g. _satellite.pageBottomFired), and the actual Analytics calls are only sent once per trigger.

It is possible to have more than one Analytics call happen on a page with DTM, but it is frankly not a situation that happens often. Most people decide on either “Bottom of Page” or “DOM Ready”, then fire all of their PLRs on that trigger.

(By the way: there is logic in DTM that if they haven’t run before executes all “Bottom of Page” PLRs by the time “DOM Ready” happens. This is your insurance against forgetting to put the _satellite.pageBottom() call into your pages!)

Launch — Complete Control

Launch doesn’t do any of that.

You have no PLRs at all. There is one type of Rule, called “Rule”. D’uh.

The possible triggers for Rules include the 4 above, so you can create Rules that fire at page load time, of course.

Launch also doesn’t automatically fire Analytics calls (or Target mbox calls).

And instead of handling “the aggregation of PLRs” for you, Launch comes with a concept of “Order”.

You specify a number in the Order field of each Rule, and Launch will execute all Rules for a specific trigger in order from smallest to largest.

As a result, the approach with the multiple PLRs that was cool in DTM, sort of doesn’t work like that anymore.

With Launch, you have to think about what the best time is for a specific thing to happen, then you make a Rule for it.

In my humble opinion, there are two valid approaches:

• Create one Rule for each page template, configure Launch to only ever use that one Rule on each page. No overlap.
• Create multiple Rules that do specific things (“Set general Analytics ‘variables'”, “Set product info”, “Fire Analytics call”), set the “Order” fields on each Rule, and fire them as needed.

I deliberately didn’t list those two approaches in a numbered list, feigning complete impartiality, but if you have read this blog before, you will know that I a) have an opinion, and b) will tell you what it is.

Here it is: Use the approach with the multiple Rules and the Order!

The “only fire one Rule per page” approach means you have to repeat stuff in a lot of Rules, such as setting the Page Name. Don’tt do that! DRY is an important concept!

I agree that getting tangled up in Rule Order can happen, and that having a single Rule per page is somewhat easier to understand (look at one Rule, understand completely what it does). Ok. But the second time you have to add a “Set Variable” action to a dozen Rules, you’ll curse yourself.

If you asked me to guess how a rumored migration tool would handle PLRs, I would say probably by simply copying them, then adding a “Fire Analytics Beacon” Rule that is set to fire on all pages and has a high “Order”. After the migration, you would likely want to go into the individual Rules and set Order to whatever makes sense for you. That would not be strictly necessary, though, since DTM didn’t allow you to specify order, and all your PLRs are therefore independent.

My preference is the same for Rules that fire on visitor activity.

I am currently editing a DTM Web Property where about 25 EBRs all set the same two eVars to the same two Data Elements, only we renamed one of the two Data Elements.

In Launch, I would have a Rule that fires on every click and sets those two eVars. Maybe even two Rules (“Set Language eVar on click” and “Set Pagename eVar on click”). There would be further Rules for specific clicks, of course, including one that sends of tracking.

Yes, there will be a lot of Rules. Better than repetition.

Also, this can (and hopefully will) mean the end of the doPlugins() method!

(Note that because the Launch team are a cool and crazy bunch, the numbers in the “Order” field can be negative, have decimals, and be pretty big. My “Now fire Analytics Call” Rule is usually a 50000. You can also make that one a 1, and have all other Rules populate the [0,1) interval, but that would be nerdy.)