| Insights
Driving value with efficient data gathering
The process of an analytics implementation always starts with the discussion of requirements.
Different people in different teams will each want to know different things about the website or app’s performance and usage. Marketers will want to know the performance of their campaigns against specific on-site events, content writers might want to know about user engagement with their specific pieces, while ecommerce teams might want to know conversion rates from product views to conversion.
Equally, the business might have some KPIs and business objectives that feed into this. Over and above this, there will be some common metrics and dimensions that are either part of every analytics implementation, or are important in some sectors but not others.
Either way, once this process is complete, you end up with quite a long list of requirements that, when translated into a solution design, means quite a lot of variables are needed to capture all of the data.
Efficient data capture
At Yard, we have delivered a lot of analytics implementations varying in sizes from small, single site implementations to large, multi-site implementations across app and web. We’ve seen implementations with hundreds of variables, and some with fewer than 20.
When it comes to efficiency, it makes sense to only capture what is needed. Too often, some data is captured, and it’s never used.
When we get involved with a new client, our first task is to perform a “health check”, which allows us to see how well the analytics implementation has been done, as well as giving us insight into what they’re capturing. Once we’ve completed this, we almost always end up with a list of variables that fit into one of these categories:
They know what the variable is for, but they don’t use it
They know what the variable is for, but they don’t know if it’s being used
They don’t know what the variable is for
The variable doesn’t work, and hasn’t for a long time
What this means is that the analytics data base is being filled with data that’s not needed, and there was work done to implement these data points up front.
So, in terms of efficiency, the impacts these variables have are:
Increased effort to capture these variables either as part of the initial implementation or even later on, separately.
Additional configuration in terms of classifications or processing rules for variables where relevant.
Removal or repurposing of these data points periodically can add unnecessary effort.
Having a lot of data points can add confusion, especially if some of them are similarly named. Which means building reports can take longer.
Depending on the technology/technologies, it can have an impact on loading times or publishing the data capture, as well as report population.
Additional considerations
Obviously, there are caveats here. The age of the implementation can have an impact. The site might have changed over time and some variables that were relevant no longer work. People move on and the implementation they managed didn’t have sufficient documentation.
A business’s KPIs or requirements also change over time, so previously useful variables are no longer used. There are also certain variables that are useful to capture, even when they’re not always used, because they help with debugging in some cases.
With that said, there are also processes that can help. Up-to-date and detailed documentation will always help. Periodically reviewing the implementation and the configured metrics/dimensions can be done to ensure everything is still relevant and working correctly. Equally, setting up alerts can let you know when variables stop working, this can be useful to help decide whether it should be fixed or scrapped if no longer relevant. When site/journey changes occur, removing or repurposing no-longer relevant variables etc.
These can help with ongoing efficiencies, but with new implementations, ensuring that only variables that are required is the best thing to do. This is key for an efficient initial implementation which reduces the cost and time-to-complete.
