Well, today we’ll do basic tracking using “Launch, by Adobe”, the designated successor of DTM.
As you might expect, there are a lot of similarities between this article and the one with DTM from back in 2015. There are, however, some notable differences, due to the way Launch works.
The world has advanced in the last three years, and so has tag management.
First thing to do is to include Launch into your pages. This is just as easy as it was with DTM.
You can choose to embed exactly like you did with DTM, or you can embed asynchronously. Let’s go for async, it is the way forward and makes sure your pages load as quickly as possible.
So, this goes into the
<head> of your pages:
<script src="//assets.adobedtm.com/launch-xyz.min.js" async></script>
Note: yours will have some hex numbers in place of the “xyz”.
Note: the toggle on the overlay only changes the embed code — all it does is add “async” to the
There is no code to put at the bottom of the page if you deploy async, of course.
And just like in all the other posts, let me point out that at this stage, we have all that we need for basic tracking, but a data layer with some additional information would be helpful.
In Launch, the basic configuration includes:
- creating a Property (for web),
- adding and configuring the Adobe Analytics Extension,
- creating a Data Element for the pagename, and
- adding and configuring two Rules
I don’t want to go into too deep an explanation of Extensions, Data Elements, or Rules at this point. If you feel the need to catch up, refer to the Basic Tracking – Remix (contains DTM) article from 2015.
For now, we’ll keep the configuration of the Adobe Analytics Extension simple. All we’ll do is specify the Report Suite(s) — three of them in Launch.
Launch does not pull Report Suite IDs, so I just simply copied and pasted them. In a real world deployment, I’d use Data Elements.
Setting the Report Suite IDs in the Analytics Extension is the equivalent of assigning a value to
Data Element & Rules
Next we’ll create a Data Element that provides a pagename, the identifier of any page that we track.
Move to the “Data Elements” tab, click the “Create” button.
If you have a CEDDL-compatible data layer, your Data Element will be pretty easy, like this:
If you do not have a data layer, you can instead create a “custom code” Data Element, and the code you provide must compute a pagename, maybe based on the URL.
Next step: Rules
This is where Launch is different. DTM had so-called “Page Load Rules”, which were built for the “browser has just loaded this page, here are things to do” use case.
Launch has a single Rule type instead of three, but through different “Events” and the “Order” parameter is a lot more flexible.
For our basic tracking, we’ll create two Rules:
- A Rule that sets the pagename for Analytics, and
- a Rule that fires the Analytics tracking call
I love you, my dear readers, and I know some of you are spectacular nitpickers. I would expect nothing less of you! I mention that here to let you know that your most burning question/remark/nitpick will be addressed in a PS at the very end of this article: “You could do this with a single Rule, right?!”
Create the first Rule, call it something like “All Pages – load”. As the trigger, select “Library Loaded (Page Top)” from the “Core” Extension.
Add an “Action” to the Rule, select the “Adobe Analytics” Extension, then choose “Set Variables”.
In the UI on the right, you can assign Pagename to the “%Pagename%” Data Element.
Once done, the Rule should look like this:
Note: triggering this Rule at “Library Loaded (Page Top)” works fine if your “Pagename” Data Element can be set at that point. Specifically, either your data layer has to be ready before you load Launch, or your DE has to rely on stuff that is ready, such as the page URL. The alternative is to use a different (later) Event, such as “DOM Ready”. Make sure the Event in this Rule happens before the Event in the second Rule!
For the second Rule (let’s call it “All Pages – track”) use the “DOM Ready” Event and set the “Order” to some higher value, such as 5000000.
Use the “Send Beacon” Action from the “Adobe Analytics” Extension, with proper tracking (s.t, not s.tl).
The complete second Rule looks like this:
We’re done with the setup.
Publishing is another thing that is handled differently between DTM and Launch. While in DTM, all changes went straight into the “staging library”, in Launch we explicitly build a new development library, and we choose the changes that should be part of it.
You can still use the handy Switch plugin in Chrome to test things, of course, and you should.
So, to test what you have done so far, head over to the “Publish” tab, then use the “Add New Library” button to create a new library.
When you create a library, you have to give it a name. You can also choose to directly select a dev environment (where you can later test it), plus you select what should be part of the library.
For now, use the “Add All Changed Resources” button to add everything you need.
Next, hit the “Save & Build for Development” button to kick off the build process.
After a bit of time, you should see a card that shows the name you typed for the library, and a small green dot next to it to indicate success.
Now you can head over to your site and use the Switch plugin to select your Development library.
If everything works fine, go through the publish process (which we won’t explain here, because official doc does it well).
And we’re done.
The following part has nothing to do with the basic tracking use case, feel free to ignore it.
If you are, however, interested in why I chose to create two Rules instead of a single one, read on.
Why 2 Rules?
IMNSHO nitpicking is a good thing in our line of business. Or maybe nitpicking combined with a certain thirst for understanding things.
So let me explain why I chose two Rules.
In DTM, it was possible to create a Page Load Rule that would fire on every page. That PLR would set common “variables”, such as the pagename. On some pages, it would also be the only applicable Rule. On top of that, you’d build PLRs for specific pages, e.g. the product detail pages on retail web sites, or blog article pages, or any other pages. These PLRs would set additional “variables”, and it was DTM that sorted out which PLRs it had to run.
Crucially, DTM held back on firing the Analytics tracking call until it had handled all PLRs, meaning PLRs would sort of aggregate.
Launch doesn’t do that at all. It is your responsibility to tell Launch to fire the Analytics tracking call at some point.
You can absolutely create a Rule that sets Analytics “variables”, then fires the tracking call. Launch allows you to specify multiple “Actions” in a single Rule.
But if you do that for Rules, you loose the ability to aggregate!
Or, the other way round: if I create a Rule that fires the Analytics tracking call, maybe using a “DOM Ready” Event, and if I set the Order on that Event to a high number, then I can add as many other Rules as I want for setting “variables”, and they will all be handled before the one that causes tracking.
Ok so far?
But why don’t I start with a single Rule that sets all standard “variables” and fires the call?
Well, I’d like to be able to overwrite some of the standard “variables”, which means I need to be able to put Rules between the standard setting of “variables” and the firing of the tracking call.
Also, I must resist the “for this example, we did blabla. Please don’t do this in real life!” shortcut at all costs. It’s sloppy.