Sunday, February 3, 2019

DTM to Launch Migration Tool Overview

There's a lot of buzz currently about upgrading from Dynamic Tag Manager to Launch by Adobe and there's a ton of good materials out there to help us plan and execute the migration successfully. Right off the bat, the three part series from 33Sticks comes to mind which I highly recommend you to read before this. My post will cover Adobe's migration tool which in my opinion provides a rather seamless method for upgrading to Launch. I'll share my experience with it and supplement the information that the Launch product team has already provided. I'm also not trying to provide a complete roadmap to migrate as there's already great content for it but I'm simply giving my opinion on this handy utility. Let's get started!

Overview

The migration tool is basically accessed by clicking the 'Upgrade to Launch' (highlighted in Red) button in DTM as shown below.

When you click this button, a popup will appear that shows you two check boxes and an 'Upgrade' button. The first checkbox allows you to use the same DTM embed code with Launch post migration. The second checkbox disables the existing property in DTM.

Once you click 'Upgrade', you'll see a brief message stating that the property is being migrated. Once that goes away, you'll see a link which will take you directly to the newly migrated Launch property. The new property in Launch contains the timestamp in its name as shown.

An important point to note is that only items that have been published in DTM will get migrated and anything that's unapproved in DTM will not get migrated to Launch. Here's a link from Adobe's documentation that covers what all will be migrated (Adobe Analytics, ECID, rules and data elements).

In case you want to migrate any additional rules that weren't previously migrated during the first round, you can migrate the property from DTM again. In my case, I forgot to publish a few rules in DTM that weren't migrated before so I ended up migrating the property again which added a second property in Launch with a different timestamp. Personally, I would recommend that you migrate just once and publish everything in DTM beforehand.

As far as the (migrated) rules are concerned, Launch creates a new rule to fire off an Analytics beacon (see below) in addition to the ones that get migrated.

Now that we've seen what the migration tool does, I want to share how I would approach a migration with this tool.

My Migration Approach

Before I begin, I want to share that I've upgraded a few clients using this tool as well as migrated clients by creating a brand new property in Launch. There's no hard and fast rule around which method to choose as both options will get you the desired results but if you have a very complicated Analytics set, the migration tool might be a better solution. Let's go through what my approach would be with the migration tool.

Treat this migration as an opportunity to do a cleanup of unnecessary data elements and rules and validate your data layer and tags in general.
Create a thorough launch schedule/plan to QA your staging environment and sure all tags are firing as expected. There's a lot of good material out there on how to build use cases and leverage QA tools & extensions to perform validation but that's a separate post for some other day but give this step the utmost importance.
Your launch plan needs to include a timeline of how long your tags will be tested in staging and when can they be pushed to production. I would typically give it about a month (depending on the complexity of your site) from when you begin testing in staging to when you can deploy Launch in production.
Make sure to publish all rules, data elements and tools in DTM that you want to migrate to Launch. As mentioned earlier, only Adobe Analytics and Experience Cloud ID Service tools will be migrated so other solutions such as Target or Ad Cloud will have to be created separately in Launch.
Click the 'Upgrade to Launch' button and do not select any of the checkboxes in the popup. The reason why I wouldn't select the DTM embed code option is because it's recommended to deploy Launch asynchronously which doesn't require the legacy pageBottom() call. As this call will have to be removed, there's no real advantage in keeping the DTM tag as you'll still need a release cycle to make this change. The other checkbox to disable the DTM property shouldn't be checked as you may need to go into DTM later.
Once the new (migrated) Launch property has been created, click into the property and do a quick sanity check to make sure all rules, data elements and the Analytics/ECID extensions have been copied over correctly. At this time, add any extensions in Launch that didn't get copied over from DTM such as Target. I've covered AAM separately in the last section.
Replace your existing DTM code hosted in your staging environment with the Launch embed code to begin your tag validation. Click the 'Environments' tab and copy the development script as shown below.

Test in staging and closely follow your migration plan. After meeting all your validation criteria, publish your new Launch property in production.

Audience Manager SSF Migration

If you had Audience Manager deployed via server side forwarding (SSF) in DTM, the AAM module will get copied over to Launch and the module will be present in the Analytics extension. My recommendation is for you leverage the in-built SSF integration for AAM inside the Analytics extension. Let's take a look.

Click 'Open Editor' in the Analytics extension.

Comment out the AAM module code in the library and save changes.

Choose 'Manage the library for me' option to let Launch host your Analytics library as well as automatically upgrade you AppMeasurement library. Also 'globalize' your Analytics object so that you can leverage the object elsewhere in Launch and in the browser console.

Finally, check the checkbox as shown below to enable the automatic AA->AAM SSF integration in Launch.

So that's a wrap. I hope you found this walkthrough helpful in case you decide to go with the migration tool but whatever approach you choose, it's imperative to have a sound migration plan and validation strategy.

Sunday, December 9, 2018

Fix Variable Stickiness on Click Events in DTM & Launch by Adobe

This post covers a fix for a very common issue where page load variables tend to 'stick' or 'persist' on the subsequent click event. I'm leveraging the clearVars() function and covering exit link tracking in this case but the same logic can be applied to other types click events too. We will cover this fix keeping in mind both DTM and Launch by Adobe so without any further delay, let's jump right in!

Overview of the Issue

Before we dive into the issue, we have to take a look at the HTML structure of our page. For the purposes of this post, I'm using my demo site as an example. In the screenshot below, we can see that all of our internal site links start with ".." and our external link pointing to http://www.adobe.com starts with "http://". We can use this distinction as a condition in our Tag Manager.

Here's an example of a page view call (from my test site) where we have a custom Page View event (event6) and an eVar (eVar3) to track the Page Name.

On click of an exit link, we see that event6 and eVar3 get carried over on the next call.

So, let's discuss how to fix this in both DTM and Launch by Adobe.

DTM Fix

Given that DTM is still a populate Tag Manager that will eventually be sunsetted, it makes sense to cover how to resolve this issue in this TMS.

The first step is to disable automatic exit link tracking in DTM. We do that by unchecking the "Track outbound links" checkbox in the Adobe Analytics tool.

The next step is to create an Event Based Rule tied to the anchor ('a') element with the event handler of 'click'. The reason we do that any link on the site can be an exit link so it makes sense to simply look for the presence of an anchor link.

The next step is to disable any tracking under of the Adobe Analytics section.

The final step is to add some custom code to fire our own exit link tied to the exit link starting with "http" (covers both http: and https:) where we only include eVar3 (Page Name) as part of our exit link call along with the exit link URL passed to the s.tl() call. Note that I'm using s.clearVars() to remove the extra event6 from my call.

Once published, we can see that on click of the exit link, we're only seeing eVar3 being passed but no longer seeing custom event6 being populated in the image request.

Launch By Adobe Fix

Now, let's take a look at how to tackle the exact same issue in Launch by Adobe. Given that Launch has an in-built action for clearing variables, we will leverage that instead of passing it in the custom code.

The first step is to disable exit link tracking from Launch by Adobe by unchecking the 'Track outbound links' checkbox in the Adobe Analytics extension.

Next, I've created a new rule and am using the 'mouseover' event (which I really like as I'm able to test links by right clicking instead of clicking to monitor image requests). For Actions, I'm using 'Adobe Analytics - Clear Variables' and then just selecting 'Adobe Analytics - Set Variables' to put in my custom code in the JavaScript Editor. Note that I've not chosen the 'Send Beacon' action as we're doing our own custom event handler.

In the Code Editor, I've used the exact same code as DTM except for the clearVars() function as I'm leveraging Launch to do that.

After publishing the code, we can see the exact same image request as we saw in case of DTM, where we're only capturing eVar3 along with the exit link URL.

So, that's it! Hope you enjoyed this post and can make use of what I've done (or something better) to solve this common issue.

Product Management Insight