DTM to Tags (formerly Adobe Launch) Migration: Lessons Learned

Being in the frontlines of many DTM to Tags (formerly Adobe Launch) migrations has led us at Softcrylic to learn a lot about what to watch for. If you are reading this post, chances are you are either getting ready to migrate to Tags before the next deadline in October this year, or you have done so but are facing some unforeseen challenges. We decided to compile a running list of lessons learned and their solutions and share with the community so your migrations can be successful.

Below was compiled from various engagements by our Offshore Digital Analytics Manager, Rajdeep Singh. Feel free to click on each to skip directly to the content or read them all! We are also interesting about other issues you have faced that are not covered here. As we continue to migrate clients, we will keep posting about lessons learned. Sign up for our blog newsletter to stay in the loop:

1. No _satellite.pageBottom() snippet in Async Tags
2. An additional Send Beacon rule in Tags
3. “Error Minifying your custom code. Unexpected token” while building Initial Library in Tags
4. Missing Vars in s.tl() beacons
5. Issues with clicking a link but getting 505/404 errors
6. Media pixels with multiple IDs capturing same data when they should not
7. Device Type condition has been deprecated
8. Key Press event not working

1. No _satellite.pageBottom() snippet in Async Tags

As Tags Async set-up doesn’t require _satellite.pageBottom() snippet, a lot of implementers can come up with a question – How will my DTM rules, which were firing at Page Bottom, trigger in Tags?

• One can think of using Tags Sync set-up instead of Async. While async is not for every company, that will be a blunder – you would not be leveraging Tags Async set-up, a flagship feature and hence you might not see page performance improvement post migration.
• Others can think of changing triggers in all rules from Page Bottom to DOM Ready in Tags. That may not necessarily be a smart choice – what if you have hundreds of such rules and you do not have enough resources/time to do this all manually?

Then what to do?

My advice would be just DO NOTHING.

Yes, you have read it correctly – Do Nothing. You do not have to change Page Bottom to DOM Ready or do any other tweaking in Tags because DOM Ready is a default fallback for Page Bottom trigger. In simple words, with Tags Async, all your Page Bottom rules will now automatically fire at DOM Ready event – A Blessing in disguise, isn’t it?

2. An Additional Send Beacon rule in Tags

After migrating a DTM property to Tags via upgrade button, a lot of you might have witnessed one extra rule has been created in Tags.

A lot of questions like below might pop up in your head:

• What this rule is for?
• Why has this been created automatically?
• Should I just remove it?

We will answer these questions a little later but first let’s understand the major difference between Page Load rules in DTM vs Tags. Let me start by asking you a question – Do Page Load rules in DTM fire a beacon in itself? Yes, No, Not Sure?

The answer is No!!

DTM Page Load rules were not designed in a way where you can choose send beacon action via s.t() or s.tl() function. The only purpose of Page Load rule was just to set the variables and at the very last DTM engine will collate all these vars and fire them in a beacon to Adobe via s.t().

While in Tags, you can choose the type of beacon you want to fire s.t() or s.tl() even for the rules firing at Page Load Events such as Page Bottom, DOM Ready, etc.

A picture is worth a thousand words:

Now we have the answer to why Tags automatically appends an extra Send Beacon rule in migrated properties. The sole purpose of Send Beacon rule is to run at the very last and fire all analytics vars in a beacon for all the migrated Page Load Rules. Inside Send Beacon rule you will find:

1. Event as Page Bottom with Order as 100 just to ensure that it is the last firing rule.
2. The only action as “AA – Send Beacon” firing s.t() function.

Note – If you had rules firing at DOMReady/WindowLoaded then change your Send Beacon event to DOMReady/WindowLoaded with order as 100.

3. “Error Minifying your custom code. Unexpected token” while building Initial Library in Tags

After migrating a property from DTM   Tags, a best practice is to quickly build the library and try running it in Dev environment, but it may not be that easy all the time. While building the library you may find it failing and there are chances that you may come up with a very confusing error: “Error Minifying your custom code. Unexpected token”

There is huge possibility that you are running into ES5 incompatibility issue.

ES.. What!! What the heck is ES5?

ES or ECMAScript stands for European Computer Manufacturer’s Association Script. ECMA is an association which sets standard for scripting languages such as JavaScript, Jscript, etc.

• 2009 – ES ver. 5 was released called ES5/ECMAScript5
• 2015 – ES ver. 6 (latest) was released called ES6/ECMAScript6

ES6 brings new syntax and awesome features to make your code more modern and more readable. ES6 introduces us to many great features like Arrow functions, Template strings, Class destruction, Modules, Keywords like “let”, “const” and more. Most of the browsers like Chrome, Firefox, Edge, Opera, etc. with later version supports ES6 but browsers like IE may not fully support it.

Tags has been designed in a way to support all the browsers, but all the browsers don’t support ES6. Hence Tags would not let you use ES6 modern features/keywords like “let”, “const”, “=>” functions, etc. It will throw an error something like above and would not let you build your library.

Now some of you might think that we have used “let”, “const” and other modern JS features in DTM but never faced any issue then why we can’t use them in Tags, what this error ?

Was DTM designed to support ES6 but not Tags? How come a soon-be-obsolete TMS supports ES6 but not the latest one?

Answer to this baffling situation is DTM did not support ES6 either, it just had an old compiler that was around before the days of ES6 so it wasn’t smart enough to throw an error at you if you ES6 features.

Boom! That explains it all.

Following snippet will throw an immediate error in Tags but would not trouble in DTM:

Hence there can be cases where your migrated property in Tags might have custom code with some modern JS keywords/features and while building your first library you may experience an error somewhat like above.

Now you all know the solution. Replace all modern JS keywords to legacy ones as below:

• “let”/“const” with “var”
• Arrow => notation in functions to Parenthesis () notation
• and so on..

Now next question which may pop up here is “How to find all such Rules/DE”?

Going Rule by Rule and checking the custom code or searching for all the modern keywords one by one in Search bar aren’t the smartest choices – time taking and not 100% fool proof. My suggestion would be “Read the error carefully” and follow the below steps:

Error Minifying your custom code.
Unexpected token: name (__initiate)

• Step 1: Whatever you see inside parenthesis, search that in Tags search functionality e.g. “__initiate”
• Step 2: Go to all the search results one by one and look for the erroneous string (__initiate) within custom code. As you will find your string and so the ES5 incompatibility error.
• Step 3: Replace the incompatible keywords/features with ES5 compatible ones. Here is a blog which can help you in finding ES5 compatible keywords/features.
• Stpe 4: Re-build your library. There are chances that you may see same error happening again but this time it will be with different erroneous string.
• Stpe 5: Repeat Step 1 to Step 4 until all the errors are gone.

4. Missing Vars in s.tl() beacons:

After migrating your property to Tags you need to be little extra cautious with link click rules firing beacon via s.tl() otherwise you may end up losing some of your vars in beacons.

What!! How come and when?

If you had some rules in DTM in which few of your vars were being set via “UI” and few others via “custom code” then you wouldn’t have experienced any issue. DTM would have concatenated “UI” vars with “custom code” vars and defined them all in s.linkTrackVars automatically to ensure all vars are getting triggered in s.tl() beacon.

Sadly, Tags does not do that. In above scenario, Tags would consider vars defined in custom code only. Custom code vars will override UI vars instead of concatenating with them. By the way, this looks to be more of an Adobe Analytics extension limitation instead of Tags.

So, what’s the solution?

Use s.apl plugin to append all your UI vars with custom code vars. Follow below steps:

• Step 1: Add s.apl plugin code in your AA extension in custom code section. Copy the code from here
• Step 2: Modify your custom code block as below
  

Doing so, all your custom code vars will get appended with UI vars and nothing would miss out.

5. Issues with clicking a link but getting 505/404 errors

After moving to Tags many of you might face issues as below:

1. On clicking certain Links, next page is loading as Blank.
2. Link clicks throwing Errors like 505/404.
3. Links to overlay are now navigating users to URL instead of opening the overlay, etc.

High probability is that they may be occurring due to Link Delay Navigation activated.

A quick solution would be disabling delay navigation setting. However, DO NOT disable it in all the rules but only those which are creating issues like above.

Now to understand what exactly is going on, lets deep dive.

The reason you were not facing issues in DTM with such rules is that Tags comes with a totally new Event Detection methodology. Aaron Hardy has written a beautiful blog on this – a must read ! To summarize what Aaron has written, Tags event detection is more robust and can detect clicks and other events earlier in the detection process as compared to DTM.

One of the reasons I see issues with using Delay Navigation is because it essentially captures the event, copies it, cancels the original event, waits for a period of time and then executes the copied event.So if it doesn’t copy the original event properly (i.e. the scenarios I’ve mentioned above) it will have adverse effects.

With a better event detection method in place one would expect things to be smoother but as this methodology is still new and there will be a few issues when applying it to practice. Adobe knows these issues and might fix them with upcoming updates. But till then I would suggest you test all your Rules with Delay navigation thoroughly in Tags and if you notice issues like above, try disabling the setting and re-test.

When I read Aaron’s blog for the first time, I thought Delay navigation would not be needed at all going forward but that’s not the case. If the link click causes the browser to redirect to a new page (as most links normally do), and you have a s.tl() firing with that link click, then in my experience, not using the delay caused the hit to be fired only about 50% of the time, whereas using the delay has a 100% firing success.

Perhaps this is the logic for delays:

• If the link is to run some script on the current page – Don’t delay
• Else – Delay (including for links to “pages” in SPA websites)

6. Media pixels with multiple IDs capturing same data when they should not:

This requires your attention if you have 3^rd party multi-ID pixels implemented in Tags. Multi-ID pixel means there are two or more pixels (for same vendor) with different IDs being used on the same page and they both are collecting different events. e.g.

When this happens, with Tags, both pixel IDs will record the later event (AddToCart) on the click as following:

On DTM it did not record an AddToCart twice, but on Tags it did.

Why does this happen?

Below is a summary, but for a more detailed explanation check out the DTM to Tags comparison blog post about multi-id pixels issue.

When using non-sequential HTML in DTM, DTM will inject the pixels within a hidden iframe. On other end, Tags does not have non-sequential HTML because everything is either embedded within Tags library or loaded from the Adobe server and added using Postscript, therefore no iframe.

While not an actual bug, this is a product design difference that is important to know about so it does not caught you off-guard. To date we have seen this happen with Facebook but we think it could happen with other vendors. To fix Facebook’s issue, use their trackSingle selective pixel code to ensure only an event is sent to the desired pixel ID. For a more detailed explanation check out our dedicated blog post to this topic.

7. Device Type Condition has been deprecated:

OOTB condition “Device Type” has been deprecated in Tags.

Reason being, it wasn’t 100% fool proof. This feature had many grey areas – categorizing user agents into device categories that had overlap, browser spoofing, too many permutations of user agent strings and maintenance issues.

Adobe has no plans to maintain this and want users to come with strategy to categorize device on their own.

Resolution Options:

• Use whichbrowser or few other publicly maintained JS parsers for identifying devices based on user-agent strings
• Another alternative is to use the screen resolution as condition. You would have to agree on an internal convention on what screen resolution matches per device types, something like below:
  
  A data element can calculate and return “deviceType” value and be used in condition
  

8. Key Press Event not working:

If you had some rules in DTM with event “Key Press” and you’ve moved them to Tags then this requires a little attention.

In most cases, with event “Key Press” custom condition checking for comes in, in order to restrict the rule to fire on a certain key press. One of the examples is to fire “Internal Search” rule when a user presses “Enter” key after typing some string in search box. The “keyCode” property of “event” object returns the Unicode character code of the key that triggered the onkeypress event, or the Unicode key code of the key that triggered the onkeydown or onkeyup event. For “Enter” key, “keyCode” property returns “13”, Hence following code will check for “Enter” key press in custom condition:

This works fine in DTM but returns “undefined” in Tags.

Why?

Because Tags also owns an object called “event” and in above scenario it will look for a “KeyCode” property of Tags “event” object instead of JS global “event” object, hence it will throw “undefined”.

Solution?

A simple tweak – just append “window” before “event.keyCode”.

Doing so, compiler will look for “window.event” global object instead of Tags local object. In Tags, your custom condition code should look like below: