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 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.events— we’re sending
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.
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
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.
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.
6 thoughts on “Migrating to Tag Management”
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!
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.
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.
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!
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.
Thank you for a great post! 🙂