Ensuring data quality — part 1: Human skills to stay up to speed

Have you ever driven a car with a faulty fuel gauge? The needle tells you the tank is full, but you’ve already driven 150 kilometres since last fill-up. At first, you might think you got a great deal – what a fuel-efficient car! But as the kilometres pass, doubt creeps in and your confidence in the gauge falters. If this gauge isn’t reliable, who’s to say that the odometer is? Or the speedometer? Web performance indicators face the same quality and reliability concerns. At the beginning of every data project (e.g. dashboarding, webanalytics, DMP, all players dream flawless data collection: comprehensive, precise, and sustainable.

But as the project evolves, these ideals are left behind as the focus turns to what’s essential: collecting reliable data, which will serve as the foundation for future analyses.

The idea here is not to write a book about the impact of erroneous data collection. The consequences are many, and affect each part of the project (financial impact, poor quality, deadline extensions). Though it is commonly accepted that it’s better to invest early for quality data rather than fixing errors later, it remains useful to take a look at different ways to ensure data quality. There are two categories: human professional skills (which will be examined in this article), and tools and processes to implement (which will be examined in a later article).

First key skill: daring

One must be daring to collect good data – not to collect a larger amount of data, but to have the audacity to recognise what is relevant to the business.

Two filters can be applied to determine if a KPI is actually useful:

• What is the alert threshold of this KPI? (the response should be a number)
• What should be done if the threshold is crossed (above or below)? (the response should be an “action” and an “actor”)

Here is where you must be daring, because if one of these questions does not have a response, you must remove the KPI in question from the tagging plan as it does not serve any real purpose. It is for the good of your project and for the quality of your data, as it will allow you to focus on other KPIs (those with real value). Think of yourself as a winemaker, pruning the vines so that only the best grapes will reach maturity and be used in your wine.

Once your KPIs have been carefully selected, you must organise your team.

Second key skill: organisation

Beyond surface discussions, data collection projects are primarily used for business purposes, though they have important technical aspects. It is vital that the link between these two worlds remains strong, because KPI feasibility will depend on the technical environment and what tools are available: a given KPI would likely be difficult (or impossible) to collect from a mobile app, whereas it is natively recorded on a website.

In this context, the project leader must take the various teams into account every step of the way, and not just at the beginning or end.

• If business stakes are forgotten, indicator relevance will suffer. Nothing is worse than sending a performance dashboard to someone that doesn’t actually need it.
• If developers are isolated, metrics will be less reliable. Replacing a productSku with a productId could sink half a project if business teams needed granular data for their analyses.

Organisation is thus a must to make sure that everyone involved is on the same page. Checking results of KPI tests is a good example: this meeting is the opportunity to check in on technical aspects (integration of the dataLayer) which in turn helps teams to anticipate the impact implementations will have on KPIs and data quality in the interface. This is also when you decide whether KPIs should be kept in priority or thrown out, if the schedule requires.

Third and final key skill: curiosity

In a context where business performance indicators (and their reliability) are highly dependant on technical feasibility, teams must make and understand the connection between a KPI framework and implementing a tagging plan in JavaScript. It is thus necessary to have team players with hybrid skills, who can adapt to different profiles (C-Level or developer) and learn new collection and analysis techniques (server-side TMS ,  hybrid apps, offline tracking, etc.). This also means that teams must have the time to learn about these technologies, or else have someone internally capable of doing so.

But everyone’s qualities are dulled when it comes to managing quality — work can get sloppy, or repetitive tasks can take their toll. Even with the best of intentions, professional skills need direction in order to be used wisely, like a train placed on the right track. In the second part of this article, we discuss the tools and processes that can be implemented.