Discussion – Customize Analytics in DTM

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!

Anyways.)

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!

Standard

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.

And sometimes, it’s just that you’re moving to tag management, and you have so many useful lines of Javascript in your 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.

How?

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!

Why? Because that way, updates to the core Javascript are only a couple of clicks away, and DTM will actually remind you when updates are available.

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.js file — 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.

If that is not possible, then go for “3rd party / Javascript”.

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.

Campaign Tracking

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 doPlugins() method.

TBD

There will be more to come, as I intend to show ways of building things that Jenn brings up.

Exception

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.

Why?

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.

Any solution that requires me or my customer to copy Javascript code from A to B is potentially … no, scratch that: it will cause missed or delayed updates, and to me that is as annoying as it is unnecessary.

Given that the s_code.js or 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!