Launch – Concepts

I could have called this article “Launch – WTF???” instead, and maybe I should have. This is a quick and brutal journey though the most important concepts you need to know when you start using Launch.

Tag Management

Let’s start from 0.

A “Tag Manager”, “Tag Management System”, or simply “TMS” is a tool that is embedded into your web site, and that usually provides a graphical UI in which people (sometimes marketers) can manage marketing tags, pixels, or whatever you call those.

Examples of those tags include Analytics, Target, remarketing pixels, and many more.

There are a number of TMS our there. The guys at ObservePoint have written a helpful article on 10 Tag Management Solutions You Should Consider Today, and the Tag Management System Comparison: Know Your Options! on Blast is helpful, too.

And to address the one big question right away: a TMS will not “set you free” from having to work with Dev/IT. It’ll give you a lot of leeway and can spectacularly improve the life of marketers, but only if marketing and Dev/IT work together. Simply ignoring Dev/IT will not work!

Tags

A TMS is called a TMS because it manages “tags”. Again, examples of those are analytics code, A/B testing, remarketing pixels, you name it. If marketing wants it in a page, chances are it is a tag.

In the pre-TMS days, marketing tool vendors would send the marketers some HTML code, and that could had to be added into the pages. Your friendly marketer would come to you, the developer, and ask you to put it in. You’d then prioritise, build, test, and eventually release.

With a TMS, this can be done mostly by the marketers themselves, provided the tag doesn’t need any information in the page. The marketers would then also have to test, and ultimately release the tag via the TMS.

In an ideal scenario, the TMS would already know how to deploy the tag, and so it would just provide a configuration screen, where the marketing team would set their ID and similar things. Much safer.

Launch comes with the concept of “Extensions”, which are essentially pre-built tags. It also allows people to write Extensions, and the hope is that, eventually, almost all marketing vendors’ tags will be available as Launch Extensions.

But first:

Rules

A TMS has to know when and where to put tags.

Examples:

• an Analytics tag should be present on all pages. The information transfered on that tag should be different for different types of pages (product page versus confirmation page versus …)
• a remarketing pixel for a specific campaign should be inserted, but only on the campaign landing page
• a conversion tag for an A/B test should record when the visitor converts (whatever that means for this specific A/B test)

With Launch, you create “Rules” for that.

Rules usually contain “Actions”, such as “Track this in Analytics!”, “send this remarketing pixel!”, “inject code for the A/B test!”, or anything else.

Extensions can define Rule Types. As an example, the “Adobe Analytics” Extension provides an Action that allows you to send a tracking call.

So far, so good.

When does that Action happen?

Well, that is up to you.

Rules can have one or more “Events”, which you could call triggers, as well.

If I configure a Rule to do something when the browser signals “DOM Ready”, then that’s what it will do. If I configure a Rule to do something when a visitor clicks a specific element, then that’s what will happen.

But we’ll get to Events, later.

A Rule can also have one or more Conditions, which essentially tell it “yes, do it”, or “no, not this time”.

There are some built-in Conditions, and again, Extensions can provide their own.

Rules make the team work

The combination of Events, Conditions, and Actions is very powerful.

A Rule defines exactly what that combination is. The Rule is the project manager, so to speak, it coordinates the team effort done by Events, Conditions, and Actions.

When I make a Rule in Launch, I tell Launch precisely what to do in response to something happening, and whether there are any constraints. Actions happen as a result of Events, but only if the Conditions are good.

This is so powerful that I will always try to avoid coding any of the above in custom Javascript (see 2019 Challenge: No Custom Code).

I would even state that using the doPlugins callback is no longer a given staple of an Adobe Analytics deployment. On the contrary: you’re on the right path if you don’t have it.

Data Elements

Analytics is all about sending data, analysing data, and making good decisions based on the analysis.

The aforementioned Adobe Analytics Extension, as an example, provides an Action Type called “Set Variables”, which we use to tell Launch exactly what data to send into Analytics.

Where does that data come from? Well… maybe from a data layer. Maybe from somewhere else, I don’t know. This is the first reason why Data Elements are helpful.

An implementation partner, or you (the developer) can create a Data Element — say “Page Language” — that will contain the language of the current page. How the Data Element determines what that language is, is completely hidden away, and whoever uses Launch to track that language, doesn’t really care, anyway.

The second reason why Data Elements are helpful: they can be used in the Launch UI, when we create Actions (or Conditions or Events), and they are placeholders.

If we build a Rule for Analytics, and the language of the current page is something we want to track, we can use the Data Element (called “Page Language”) in our “Set Variables” Action, rather than having to write “en” into the Rule (and consequently having to build one Rule per language!)

I guess I don’t have to explain how useful placeholders are, do I?

Actions

Reminder: Rules can contain one or more Actions, such as “Send an Analytics Beacon”, “Load Target”, or “Render this 3rd-party pixel into the page”.

Actions are things that happen.

Launch (or rather the Core Extension) comes with a plethora of Action Types, and Extensions (such as the one for Adobe Analytics) can define even more Action Types.

Compared to DTM, where Actions were somewhat implicit (a Page Load Rule would fire an Analytics beacon if the Analytics Tool was configured, as an example), Launch has absolutely no built-in Actions. It is completely up to the person working in Launch to make all the magic happen.

The big plus: more flexibility

For once, a Rule can contain multiple Actions, and those Actions will happen in the order they are shown in the Rule.

Secondly, your site’s pages might not simply be HTML that loads static content, and so Launch gives you more control about tracking things than DTM ever did — you don’t have to track a page at load time.

One fun Action Type I’d like to mention is the “Custom Code” Action Type, provided by the Core Extension. This one allows you to add Javascript code, and the Action will essentially execute that code when the Rule triggers.

This is very good for quick additions to your site, like 3rd-party pixels. I would recommend using pre-built Action Types in the long run, though, so you don’t have to maintain that custom code. (Yes, I’m telling you to build an Extension.)

Events

Reminder: Events are how Rules know when they need to do something, or when Rules are triggered.

There is quite an impressive list of Event Types built into Launch (or rather, into the “Core” Extension), and, again, Extensions can provide their own Event Types, too.

Note that Rules are dumb, in the sense that whenever the trigger happens, the Rule will fire.

Here is an example that hopefully illustrates that point:

If we were in a meeting, and you said: “Jan, can you tell me if Launch is a TMS?”, I would answer: “Yes, it is.” And if you said the same thing, again, and if I was like Launch, I would answer the same thing, again. Over and over.

The fact that you say “Jan, can you tell me” would be a trigger, and I have this built-in Rule that says “if someone asks you a question, do the polite thing: answer!”

In real life, I am not like Launch, and I would raise an eyebrow and look at you in a weird way, if not the second time, then clearly the third time you said it. Like most humans, I have some situational awareness built-in.

You can build the same in Launch, using “Conditions”.

Conditions

The way Launch uses Conditions is essentially like this: when a Rule has been triggered (by an Event), it’ll do one more “go / no-go” check. The check looks at any Conditions that may be part of the Rule, evaluating them one by one. Only if all Conditions return true will the Rule do whatever Action or Actions it has.

You know the drill by now: the “Core” Extension comes with a good list of Condtions for you to use, and Extensions can add their own Condition Types, too.

Jim Gordon has written an Rule Conditions Guide, if you’re interested..

Extensions

This is the big difference between DTM and Launch, if you ask me: Launch can be extended! And you don’t have to be Adobe to extend it.

Everyone can write what is called an “Extension”.

An Extension contains Javascript code. That code can provide new Action Types (such as “send a pixel to my cool retargeting tool”), new Event Types (such as “when Visitor has scrolled 50% of the page”), new Condition Types (such as “only on Tuesdays”), new Data Element Types (such as “Constant Data Element”), and even code that can be shared with other Extensions, so-called “Shared Modules”

The vision of Marketers being able to manage practically everything in the UI has come a big step closer to reality, because you, the developer, can write an Extension for pretty much anything your friendly marketer would want to do.

Yours truly, thinking this is absolutely cool, has written a bunch of Extensions, and there will likely be more.

Libraries & Environments

With DTM, when you saved something, the backend ran a compiler and created what DTM calls “staging.” When you subsequently approved and published, the compiler would create “production”, the code that would eventually be delivered with your site.

Launch changes that approach. Rather than having staging and production, Launch has multiple Libraries. You still have “production”, there is also a “staging” Library, but you can also have multiple “development” Libraries.

“Multiple development Libraries?”, you ask, “what for?”

With Launch, saving a change you made doesn’t mean the compiler takes it and starts building. Instead, you can choose wich changes you want to add into a Library.

So, multiple people can work in Launch, in the same Property, on different aspects. Each person can have their own dev Library, and noone steps on anyone else’s toes.

Cool, no?

Whoever thinks their changes are fit for production, submits their Library for approval. An approver can then build the Library (which makes it available on staging), test, approve. A person who has rights to publish can then publish it to production.

The process is more complex than with DTM, but it helps for teams.

And the real biggie: Libraries live on “Environments”, like they did in DTM. While DTM had “we’ll host it for you”, “you host it yourself”, and “we’ll push it to you via FTP”, and that was a Property-level choice, in Launch, you can specify Environments per Library.

It is therefore possible to self-host the production Library, but still have developers work on Adobe-hosted dev Libraries, which is much more convenient.

To self-host, or not to self-host

With DTM, I didn’t like self hosting, because it often meant someone else would have to “release” the library, and we were basically back to release cycles, which defeats a large part of the reasons for having a TMS.

It was also a bit of a PITA to develop with self-hosted staging libraries. I ended up using the Replace feature in Charles quite often.

Launch makes that easier.

I will set up my personal dev Library to live on the Adobe-hosted Environment, and while I’m building or editing stuff in Launch, I really don’t care about release cycles or IT involvement.

Self-hosting has a bunch of advantages, such as more control (e.g. over HTTP headers) and less DNS overhead, which in some cases outweighs the disadvantages (the code must somehow be pushed onto your servers).

These days, I’m agnostic.