Best Practices for Getting Started with Adobe Dynamic Tag Management

If you are new to Adobe Dynamic Tag Management (DTM), getting ready to migrate to DTM, or brushing up on DTM, this guide is for you.

Last Updated: January 30, 2017

Dynamic Tag Management lets marketers quickly and easily manage tags and provides innovative tools for collecting and distributing data across digital marketing systems. DTM also enables responsive delivery of user-specific content-providing new levels of agility and control to companies seeking to thrive in today's fast-paced digital marketplace.

In addition to this Best Practices Guide, the following resources are available to help you get the most out of Dynamic Tag Management:

Resource Details
Dynamic Tag Management Product Documentation

In-depth information and step-by-step instructions about how to use Dynamic Tag Management.

Getting Started Guide

Information about how to start using Dynamic Tag Management.

Basics for the First-Time User

An introduction to the Dynamic Tag Management (DTM) user interface.

This content was built in partnership with

This section contains the following information:

Dashboard

Navigation: Home > Dashboard

The first page seen in DTM after logging in is the dashboard. The dashboard contains a list of all of the companies to which you have access.

Company Overview

Navigation: Home > Dashboard > Company Overview

Clicking into a company from the dashboard takes you to the company overview page.

Note: If you have access to only one company, you are directed to the company overview page instead of the dashboard upon login.

In DTM, a company is a collection of web properties. A web property is a collection of tools, rules, and data elements.

All web properties in the company are accessed from the company overview page.

Admin-level users can add new web properties from the company overview page by clicking Add Property. The only required fields when configuring a web property are Name and URL, which can be changed at a later time if needed.

Admin-level users can also manage and provision users from the company overview page via the Users and Groups tabs.

Property Overview

Navigation: Company Overview > Property Overview

Clicking into any property from the company overview page takes you to the property overview page.

The property overview page gives a brief summary of the property configuration and serves as a gateway to the main property components: tools, rules, data elements, the publish workflow, and the property embed codes.

Navigation: Property Overview > Installed Tools

DTM tools are built-in integrations that allow for quick deployment of solutions to your site.

Currently, DTM offers tool integrations for Adobe solutions as well as for Google Analytics and Nielsen. Each of these integrations is uniquely designed to make configuration and deployment of that particular solution easier.

Note: Any third-party tool or tag without a native integration can be implemented in a rule through the

JavaScript / 3rd Party Tag section discussed below.

Rules

Navigation: Property Overview > Rules

Clicking the Rules tab from the property overview page takes you to the property rules.

Rules in DTM are used to conditionally execute tools, tags, scripts, and HTML.

Regardless of the type, rules in DTM have two main components: the condition and the trigger. The condition indicates the scenario in which the rule will fire and the trigger indicates the item(s) that will execute when the rule fires.

There are three types of rules in DTM:

  • Event-Based: Event-based rules are interaction driven. For example, if I wanted to track when a user clicks a certain button, I would use an event-based rule.
  • Page-Load: Page-load rules are tied to the page load. For example, if I wanted to add a specific block of code on load of certain pages on my site, I would use a page-load rule.
  • Direct-Call: Direct-call rules are used in scenarios when DTM cannot detect an event in the DOM. For example, if I want to track an AJAX event that can't be detected in the DOM, I would use a direct call rule.

Regardless of the rule type, if the condition is met the trigger executes.

All rules types have the option to trigger third-party vendor tags or any other custom JavaScript or HTML via the Javascript / Third Party Tags modal.

Other trigger modals are enabled in rules when tools are added to the property. For example, if my property contains an Adobe Analytics tool and a Google Universal Analytics tool, the property rules will contain optional trigger modals for these tools.

Each tool modal offers easy methods to customize a trigger for that particular tool.

Data Elements

Navigation: Property Overview > Rules > Data Elements

Clicking the Data Elements tab within the Rules tab displays the data element overview page.

Data elements are used to build a data mapping in DTM. Defining common data points as data elements enables those data points to be easily captured and leveraged within rules and tools in DTM.

Workflows

An important concept in DTM is the idea of a single web property having both a staging library and a production library.

The staging library contains all of the rules, tools, and data elements configured in the web property. The production library includes only the rules, tools, and data elements that are approved and published.

Navigation: Property Overview > Approvals tab

When a rule, tool, or data element is added or changed in a property an approval is automatically generated.

Navigation: Property Overview > History tab

After an item is approved, it becomes available in the Unpublished Changes queue 0n the History tab. After an item is published, it becomes available in the production library.

This separation of libraries and associated workflow allows for more effective testing in staging without affecting production.

Installation

Navigation: Property Overview > Embed tab

Clicking the Embed tab takes you to the DTM installation page.

This tab contains the various library hosting options available. By default the property leverages Akamai hosting. This method is typically acceptable for most organizations; however, if additional control over the serving of the DTM library in needed two self-hosting options are available.

Expanding the Header Code section on the Embed tab reveals the staging and production embed codes for the property.

Notice there's one embed code for staging and one for production. This is how DTM differentiates between the staging and production libraries discussed above. When the staging embed code is installed, the staging library loads. When the production embed code is installed, the production library loads.

After the header and footer embed codes are properly installed on a site, the associated DTM library loads automatically on each page load.

Leverage the DTM Switch Plugin to test in the web console. This helps you understand what DTM is doing on the page and allows you to locally switch to the staging library for more effective testing. For more information, see Search Discovery Plugins in the Dynamic Tag Management Product Documentation.

DTM Technical Architecture and Hosting

Information about the technical architecture of Dynamic Tag Managment (DTM) and its hosting options.

This content was built in partnership with

This section contains the following information:

Architecture

The primary components of the DTM technical architecture include the web management application, the staging and production JavaScript libraries, and the embed code.

The web management application is the online interface that you log in to and use to manage your DTM implementation. This is where you'll create and configure tools, rules, and data elements and manage the deployment of these configurations to your site(s).

A web property in DTM is a collection of tool, rule, and data element configurations.

Each web property is associated with one staging JavaScript library and one production JavaScript library. These libraries are generated by the web application and contain the unique set of configurations in that web property.

The staging JavaScript library contains all of the latest tool, rule, and data element configurations in the web property. This library is automatically updated with any change in the property and is intended for testing in staging environments or for local production testing via the DTM switch plugin.

For more information about the DTM switch plugin, see Search Discovery Plugins in the Dynamic Tag Management Product Documentation.

The production JavaScript library contains only tool, rule, and data element configurations that have been approved and published through the web property workflow. This library is intended for the production environment.

Hosting

Both the staging and production JavaScript libraries can be hosted in the following ways.

  • External hosting via Akamai-library hosted on Akamai's servers
  • Self-hosting via SFTP or library download-library hosted on your servers

Choosing a hosting option(s) is a decision your business needs to make. Review the following option comparison and use-case examples to help facilitate this decision.

Advantages Disadvantages

Akamai

External hosting

  • Standard deployment method
  • No configuration needed
  • Minimal dependence on IT
  • Automatic file updating
  • Reliable & speedy file delivery via globally distributed Akamai network
  • Lack of control over file delivery
  • Dependence on third-party infrastructure (i.e. if Akamai is unavailable, so is your library)

SFTP

Self hosting

  • Complete control over file delivery
  • More secure option: SSH file transfer
  • Automatic file updating
  • Upfront configuration required
  • Greater dependence on IT

Library Download

Self hosting

  • Complete control over file delivery
  • Most secure hosting option: AES 256 bundle encryption
  • Upfront configuration required
  • Greater dependence on IT
  • Additional configuration required for automatic file updating

Use Case Examples

Scenario Solution
I prefer to involve IT as little as possible and have a need for a reliable file hosting method outside of my own site infrastructure. Leverage Akamai hosting in all environments.
I want to have complete control over file delivery in my production environment; however, speed and agility is more important than file control in my staging environment. Leverage Akamai hosting in staging environments and FTP delivery in production environment.
Certain sections of my site deal with highly confidential information. Security is the most important thing on these pages but isn't necessarily as important on other pages of my site. Leverage library download hosting on secure pages and Akamai hosting on non-secure pages.

All hosting options are available to enable and configure on the Embed tab in your DTM property.

Regardless of the hosting option chosen, the JavaScript library is served on your site via the installed embed code. Each hosting option provides a unique set of embed codes that reference the applicable file location configured for that hosting option.

The embed code consists of two code snippets: the header and the footer code.

  • Header Code

    The header code is responsible for calling the associated JavaScript library from the host location and serving it on your site. This code snippet should be placed in the head section of the site code as close to the opening tag as possible.

  • Footer Code

    The footer code is responsible for identifying the end of the page for timing control. This code snippet should be placed in the body section of the site code as close to the closing tag as possible.

The appropriate placement of both the header and footer embed code snippets is critical to the effective deployment of the DTM JavaScript library.

Note: Although you can use more than one hosting option, you must ensure that only a single embed code reference is included on any given page. Duplicative or improper placement of the embed code can result in unexpected library behavior.

The following illustration show how the discussed DTM architecture components work together to effectively deploy and manage tools, tags, and scripts on your site.

For more information on hosting options, see Embed Code and Hosting Options in the Dynamic Tag Management Product Documentation.

Planning Your Migration to DTM

Information to consider as you plan your migration to Dynamic Tag Management (DTM) and best practices to help get your implementation started correctly.

This content was built in partnership with

This section contains the following information:

Planning Your DTM Setup: Component Overview

This section contains a quick overview of the basic DTM company structure to prepare for the decisions involved in planning your DTM setup.

In DTM a company is a grouping of web properties.

A web property is a grouping of tools, rules, and data elements configured to collect data and deploy tags / scripts on your site(s).

Each web property is associated with one embed code that's responsible for loading the specific property configurations on your site(s).

Users are managed at the company level but can be permissioned for each property with the exception of the Admin role. The Admin role is global and has full permissions for all properties in a company.

For more information on user roles, see Create and Manage Groups in the Dynamic Tag Management Product Documentation.

Planning Your DTM Setup: Decision Points

With the basic DTM company structure in mind, let's discuss the related decision points as you plan your DTM setup.

How many companies do I need?

In most cases one company will best meet business needs.

The primary reason for having more than one company is to accomplish complete separation of users and web properties.

This type of configuration is most typical for large businesses with numerous sets of web entities that are run by various business divisions.

How should I distribute my domains and subdomains into web properties?

Web properties can be configured as one-to-one or one-to-many with your domains.

To decide what will work best for your business, consider the cross-domain similarities and differences of the following variables.

  • Data collection methods and sources
  • Tools and tags deployed
  • Site code structure
  • DTM user workflows

In most cases one web property per one domain will best meet business needs due to considerable differences in one or many of the above variables.

This type of setup most effectively accommodates each domain's needs while still allowing for easy duplication of cross-domain constants via the 'copy' functionality.

However, in cases where these variables are the same or very similar across domains, it may make more sense to have multiple domains within one web property. In these cases, this setup can reduce unnecessary duplication between properties.

This same reasoning can be used for subdomain distribution.

Use-Case Examples

Scenario Solution
My business division manages several domains. We're deploying Adobe Analytics across all domains, but each domain has its own reporting suite and tracking needs. Leverage one property for each domain.
My business division manages several domains. We're deploying Adobe Analytics across all domains and use one global reporting suite to collect all of our data. Data sources between domains are very different due to variations in site code structure. Leverage one property for each domain.
My business division manages several domains. We're deploying Adobe Analytics across all domains and use a global reporting suite and global data layer to collect all of our data. The rest of our tools and tags are mostly consistent between domains and we're planning to have the same users manage the publish workflow. Leverage one property for all domains.

Migration Best Practices

After determining the optimal company and property distribution, consider the following best practices as you begin your DTM migration.

Process Workflow: Develop a systematic process for migrating existing page code into DTM to help ensure a smooth transition.

It's generally recommended to start this process in lower-level staging environments and migrate code on a page-by-page or site section by site section basis.

This will allow you to fully vet DTM configurations before removing any pre-existing page code reducing the risk of implementation disruption.

Working with IT: It's important to work with your IT team upfront to determine current processes and deployment cycles.

This will help ensure proper and timely placement of the embed code and coordinated removal of effectively migrated page code.

People Workflow & Governance: Another important concept is establishing a user workflow. Thoughtfully assigning user roles provides governance to the DTM workflow.

User Role Create Rules Edit Rules Test Rules Approve Rules Publish Rules Create/Edit Users Create Property
User Yes Yes Yes
Approver Yes Yes Yes Yes
Publisher Yes Yes Yes Yes
Approver and Publisher Yes Yes Yes Yes Yes
Admin Yes Yes Yes Yes Yes Yes Yes

This will ensure that all items are fully vetted by the right members of your team before being pushed to production.

For more information, see Migrating to Dynamic Tag Management in the Dynamic Tag Management Product Documentation.

Migrating to DTM: A Closer Look at Adobe Analytics

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

This content was built in partnership with

Phase 1: Quick Value Add

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

This content was built in partnership with

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 because DTM is fully relying on the existing implementation to serve the AppMeasurement code and instantiate the s object.

Phase 2: Full Migration

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

This content was built in partnership with

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

The following sections contain more information:

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 take effect only 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 because 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.

Note: Dynamically populate variables by leveraging data elements directly in any field using the %dataElement% syntax.

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

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.

Rule Type Details
Page-load rules

Use 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 rule

Use 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 rule

Use 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 to follow Migration Best Practices.

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

  • Develop a systematic process
  • Start in lower-level staging environments to fully vet migration
  • Work with IT early to coordinate code removal
Note: A possible approach for progressive migration is to determine a flag for identifying pages that have not yet been fully migrated. This flag can then be leveraged in the Customize Page Code editor in the tool settings to conditionally cancel the default DTM beacon on those pages by setting 's.abort = true'.

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.

Benefits of a Tag Management System: A Focus on DTM

Information about the basics of tag management and walks through how Dynamic Tag Management can specifically benefit your business.

This content was built in partnership with

The following sections contain more information:

What is a Tag Management System?

Tag management systems are designed to make implementing and managing marketing and analytics tags on your site easier through the use of a container tag.

A container tag is a single code snippet that when placed in your site markup is capable of triggering countless tags on your site.

This approach reduces strain on the IT group and places the control in the marketers' hands.

Why Dynamic Tag Management (DTM)

Dynamic Tag Management takes the tag management approach described above and enhances it through a straightforward, yet, highly capable design with integrated scenario and timing control.

Consider the following as you decide if Dynamic Tag Management is right for your business:

Benefit Details
Improved site performance

With Dynamic Tag Management, marketing and analytics tags are moved from the markup of your site into the DTM library. This in itself reduces page load time as the DTM library is optimized for file compression and speed

.

However, performance is enhanced even farther through the use of the conditional controls and asynchronous methods DTM offers.

Conditional controls make it easy to ensure that tags are triggered only when needed, eliminating unnecessary code deployment.

Asynchronous loading forces tags to stay out of the way of the page, greatly reducing the burden on page render.

Increased control, decreased risk

With less reliance on IT, you'll be able to deploy and manage tags on your watch.

This means less commitment and risk in deploying vendor tags and increased agility to keep up with new tool / tag features.

Plus, DTM has built-in features to ensure compliance with data-privacy policies and to prevent vendor tags from interfering with your site or leaking data to third parties.

Work faster and more efficiently

Dynamic Tag Management takes a behavior-centric approach and leverages comprehensive integrations and data-centralization to make tag deployment easy.

The behavior-centric approach allows for countless tools / tags to be deployed at the same time based on a certain behavior rather than deploying each tag individually.

DTM's built-in integrations facilitate easy configuration of tools such as Adobe Analytics and Google Analytics, eliminating the need for extensive custom code.

Data elements centralize common data points, reducing code redundancy and optimizing data lookup time.

Together these features save time and frustration so you can focus less on tag deployment and more on moving your business forward.

Use Dynamic Tag Management for free

Best of all, if you're an Adobe Experience Cloud customer, Dynamic Tag Management is free.

Contact your Adobe Account Manager for details.