With DTM you don’t need Plugins! – Part 1

Today’s article is a bit of an experiment. I have set myself a goal, and I’ll try to reach that goal and document it.

The goal: getting rid of plugins in the s_code.js file.

Why would I do that?

Couple of reasons:

• Plugins in the s_code.js file make it more difficult to move to DTM. If my s_code.js had no plugins and no doPlugins method, it would be much simpler to remove it from my page code and load it via DTM.
• Simplifying and/or minimising the amount of Javascript code can only be good from a maintenance perspective.
• Plugins are written, provided and maintained by Consulting. That means some of them are not free. Using DTM to provide the same data or logic would therefore save money.
• Using DTM functionality should make the setup more robust against changes.
• I haven’t done this before.

It will come as no surprise to readers of this blog that the last reason is enough to make me try this. Plus the fact that it would spawn this article and a couple more.

Status

Let’s start with an inventory of plugins in my very own s_code.js file. I am using the following currently:

• getQueryParam — for grabbing external and internal campaign tracking codes.
• getValOnce — to de-dupe campaign tracking.
• apl — to add a custom Page View event to my setup and a couple other events.
• getTimeParting — to analyze traffic based on days and time of day.
• getDaysSinceLastVisit — to analyse how often (the few) repeat visitors come to my site.
• getPercentPageViewed — to check whether people scroll down my articles or not.
• getPreviousValue — for grabbing the name of the previous page (good with getPercentPageViewed).
• getVisitNum — again to analyse behaviour of returning visitors.
• plus some self-made code that does all sorts of things.

Some of those are easy to replace (think getQueryParam), others not so much.

Oh. In case you are wondering why you cannot see any of these or even an s_code.js file here on this blog… I am talking about another site. This blog is hosted on WordPress and I can’t put Javascript onto the pages. I do track it (as you can see using Charles), but I won’t even discuss how because I use a method that is absolutely revolting, technically.

Right, with that out of the way, let’s remove some easy plugins!

getQueryParam

Now this is so easy to do it almost feels wrong to give it a headline.

DTM can be configured to read URL parameters in multiple places: the configuration of the Adobe Analytics tool in the Page Load Rule is one of those, a Data Element would be another.

Easy.

apl

I use the apl plugin to add a custom Page View event to all of my pages. This is one of those best-practice things we all do when implementing Adobe Analytics (others are adding a custom Product View event and passing the page name into an eVar).

This is also very easy to do: just set the event in the Page Load Rule for Adobe Analytics, and you’re done.

c_r

The c_r function is not technically a plugin. It is a function that reads a value from a cookie, that’s all.

Based on whether you are using the Cookie Combining Utility, it will actually read from the cookie that you name or from the combined cookie.

So this one can only be replaced by a Data Element of type “Cookie” if you do not use the Cookie Combining Utility. I do, unfortunately.

But if you don’t, then this is the most easy replacement ever.

Notes

There are quite a few other plugins, which I may discuss in a follow-up at some point. I’m also thinking about plugins like Channel Manager, Cross-visit Participation (cvp) or maybe even the Cookie-combining Utility, which reduces the number of cookies used by the plugins, but makes moving to a plugin-less s_code.js file pretty tough.

I will in a future article look into the Conditions in DTM, see if they help me further.

Also, what’s left over can be moved into DTM, as is, if you want.

Hm…

Two down, lots to go. “I’ll be back”