There is no “standard deployment”.
A couple of weeks ago, I was talking with a colleague who hadn’t worked with DTM before. He asked me lots of intelligent questions about his somewhat non-standard requirements, and I replied with what I think is the best approach.
Whilst doing that, I kept thinking about “the other approach”, which I usually mentally connect with my colleague André Urban, or my ex-colleague Jenn Kunz, mostly because they are the most vocal about “the other way” in my immediate vicinity.
(And by “vicinity”, I mean phone, twitter, and slack, of course. Ah, the Internet! How poor we were ‘ere the Internet!
I decided that the fact that there were essentially two mutually exclusive ways was a good excuse for
a blog battle an online discussion. Jenn Kunz versus myself, battling it out. We’re nerds, right? There must be a best way, the best way!
So, here I am, explaining the advantages of my way. Jenn Kunz will do the same for hers.
And while I’m sure there are pros and cons for everything, and that we will eventually settle on “it depends”, I am still hopeful, deep in my heart, that I will be able to convince Jenn. Wish me luck!
DTM, and other tag managers, make it very easy to deploy a standard Analytics implementation on any web site. Thing is, though, I have never seen a standard Analytics implementation.
The moment you start leaving the realm of “clean, easy, and standard”, you are diving into troubled, deep, murky waters. You don’t know whether there are any dangerous under currents, but I bet you you’ll encounter some sooner or later.
I’m not saying that standard implementations are useless. They are not. What I’m saying is that there are a lot of moving pieces and dependencies. In reality, people tend to not adapt other systems to our Analytics needs, so we end up adapting to theirs.
s.doPlugins() that it’d take ages to rebuild everything properly. So you’d rather just transport it over as is.
No matter why you want to do it, here is how I suggest you go about it:
Aim for “as standard as possible”, then add a doPlugins() method that handles the non-standard requirements.
When you add the Analytics Tool in DTM, leave everything as standard. Select your staging and production report suites, your char set and currency codes, maybe set the tracking servers, and possibly even some global variables.
But leave the library on “Managed by Adobe”! That is the crucial bit!
So far so standard. How about all those fancy other things you want to do?
Let’s split those up into two groups:
- Things that you used to put into the
s_code.jsfile — plugins, the
doPlugins()method, extra stuff that I need on every page
- Things that you used to embed directly into pages, be it some or all of them
Whatever falls into group 1 can very easily and directly be transferred into the editor window under “Customize Page Code” in the Analytics Tool.
To be honest, some of that can simply be built in DTM directly. Things like picking up a Campaign Tracking code, or setting some variable to some value read from a cookie and such. Move those! Reduce your code where you can!
Things that you used to do in code on pages, specific or not, should be moved into Page Load Rules.
Try to mimic the effect, not the code, by which I mean if your code used to set a variable, try doing it in the normal DTM way, with a Data Element and a simple assignment in the DTM UI.
There is really not that much more to say, but let’s maybe look at some specific things.
Dynamic Choice of rsid
Yes, can be done, and falls under group 1, above.
I wrote about this last year, but in short you make a Data Element, Custom, that calculates the rsid, then add a call to
s.sa(_satellite.getVar("Report Suite ID")); into the
doPlugins() method, so the rsid is properly set on every call that goes out.
In almost all cases that I have seen, campaign tracking could be moved from
doPlugins() straight to DTM, be it into the Analytics Tool, or a PLR that fires everywhere.
Simply build a Data Element and specify that in the PLR or Tool. The DE can handle pretty much all the complexity you need.
If you’re using the Channel Manager plugin, handle it like group 1, with a
There will be more to come, as I intend to show ways of building things that Jenn brings up.
There is one exception, where Jenn’s way is the only way: when you need to add a Module. The ActivityMap module is part of the Analytics code that DTM delivers out of the box, but things like the Media Module are not.
So if you need that specific module, better do what Jenn says.
But in all other cases, follow my approach.
I am putting all of my eggs into a single basket: there is nothing more important than the ability to quickly and routinely update the libraries.
Given that the
AppMeasurement.js file has 4 sections, one of which comes from Adobe, it makes more than a little sense to split those parts apart. With a tag manager doing that for you, you’d be a fool not to!
9 thoughts on “Discussion – Customize Analytics in DTM”
Nice examples of what cannot be achieved easily via “standard DTM way” are s.products (especially when you use stuff like Merchandizing eVars) and in most cases hierarchies as well.
I usually handle those within the Custom code in the Analytics part of a Page Load Rule.
LikeLiked by 1 person
Nice one … Like this “Try to mimic the effect, not the code”
I am a big fan of this approach. Using custom code even when not require it just for the sake of it, just makes the life harder for everyone else.