Basic Tracking – Remix (contains Launch)

~ Jan Exner

I’m sure you remember the three prior installments of the “Basic Tracking” article series, don’t you? Basic Tracking from 2013, about a pure Javascript approach, Basic Tracking – Remix (contains DTM) in 2015, about the more modern tag management approach, and Basic Tracking on AMP Pages in 2018, about the beautifully weird and somewhat limited approach on AMP sites.

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.

Basic Tracking

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”.

[screenshot]
Find your embed code (not ‘xyz’!)
[screenshot]
Copy embed code
Note: the toggle on the overlay only changes the embed code — all it does is add “async” to the <script> tag. The actual Javascript code delivered by Launch doesn’t change.

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.

Basic Configuration

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.

[screenshot]
Analytics Extension configuration
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 s_account in Javascript, of course.

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:

[screenshot]
Create “Pagename” Data Element
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.

[screenshot]
Alternative: use a “Custom Code” Data Element
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:

  1. A Rule that sets the pagename for Analytics, and
  2. 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.

[screenshot]
First Rule: Event “Library Loaded (Page Top)”
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.

[screenshot]
First Rule: Action “Set Variables”
Once done, the Rule should look like this:

[screenshot]
“All Pages – load” Rule
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.

[screenshot]
Second Rule: Event “Dom Ready” and Order
Use the “Send Beacon” Action from the “Adobe Analytics” Extension, with proper tracking (s.t, not s.tl).

[screenshot]
Second Rule: Action “Send Beacon”
The complete second Rule looks like this:

[screenshot]
“All Pages – track” Rule
We’re done with the setup.

Publish

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.

[screenshot]
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.

[screenshot]
Library name, environment, and contents
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.

[screenshot]
Save & Build Library
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.

[screenshot]
Library compiled successfully
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.

Simples.

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.

Published by Jan Exner

German expat living in Switzerland (formerly UK and France). Consultant and member of the Multi-Solutions Group at Adobe, working with the Digital Marketing Suite. Father of 4 girls.

15 thoughts on “Basic Tracking – Remix (contains Launch)”

    1. Uh, good point!

      In all my test, it always has happened in that order, but you are right, of course.

      So using “Library Loaded (Page Top)” for tracking, too, should work. Any other constellation should probably be thoroughly tested.

      Thanks!
      Jan

      Like

      Reply

      1. It is that when you decide to go async, you really have to think this through. It is not just about adding the async attribute to the main library and doing the rest the same way. I also guess that there is some work to be done by the Launch team to properly communicate how to support full async in Third Party Extensions, because I believe that you need to cope with callbacks (and/or Promises / async-await) if you wan to do this properly.

        Like

      2. You’re right, as usual.

        The Extension doc refers to Promises a bunch of times, too.

        I wonder whether there is a point where the dependencies within an Extension become too complex, or whether the relatively simple architecture (Events / Conditions / Actions, that’s it) will push people to keep it simple.

        Like

  2. Pingback: Basic Tracking – Angular SPA & angulartics2 – Web Analytics for Developers

  3. hello
    Setting a rule order is not of help here. Because rule order only comes into picture when the event
    type is the same.
    I have found having a second rule unnecessary delay sending a beacon.
    We dont require aggregation in any case – as long as you fire beacons it should be okay. Let me know your thoughts.

    Like

    Reply

    1. Hi Chetan,

      Rule order does help, at least the way I do it. I do indeed use the same Event Type for the two Rules.

      One thing to think about would be maintenance. Having two Rules means you _can_ at any point aggregate, while having single Rules means your overall setup is simpler. As you know I like simplicity, and so I’m totally with you: if you’re sure you will never aggregate, then your way is perfectly fine.

      Cheers,
      Jan

      Like

      Reply

      1. Hi Jan

        Can you please provide a few use cases wherein you would recommend aggregating ?

        Dom ready – page views and send beacon
        Click on specific elements like CTAs or Shop Nows – set evars and send beacon

        I am not able to understand why I would aggregate.

        Thanks

        Like

      2. Let’s take your example of a page load, using DOM Ready.

        1. Rule (Order 50) sets all sorts of variables that are important on _any_ page, such as the pageName, language, event1, and some others.

        2. Rule (Order 5000000) sends the beacon, again on _any_ page

        So far so good, but on my blog articles, I’d like to track additional stuff, like tags, author, days since publish, so

        3. Rule (Order 100) sets those variables. It also has a Condition that checks whether the current page is indeed a blog article.

        I use this setup because a) I believe in DRY, and b) I believe that sooner or later, I will want to amend any setup.

        Liked by 1 person

  4. Pingback: Adobe Experience Platform Mobile SDKs – Analytics – Web Analytics for Developers
  5. Pingback: What is “s_code.js”? Do I have to know? – Web Analytics for Developers
  6. Pingback: In Search of the Simplest, Useful Analytics Setup – Web Analytics for Developers
  7. Pingback: Obscure References – Web Analytics for Developers

Leave a comment

This site uses Akismet to reduce spam. Learn how your comment data is processed.