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:

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:

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.