Out with the Old!

The subject of today’s article is “things we do, well, because, and which we should stop doing.”

Below, you can find a list of things that I, personally, would a) not do anymore, and b) like to eradicate from any deployments I have ever participated in. I’d also like to erase them from my memory, but I think that has to wait until we all speak AEP and XDM fluently.

If you use any of the following in a current setup, add up the points. We’ll talk about your score at the end.

Track everything we can think of – 1 point

“Our product category pages have this filtering system. People can narrow down their searches in about 9 million different ways. We must know about every single one of those!”

Frankly, you don’t.

I see two questions here:

1. Are people using your filters? Yes? Good, keep them! No? Remove them from your site. That level of tracking is simple.
2. Have you checked how they use them when you first put them live? Yes? Good, you’re done. No? Why not? And why would tracking them now change that in any way?

I believe that “too much data” is one of the principal reasons for people not to use Analytics.

Be it confusion, the struggle with data quality, or simply a question of beauty in simplicity, it keeps people from looking at data, of trusting it, of making decisions based on it!

If you are in an analytics team or function, and if you don’t prune your data, you are effectively cutting off the branch that you are sitting on.

Unless you are Tim Wilson, of course, but then you aren’t.

Seriously, though, if you think you need stuff like the above for any sort of reason, and you are aware that your users won’t need it, at least hide it away from them! And review it often, so you can prune it eventually.

c2=D=v2 – 2 points

“We used to write everything into both, eVars and props” is like “We used to boil everything”

There used to be a time when eVars were in their infancy. We could all see the potential, and we loved them, dearly, but for some things, we used props.

Those times are over, eVars have officially grown up!

They have actually moved out, started their own careers, and are now looking down on props with a bemused (but gentle) aloofness.

I keep saying that there are almost no reasons anymore to use props, and people keep telling me about use cases that they found.

Fair enough.

But the “if you track it into an eVar, copy it into a prop, too” use case has outlived every excuse known to mankind.

Do not track stuff into both!

(Overly cryptic headline: check, obscure pop culture reference: check. I’m half-way down my cheat sheet here)

Track pagename twice and use a Custom Page View event – 4 points

Almost every implementation I see does this:

    s.pageName = "Home";
    s.eVar1 = "Home"; // copy pagename
    s.events = "event1"; // custom Page Views event

I think this technique dates back to the days when we all used the “Reports & Analytics” UI, formerly known as Adobe Analytics, formerly known as Omniture SiteCatalyst.

In the old UI, “Pagename”, by design a traffic variable (a prop), behaved differently in some reports, and it was also possible to use it with success events.

Some of the results were mildly confusing, such as when in a report the metric would silently decide to be a participation metric, in other words, when the report used a different allocation without really telling us.

So we put the pagename into an eVar, and we tracked an additional, bog-standard event, and we used those in the reports. Predictable.

These days, we should all use Analysis Workspace.

In Analysis Workspace, there are no silent assumptions, and you can decide what allocation to use explicitly.

There is therefore no reason why you would need to do the above.

Track events twice, because de-dupe – 8 points

Before calculated metrics became “derived metrics”, and segmentation changed everything, we had to decide whether we wanted an event to count every time, or not. To this day, there is a field in the Analytics Extension for Launch that allows you to “serialize” an event, or to de-duplicate it.

If you send a serialized event twice, but with the same value, it will only be counted once.

We used that for things like “in how many visits do people look at their shopping cart?” (serialized) versus “how often do visitors look at their shopping cart?” (non-serialized).

Yes, we needed two events for that, and at the time, we didn’t have 1000 of them, either.

These days, you can pretty easily create a calculated metric, based on the Visits metric and a “Cart View exists” segmentation, to do pretty much the same thing.

If you still have any serialized events, it is highly likely that you can simply replace them with a calculated metric.

Put tracking codes into multiple eVars – 16 points

Campaign tracking is easy, until you start to think about expiration and allocation, and then it becomes mind-boggling very quickly.

In the past, we often tracked tracking codes into s.campaign, plus into one or more additional eVars. We then configured those eVars with different expirations and allocations, so we ended up getting reports with 30 days expiration and last touch, 30 days expiration and first touch, 15 days and last touch, 15 days and first touch, and so on.

This was often done at the request of different people with different opinions on expiration and allocation.

Then Marketing Channels reports came along, reducing the need for eVars by automatically covering first and last touch. Data Workbench (part of Analytics Premium) added all sorts of logic to attribution reporting, and even Analysis Workspace has thrown its hat into the rink, lately.

If you want to look at attribution, do it right.

Handle most of the tracking in doPlugins – 32 points

The doPlugins method has been around for a long time, and it used to be a brilliant way for us to add code into an Analytics deployment without having to rely too much on our customers’ developers.

People have done amazing things just using doPlugins. It used to be a tell-tale sign of someone knowing what they were doing when they did stuff in there.

With DTM and Launch, and other tag managers, now being the primary means of deploying Analytics, I find that I almost never even have a doPlugins method anymore, there is simply no need.

And because stuff should be simple, I would argue the days of putting plugins into Javascript code are over.

Use it, if you must, but try without it. You might be surprised how easy that is.

Notes & Results

Have you added up your points? Wanna share?

I’d like to know how many of us are still doing those things above, maybe even for good reasons.

Post your score, anonymously if you like, no blaming intended here.

And then let’s move on.