Keep Your Web Data Clean and Safe to Drink — Part I

Con­tin­u­ing my series on the “Seven Keys to Cre­at­ing a Data-Driven Orga­ni­za­tion”, I’d like to now focus on the actual web data, which under­lies every­thing. In my last two-part arti­cle, I talked about the impor­tance of deliv­er­ing quick wins to your orga­ni­za­tion. How­ever, with­out ade­quate and reli­able data, quick wins are not even pos­si­ble. It’s impor­tant that ana­lysts, man­age­ment, and every­body else in the com­pany can trust the data.

When I think of data, I often com­pare it to water. In the real world, water is a neces­sity of life. Data is a neces­sity of busi­ness opti­miza­tion. Just like drink­ing water, you want your web data to be clean and safe for con­sump­tion. Com­pa­nies typ­i­cally col­lect large vol­umes of data. Remark­ably, only .007% of all the water on the Earth is acces­si­ble for direct use by peo­ple. I think of cus­tom report­ing as the con­sum­able sub­set of all your web data. Most peo­ple in your com­pany don’t want to drink an ocean of data (they would drown try­ing), but they would find a pitcher of ice, cold KPIs very refresh­ing on a reg­u­lar basis.

Now what if that pitcher of KPIs was dirty or empty from time-to-time? Peo­ple either stop drink­ing entirely or look for alter­na­tive sources of data. That’s what you want to avoid. Your data-driven ini­tia­tives can quickly unravel if your com­pany sus­pects the web data is bad or incomplete.

Why is data val­i­da­tion important?

Just like unsafe drink­ing water causes seri­ous issues in devel­op­ing nations, bad or unre­li­able data can cause a num­ber of orga­ni­za­tional prob­lems. I’ve iden­ti­fied four prob­lems that can be avoided with proper data val­i­da­tion. Each of these prob­lems can veer your com­pany off the path to becom­ing a data-driven organization.

1. Avoid costly mis­takes: You want to pre­vent hav­ing incor­rect data that may mis­lead your company’s deci­sion mak­ing. Whether it’s a false pos­i­tive or a false neg­a­tive, bad data can lead to erro­neous con­clu­sions and costly mis­steps by a busi­ness. Ana­lysts can inter­pret good data incor­rectly. How­ever, you’re already behind the eight ball if you’re unknow­ingly ana­lyz­ing bad data.
2. Avoid miss­ing insights: If a com­pany fails to col­lect all of the nec­es­sary data, it can miss valu­able oppor­tu­ni­ties to improve the busi­ness. From a user adop­tion per­spec­tive, the web ana­lyt­ics team can also pass up good oppor­tu­ni­ties to answer impor­tant busi­ness ques­tions com­ing from senior man­age­ment and the rest of the com­pany. Rather than being the hero, you end up being the zero.
3. Avoid fire drills: If the data is shaky or unre­li­able, web ana­lyt­ics pro­fes­sion­als can waste a sig­nif­i­cant por­tion of their time respond­ing to fire drills. Rather than spend­ing their time on high-value activ­i­ties such as user edu­ca­tion, analy­sis, or test­ing, they are forced to respond to ran­dom data discrepancies.
4. Avoid fly­ing blind: Inter­nal doubts about data accu­racy can quickly erode con­fi­dence in a web ana­lyt­ics pro­gram. When peo­ple within the orga­ni­za­tion decide it is safer to use no data than per­ceived bad data, you have a seri­ous prob­lem on your hands. When you’re try­ing to start a data-driven rev­o­lu­tion at your com­pany, the last thing you need is a “data-shaken” counter-revolution to undo all your progress.

Ensure data val­i­da­tion is baked into your process

When you learn that a new site is going live on a com­pressed time­line, the ten­dency is to rush the site tag­ging — and espe­cially the QA process of the imple­men­ta­tion. Some­times the QA process is skipped entirely. Sur­pris­ingly, the same peo­ple that exerted pres­sure to get the site live “at all costs” are also fre­quently the first ones to ask about the site met­rics after launch.

Sur­prise, sur­prise - garbage in, garbage out.

The goal shouldn’t just be about launch­ing a new site quickly but also about gain­ing use­ful insights along the way, which will help to opti­mize dif­fer­ent parts of the busi­ness. Was this micro-site worth launch­ing in the first place or should we scrap the next three we have lined up? How can the micro-site be opti­mized because there appears to be an issue with the reg­is­tra­tion page? Deploy with good data and you can answer these ques­tions. Deploy with­out data or dirty/incomplete data, and you will lan­guish in ignorance.

Qual­ity assur­ance or data val­i­da­tion should be baked into your web devel­op­ment and tag­ging process. It is less expen­sive and time con­sum­ing to fix an error before deploy­ment rather than after the fact when IT resources have rolled onto other projects. You need to ensure there’s ample time fac­tored in for data val­i­da­tion because bad or use­less data is the same as no data. Make sure that you lean on your exec­u­tive spon­sor for sup­port when inter­nal teams are pres­sur­ing for excep­tions to the tag­ging stan­dards or QA process.

In the next part of this arti­cle, I’ll exam­ine impor­tant con­sid­er­a­tions for your data val­i­da­tion efforts.