Migrating to Tag Management

I have been slow with implementing Tag Management on my own sites and until I actually started doing it I didn’t know why. Now I know: it’s not straight-forward.

It is fairly easy once you know what to do, though.

So let me walk you through the process from the perspective of a developer.

We’ll do a simple example first, just a standard blog article with s.pageName, two events and an eVar. Later, we will provide an example with Context Data Variables, which in theory should be easier.

The Original

The page we are going to use looks like this:

[Screenshot]

Original Sample Page

You can see everything that is needed for tracking close to the </body> tag at the bottom of the file.

In the code, we are setting:

  • s.pageName
  • s.events — we’re sending event1 & event15
  • s.eVar21

Now all of that is specific to this very page and we will therefore have to keep it on the page somehow when we move to Tag Manager.

The Change

We are following the online documentation, and we’re specifically interested in step 2 — Migrate Legacy Implementation Code.

The documentation explains how the overall architecture works and what the different parts do, but I am missing one thing: what happens to the code on my pages?

The secret lies with amc.on Tag Event Callbacks!

Tag Management in its current incarnation (“2.0”) executes tags asynchronously. That means the tags are loaded at the top of the page but they can fire whenever they want.

You can no longer just include a <script> block on your page that sets the various “variables” or otherwise accesses the s object, because the object might not yet exist, or you might be too late!

So, you wrap your code into a function that is part of an amc.on callback handler.

I won’t go into too much detail here. The documentation on Tag Event Callbacks lists them all. In our simple example, all we need is to use a handler for the tagload.sitecatalyst event.

New Code

The new page, with the tag loader inserted and the page code wrapped, looks like this:

[Screenshot]

New Sample Page

Note that the tag loader sits at the top of the page rather than the bottom. That allows the system to fire tags earlier, reducing the risk of lost tracking due to quick clickers. Because it is asynchronous, it should not impact page load times or performance.

Note also how the actual page code hasn’t change at all, except for the wrapper, of course.

Notes

The example is really very simple, and looking at the code it doesn’t seem to make much sense to switch to Tag Management. For bigger sites that is likely completely different. Especially sites that use not only Analytics but also other parts of the Adobe Marketing Cloud, deployment will be a lot easier with Tag Management.

And even in this simple case there is one reason to use it: updating the “core” Javascript code is a matter of clicking in the UI rather than deploying a new file.

About

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.

Tagged with: , ,
Posted in Javascript, Page Code, Principles
6 comments on “Migrating to Tag Management
  1. mitchellt2 says:

    Thanks for a great post (and a great site!). I am interested in how to pass product and merchandising data dynamically from the server side into the s_code hosted on Tag Manager. In the Google Tag Manager realm, it is done with a ‘data layer’, how can we do this with Adobe’s solution? I’m working on a prototype myself, with some degree of success (but not quite there yet). Thanks for any ideas/suggestions!

    Like

    • Jan Exner says:

      Hi!

      Thanks for the compliment and even more for reading!

      The equivalent of the data layer can be built with Context Data variables. We’ll post an article on that soon, mainly because it really makes the life of the implementer a lot easier.

      Like

  2. Jan Exner says:

    Note: Adobe released Dynamic Tag Management on Sep 18. The legacy Tag Management solution will probably be sunset at some point.

    See http://dtm.adobe.com for more information.

    Like

  3. MitchellT says:

    In the DTM docs, Adobe is stating a sunset of “end 2014”. Somehow I hope that date is extended. Thanks for this blog – looking forward to future posts!

    Like

    • Jan Exner says:

      Thanks Mitchell!

      I reckon supporting and driving two tag management solutions might not be an effective use of resources, but I am not product management and I don’t know what the plan is.

      Like

  4. PaoloBar says:

    Thank you for a great post! 🙂

    Like

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

Enter your email address to follow this blog and receive notifications of new posts by email.

Join 1,398 other followers

%d bloggers like this: