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:
- Are people using your filters? Yes? Good, keep them! No? Remove them from your site. That level of tracking is simple.
- 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.
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
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.
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.
7 thoughts on “Out with the Old!”
Completely disagree with your philosophy about “Don’t track everything” although, I acknowledge it’s a popular one to hold
To answer some of your questions:
“Have you checked how they use them when you first put them live? Yes? Good, you’re done. No? Why not?”
1) what data analysis says now (or at the time a feature was launched) about the ways its used may not hold into the future – as traffic sources, device type usage change etc
“And why would tracking them now change that in any way?”
2) business changes may mean something not analysed previously now needs to be – perhaps a new product category launch means its now necessary to analyse the filter usage. Perhaps a new op[timisation initiative means it needs to be understood in order to identify pain points
“I believe that “too much data” is one of the principal reasons for people not to use Analytics.”
3) I don’t personally believe that Analytics is any more complicated with 100 evars rather than 50. I think that people don’t understand what questions to ask. I think they don’t even open Analytics because its easier to send a reporting request to an analyst. I think the Adobe classroom training is of little relevance to how Analytics is actually used day to day. I think people are too time poor to learn new skills. I think organisations don’t invest as much in people, strategy, partnerships as they do in the platform itself. etc.
Thanks for the feedback, very good points!
I think to your arguments 1 & 2 I would say I agree that things change, but all it does for me is to remind me to every now and again go in and check whether things still work or not. That might be done via Analytics, yes, but I only need the data at that point, not permanently. And it might also be done using A/B testing, which for UI topics, I find easier.
And where we probably disagree more is your argument 3. For an analyst, or anyone who works with data as their job or vocation, there is no difference. For all others, I have seen how too much choice is a blocker. People look at the abundance of data, and they shy away. Is that not what happens for your stake holders?
It only matters, of course, of you want to get people to self-serve.
One of the issues I have with the argument that the analysts don’t know what they want yet so track everything in case they need it someday, is that by the time they may ask those questions the data being tracked in the past (3-6 months earlier) is often irrelevent at that point. If they have a new question then put up that tracking and in most cases on a good sized site you can get enough data in a couple weeks to start making reasonable analysis. Not always, but in most cases.
I’m also a big advocate for turning off certain tracking after questions have been analysed and reported on. It is very common for specific type questions to come up, either for narrow ones or short term projects/features, we put tracking on it, the question gets answered, and that tracking stays in place for years even though the data is not looked at again, or even becomes irrelevent because of site evolution. Usually this is not noticed for years until a re-implementation is done and people are wondering what some of the tracking is even for. Not only is leaving unneeded tracking on long term a contributor to data bloat, it also increases code bloat and complexity as well as potentially page performance degradation and server call cost overruns. If that question comes up again, then we can turn it back on for a while until they get enough data to answer again.
I agree that there is little point now in using an event in lieu of page views but I still think there are reasons for capturing/ duplicating pageName into an evar.
– evars have bigger character limits and s.pageName is far too small for us unless you start abbreviating.
– we can include the page name evar in a custom link to determine the page where the custom link was fired. (You can’t include s.pageName in linkTrackVars as far as I know )
The issue with marketing channels (well, one of the issues …) is: If you gave in to people with different opinions on campaign tracking before, then adding marketing channels will just add another view to argue about. So, not disagreeing in principle, but adding a pinch of real world:p
And I agree with Gareth on the pagename eVar. Using an exlicit eVar communicates to our users that they can trust the allocation feature. And typically we don’t want to know PVs, we want to know about some .tl stuff and some context in a prop or eVar on a page.
Everything else admit to have sinned more than once in the past. The two items I find the hardest to resist: doPlugins and the event for custom PV. Too many memories. I take my 36 points with milk and sugar, please.
thank you for the article!
I agree with you on “getting rid” of props, but there is one function, which exists only for props – automated generation of Entry and Exit props.
Typical example – I need to create a segment with visits, who entered(landed) on PageType XY – how can I do it with evar? Is that even possible? For prop, I just create a rule with Entry PageType = XY, but for evars I am not sure…
Thanks for any thoughts!