It’s been almost 18 months since I joined eCapacity, after having been with Adobe for more than a decade – how time flies. As I evaluate these past months, I realize that one of the main differences in my role is the type of clients I support. With Adobe it was primarily new prospects, whereas today I’m focused on existing Adobe customers. A lot of these customers I’ve worked with before, as I’ve implemented some of them back in the Omniture days. And as I review their configuration today, I realize not a lot have changed in their setup – the foundation is pretty much the same I created 8-10 years ago.
It would be easy to state that the solution I provided 8-10 years ago, is so solid that no update has been necessary. The only problem is that the best practices at the time are no longer best practices. Their site has changed multiple times in the same period, but the basics of their Analytics setup haven’t.
This made me realize how much the best practices have changed since I joined Omniture and how few customers (my personal view) have ensured to evolve the implementation and keep it up to date on best practices. So today I’ll give you 5 tips to bolster your Analytics implementation strategy.
Tip #1: Solution Design Reference
First, does your organisation have an SDR and is it up to date?
If not, create one! When I start working with new clients, I am astounded at how few have their Adobe Analytics implementation appropriately documented. Usually, I find that:
- Few companies have defined analytics business requirements.
- Most Solution Designs is a simple list of the variables which are enabled, but they are not paired up against business requirements.
- In most cases, Solution Designs are outdated or inaccurate.
A Solution Design should contain your most critical business questions. And is your foundation for why you’re collecting data. Mapping business requirements to business questions to which variables they correspond to, will provide you with a solid foundation for your implementation. Especially with GDPR, this is more important than ever, as it gives an overview of what data you’re collecting from your website visitors.
Tip #2: Don’t use both a prop and eVar
Are your users on all levels able to easily find the relevant reports and understand the data populated?
What I’ve seen the most is that companies – all depending on their size, but at least here in the Nordics – typically have one, sometimes two individuals who are superusers. Who fully understand the implementation and how data is populated. But the majority of users do not. It is therefore critical that you ensure it is easy for everyone to find the reports they need. Populating both a prop and eVar with the same data used to be best practice, but isn’t any longer. Don’t do this unless necessary.
Multiple reports with the same name make it difficult for entry-level users to know which report/dimension to use. Rule of thumb, only use props when required for hit level reporting and pathing.
Tip #3: Remember to do house cleaning
First, expect that your data contains trash. No implementation is 100% perfect. Bots, performance testing tools and javascript can all be causing the data to look funky. An easy fix is to use Virtual Report Suites to exclude this type of traffic from your analysis.
Also, make sure that all enabled variables are collecting data. I often experience – both when with Adobe, as well as with eCapacity – that if users don’t trust the data, it will result in users blaming the tool. In the worst case, it will result in a decision to replace the tool. Problem is that the tool is only reporting what you’re feeding it. Garbage in, garbage out. Shocker, right.
So no data or inaccurate data will lower users trust in the data. To avoid this make sanity checks that data is collected as you would expect and remember to disable old reports as your implementation changes over time.
Tip #4: Add variable descriptions
This is so simple and it keeps surprising me how few benefits from this feature. In the Admin Console, when enabling/edit variables, you can add a description to it. This will make it easier for users to understand what the data is showing. On a similar note, you should also be using tags for your calculated metrics and segments. It may not seem important to begin with, but the sooner you start to do this, the better. At some point, you’ll have loads of them and you’ll have forgotten what you created them for. These tags will also help others to re-use your segments/metrics when tagged appropriately.
Tip #5: Benefit from approved metrics and segments
The other day when I logged into a customer account I saw they had 35(!) bounce rate metrics listed – all named the same. The biggest problem was that they weren’t based on the same logic. Not only is it confusing that the same metric appears 35 times, but it is also critical if the same metric is reporting different numbers or aren’t based on the same logic when reported upwards in the organisation.
Do yourself a favour and create all the official and approved segments and metrics and mark them as ‘approved’. This will ensure that all users know which metric to use and that all are reporting using the same logic.
You have spent a lot of hours and money on your implementation and it has most likely been costly for your company, so ensure you keep it updated and easy to use for users on all levels. What are you doing to ensure a solid implementation?
