Getting Started: Migrating to DTM - A Closer Look at Adobe Analytics

Content built in partnership with Search Discovery

Find out more about SDI's Adobe DTM expertise

Whether your current Adobe Analytics implementation is deployed via on-page methods or via another tag management system, this article will help you understand your options as you migrate to DTM.

Phase 1 - Quick value add

Since migrating analytics code can be a lengthy process, DTM offers a feature that allows you to augment your existing Adobe Analytics implementation without disrupting it.

This feature is called ‘Page code is already present’ and is located in the Analytics tools settings in your DTM property.

To access this feature, expand the ‘Library Management’ section of the tool settings.

With this feature enabled, DTM is able to leverage the existing implementation to send supplemental s.t() / s.tl() calls via event-based and direct-call rules. 

This functionality makes it easy to start using DTM to augment your Adobe Analytics implementation before migrating any code.

However, it’s important to note the following limitations with this approach.

• Variables and settings configured in the DTM Adobe Analytics tool will not take effect
• Adobe Analytics variables set in page load rules will not take effect

These limitations occur since DTM is fully relying on the existing implementation to serve the AppMeasurement code and instantiate the s object.

Phase 2 - Full migration

In order to take full advantage of the integrated Adobe Analytics functionality in DTM, a complete migration of Adobe Analytics code is recommended.

This migration should include all s object references in the page code and included scripts on pages where DTM is deploying Adobe Analytics.

Migrating global code

The first step in migrating is to configure your global code in the Adobe Analytics tool settings in your DTM property.

The AppMeasurement code / s_code is configured in the ‘Library Management’ section of the tool settings under Code Configuration.

If ‘Page code is already present’ from phase 1 is currently leveraged, you’ll need to uncheck this option to reveal the Code Configuration options. This change will only take effect in staging so you can fully configure and vet the migrated code before pushing this change to production.

The Custom configuration option is typically preferred as an initial migration approach since it allows you to reference your existing AppMeasurement / s_code as-is without the need for additional tool configuration.

✓ Custom - Hosted in DTM – paste existing code into editor

✓ Custom - Hosted at URL – reference existing code at URL location

With the Managed by Adobe option, DTM automatically provides and hosts the selected AppMeasurement base code version. This method allows for easy code version updating making it a great long-term option. 

Regardless of the Code Configuration option, items not included in the AppMeasurement code can be set in the tool settings via the provided interface fields or in the Customize Page Code editor.

The provided interface fields are a great long-term option for configuring global settings and variables as leveraging these fields in place of custom code ultimately reduces the overall complexity of your implementation.

The Customize Page Code editor is a convenient alternative for items that require code such as plug-ins and conditional settings. Any code placed here will work in tandem with the hosted AppMeasurement code / s_code.

Migrating page-level code

Migrating page-level code

The next step in migrating is to configure non-global code in DTM rules.

Here’s an overview of each rule-type and their typical usage for setting Adobe Analytics triggers.

Page load rules: to append variables to the default page view beacon on all or certain pages

✓ Use case example – sending a particular eVar on load of my promotional page

Event-based rules: to trigger a s.t() or s.tl() beacon on specific user interactions

✓ Use case example – sending a custom page view beacon with a particular event when a popover is enabled

Direct call – to trigger a s.t() or s.tl() beacon in scenarios when DOM event can’t be detected

✓ Use case example – sending a s.tl() beacon with a particular event when a video is viewed

Remember code migration best practices

As discussed in the previous article, it’s important to remember the following best practices as you work to migrate your Adobe Analytics code.   

1. Develop a systematic process
2. Start in lower-level staging environments to fully vet migration
3. Work with IT early to coordinate code removal

Please note that this approach only affects the Analytics tool beacon; rules configured to fire Adobe Analytics should be conditioned in the rule itself.

Please vet this approach fully in staging environments before leveraging in production.

Up next in the five part Getting Started series: Benefits of a Tag Management System - a focus on Dynamic Tag Management.