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.

[Screnshot]

Setting of Campaign Tracking Code in Page Load Rule

[Screenshot]

Data Element for Tracking Campaign Tracking Code

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.

[Screenshot]

Page Load Rule with Custom Page Views Event

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.

[Screenshot]

Where to put the Code from s.doPlugins

Hm…

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

About

German expat living in Switzerland (formerly UK and France). Consultant and member of the Multi-Solutions Group at Adobe, working with the Digital Marketing Suite. Father of 4 girls.

Tagged with: , , , ,
Posted in DTM, Integration, Javascript, Plugins
7 comments on “With DTM you don’t need Plugins! – Part 1
  1. Hi Jan,

    Interesting post!! I’d like to add a couple of comments about which you wrote about s.apl I think isn’t 100% true 😐

    If you use a mixing between UI+Custom Code, will realize that the second one overwrite s.linktrackevents, so unfortunatelly still have to use s.apl for fill s.events and s.linktrackevents arrays.

    The second thing, thanks to DTM I discovered a new use for plugins, even those that we can call ‘deprecated’ because Adobe included on Analytics by default. This new use consist to pass their values on Data Layer (therefore then on Data Element) for interact over the user in real time, I’m currently using getDaysSinceLastVisit and it’s so interesting.

    Regards and thank you for your posts,

    Julià.

    Like

    • Jan Exner says:

      Hi Julià,

      You’re right about apl and link tracking. My use case was only for replacing it for the custom Page Views event. In the s_code.js file, I only use apl for that reason. But for link tracking, it is definitely useful!

      I like your idea with the plugins and the data layer! You are essentially making data available to more tools that way, and that can only be a good thing!

      Like

  2. Dwight Smith says:

    How would you implement Adobe’s old Form Analysis Plugin functionality – using DTM? Am particularly interested in how you would handle field validation AND form abandonment to know which field abandonment occurred on. Thanks!

    Like

    • Jan Exner says:

      Hi Dwight!

      Let me be honest with you and say this: I was really hoping someone would write an article about that specific plugin before I had to 😉

      I think there is a slightly bigger discussion in that question about what the real business case for form analysis is. Questions like: how much money is it worth? (versus: can we just use cookies and track on the next page) or do we do one form at a time? or all of them? with implications on how generic it has to be.

      Grateful for thoughts!

      Like

  3. […] tip: each bit of code that you migrate from doPlugins and into DTM (or whatever your TMS is) will make your setup easier, at least easier for your […]

    Like

  4. Frank says:

    Hi Jan,

    Thanks for sharing this post. Do you have any other reference guide to setup the plug in getPreviousValue and getPercentPageViewed please?
    I still wonder if I need to configure s_code.js or if I can do it with Data Element or even with the load page rule. I am a newbie here in DTM.

    Thanks Frank

    Like

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

Enter your email address to follow this blog and receive notifications of new posts by email.

Join 1,398 other followers

%d bloggers like this: