Reference – Launch Load Order with an Extension

This article is a followup to Reference – Launch Load Order. That other one was, as I said, almost disappointingly simple. So simple, in fact, that it annoyed my friend Lukáš (one of my secret goals for 2019 checked off right there).

The article was that simple for two reasons:

1. Launch did away with a bunch of built-in logic, and instead does pretty much exactly what you tell it to do.
2. I wanted to keep it simple, and since I didn’t know how simple Launch is, I kind of aimed too low.

In retrospect, it’s no surprise that if you have a simple system, and you tell it “do A, then B, then C”, you get A, then B, then C.

The only reason why I did publish the article anyway was the behaviour of Rules with a “DOM Ready” or “Library Loaded” Event Type. These took me by surprise, and so I posted.

Now, back to today, and adding an Extension into the mix. I’m guessing this will still be pretty straight-forward.

With the explicit Rules in Launch, there is almost no reason to do this at all (compared to DTM), but from a point of view of an Extension developer, there are still a few mysteries.

Timer Test Extension

I built an Extension called “Timings Test”, published it (privately), and added it into my Property.

The Extension provides

• an Action Type,
• a Condition Type,
• two Event Types (triggering immediately and delayed),
• and a main module

All of these are dummies, in that they do not actually do anything. They only log their presence and usage to the browser console, helping me make my screenshots.

If you want to try this yourself, feel free to copy or fork the Extension, it is available on github.

Results

As in the other article, I created a Property, added the Extension, created Rules (one more this time, because of the two Event Types), then deployed, both sync and async.

Here are the results, sync left, async right

There is really not that much difference between the two screenshots, except that in an async scenario, everything happens later. Which is exactly the point.

Note that the time between initialising the delayed Event and it actually firing is the same (or pretty close) in both cases, meaning the Event Type will fire significantly later if you embed Launch asynchronously.

Note also that there are two additional lines on the left (sync), corresponding to the JS out put before and after the _satellite.pageBottom() call, which only exists in a sync deployment.

Other than that …

Analytics Extension

Fearing the wrath of Lukáš™, I decided to do one more thing: add the Experience Cloud ID Service, Target, and Analytics Extensions into the mix, again in sync and async deployment.

I used Data Elements where possible, and I made them all Custom Code, like this:

So, when queried, the Data Elements would log a message, helping us see in what order and when exactly they get queried.

I added a log statement to the editor under “Configure tracker using custom code”, too, of course.

Since Target doesn’t really log much into the Console, I also added 3 Custom Actions into the “Library Loaded” Rule, around the Target-related Actions.

And here are the results:

Noteworthy:

The Extensions for ECID, Analytics, and (presumably) Target are loaded before my Timings Extension.

Launch has logic that makes sure ECID does what it does before Analytics or Target are initialised. It seems that logic also puts custom Extensions after those.

If you load Launch async, all loading happens after DOM Ready, which is expected.

I put the “Set Variables” and “Send Beacon” Actions into the “DOM Ready” Rule, just after my custom Action from my Extension. You can see how the “Custom Page Name” Data Element is read just before Launch reports being done with the “DOM Ready” Rule. So, Analytics seems to be at least partly async itself! It looks as if it pushes the “Send Beacon” Action out a little bit.

My take-away from that: if I want to amend what the Analytics Extension does, I will write an Extension myself, one which uses the Analytics tracker object using promises. That should protect me against silly race conditions.

Typing all of this up, I noticed that I forgot to add a doPlugin() method into the mix. I won’t do that now, because I don’t expect it to change anything fundamentally.

There you go. Less complexity in Launch itself, some complexity in how Extensions are handled, and some complexity introduced by the Extensions themselves. Just what we expected.

Launch will not help you shoot yourself in the foot (like DTM did), but it is still powerful enough for you to be able to do so in a spectacular way.