Herken je de volgende situatie? Je levert als webanalist een rapportage op en na verloop van tijd ontvang je vragen van mensen die twijfelen of de cijfers wel kloppen. In zo’n situatie gebruikt men hoogstwaarschijnlijk naast jouw rapportage ook data die afkomstig is uit andere bronnen. Rapportages uit een CRM- of ordersysteem worden naast elkaar gebruikt en vervolgens vergeleken met web data uit bijvoorbeeld Google Analytics. Of er worden verschillende analytics systemen met elkaar vergeleken om een oorzaak aan te wijzen voor een verschil dat ergens blijkt te zijn ontstaan. Je raadt het al: ook deze komen vrijwel nooit overeen.

Het gevolg is dat dit soort situaties juist meer vragen oproepen dan beantwoorden waardoor men sneller geneigd is keuzes te baseren op onderbuikgevoel. Dit terwijl we juist datagedreven willen werken! Maar wel het liefst op basis van zoveel mogelijk betrouwbare data.

Datakwaliteit kent geen eindpunt

Datakwaliteit is enorm belangrijk maar tegelijkertijd een heel breed begrip. Je moet het dan ook niet zien als een eindpunt waar je naartoe werkt, maar als een hele wereld op zich. Eén wereld die onderhevig is aan afspraken, processen, rollen en verantwoordelijkheden. Governance zoals dat heet. Begrippen waarmee je als webanalist zeker te maken hebt of krijgt wanneer je in een data-omgeving werkt.

Waar begin je?

Kwaliteit van je web data begint bij het correct inrichten van alle metingen (“tagging”). Doe je dit niet gedegen en test je onvoldoende, dan merk je daar snel genoeg de gevolgen van. Denk aan het ‘gigo’ principe: “garbage in, garbage out”. Hoe vervelend is het als er een campagne is afgelopen en de resultaten niet volledig gemeten zijn? Of wanneer een A/B test drie weken heeft gelopen en achteraf blijkt dat er toch een meet issue was met de variant. Dat is zonde van de tijd én het geld.

Maar hoe ontstaan deze verschillen tussen alle systemen? Hieronder enkele punten die mogelijk van invloed kunnen zijn. Wellicht zijn het allemaal open deuren voor je, zie het dan als een manier om een interne discussie opnieuw aan te zwengelen.

Analytics vs Analytics

Definitie kwestie

Analytics vendors zoals Google of Adobe hanteren op een aantal punten hun eigen definities. Denk alleen al aan het principe van campagne/kanaal attributie of metrics zoals Unique Visitors (Adobe) vs Users (Google). Verschillen tussen analytics pakketten zullen er jammer genoeg altijd zijn.

Uitsluiten van IP adressen

Wanneer je het uitsluiten van IP reeksen te ruim instelt dan kan dit ervoor zorgen dat bepaalde bezoekers en orders onterecht niet worden geregistreerd. Het is overigens wel aan te raden om bots en spiders uit te sluiten.

Opbouw van de pagina

De opbouw van een pagina (zonder fouten) is belangrijk voor het versturen van de analytics data. De laadsnelheid en de gebruikte website technologie zijn hier met name debet aan. Er zit al een behoorlijk verschil in de datakwaliteit wanneer een website statische webpagina’s heeft of wanneer deze als één grote dynamische pagina (via Google’s Angular framework) is opgebouwd. Met het laatste kunnen webpagina’s – bij het navigeren door de bezoeker – soms te snel na elkaar worden getoond waardoor metingen per pagina of te vroeg of te laat worden geïnitieerd. Met als gevolg dat er helemaal niets wordt gemeten.

Pagina’s zonder code

Wanneer al één enkele pagina binnen een website geen analytics code heeft, of wanneer de code van een pagina stelselmatig niet goed wordt uitgevoerd, dan kan dit zonder meer gevolgen hebben op de metingen. Een bezoek kan hierdoor dubbel worden geteld (als “nieuw bezoek”) of het kanaal waarmee de bezoeker de website opnieuw bezoekt kan onterecht worden toegewezen.

Cookie melding

Het analytics image request naar je analytics pakket kan vóór of na het accepteren van de website cookies zijn verstuurd. Het verschil in bijvoorbeeld het aantal orders zit dan vanzelfsprekend in het aandeel bezoekers dat cookies niet heeft geaccepteerd. De locatie en het type cookie melding kunnen ook van invloed zijn op de resultaten.

Back-end vs Analytics

Bedragen met of zonder BTW

De prijzen van producten binnen een order kunnen incl. BTW zijn geregistreerd terwijl via een ander systeem de resultaten excl. BTW worden gerapporteerd. Zorg voor een eenduidig beeld in de uiteindelijke rapportage (incl. toelichting) of zorg ervoor dat de analytics implementatie correct op de andere systemen en rapportages is afgestemd.

Order datum

Het moment van het registreren van een order is cruciaal. Analytics registreert de order direct en dit moment (orderdatum) blijft in de toekomst onveranderd. In een back-end systeem hanteert men vaak ook een order status. In theorie zou de order op een andere dag de status “afgehandeld” kunnen krijgen en dus ook in een andere periode in de business rapportages kunnen verschijnen. Probeer ook te letten op de status die je terugkrijgt van een Payment Provider rond de betaling van een order (zoals “pending” en “canceled”).

Rapportage periode

Wanneer je over een bepaalde periode rapporteert is het relevant om te weten of alle betrokkenen en alle systemen dezelfde periode indeling hanteren. Bepaal eerst uit hoeveel weken een rapportage periode bestaat (bijv. 4 of 5 weken). Vergeet ook niet te bepalen of een week op een zondag of een maandag begint.

Offline orders

Als medewerkers van bijvoorbeeld een klantenservice afdeling toestemming hebben om orders ook rechtstreeks in het ordersysteem van een website te plaatsen gaan zij hiermee voorbij aan de website flow en daarmee ook aan de analytics metingen. Zorg dat je van dit soort situaties op de hoogte bent.

6 Tips uit de praktijk

1. Gebruik een analytics debugger

Gebruik een analytics debugger om de image requests te analyseren die worden verstuurd naar je analytics pakket. Bij voorkeur eentje die wordt aangeboden door de Analytics vendor zelf, bijvoorbeeld Google Tag Assistant voor Google Analytics en Adobe Marketing Cloud Debugger voor Adobe Analytics. Goede alternatieven zijn de Chrome plugins van Omnibug en Dataslayer.

2. Ga nooit alleen uit van de betrouwbaarheid van de ontvangende kant

Als metingen zijn ingesteld zijn we geneigd om snel naar de data te kijken om te zien of er data binnenkomt en vervolgens de conclusie hieraan te verbinden dat de data ook klopt. Dit is een misverstand. Ga nooit alleen uit van de betrouwbaarheid van de ontvangende kant. De versturende kant is namelijk belangrijker. Vanaf de cliënt kan er veel misgaan. Er kunnen in de praktijk meerdere requests tegelijk worden verstuurd op één enkele actie (“trigger”). Men noemt dit ook wel “inflated data” of het genereren van “fake pageviews”.

3. Kijk naar de trend van een bepaalde periode

Absolute aantallen vertellen slechts één kant van het verhaal. Bekijk dus ook altijd de trend van een bepaalde periode. Het kan zijn dat er tussentijds een issue is opgetreden en dit wordt alleen zichtbaar in een trendgrafiek.

4. Controleer op afwijkingen

Controleer op afwijkingen t.o.v. de norm (anomalies) en stel desnoods rapportages in voor de belangrijkste KPI’s en breidt deze uit met automatische alerts.

5. Doe een A/A test

Wanneer je je analytics pakket ook gebruikt om A/B testen te analyseren voer dan vooraf een A/A test uit om te bepalen of de data goed wordt geregistreerd en de bezoekers juist worden verdeeld.

6. Documenteer alles

Als er dingen in je analytics opzet zijn veranderd, zorg ervoor dat dit goed gedocumenteerd wordt. Dit kan bijvoorbeeld door een annotatie in Google Analytics toe te voegen. Hierdoor zorg je ervoor dat de kennis over de implementatie niet van jou afhankelijk is, maar dat de rest van de organisatie ook weet wat er gebeurd is en waarom er eventuele afwijkingen te zien zijn in de data.

Wees gerust, de perfecte analytics implementatie bestaat niet

Ondanks herhaaldelijke inspanningen blijft de volledige of perfecte analytics implementatie een utopie. Het belangrijkste is dat de data die gecollecteerd wordt klopt. Als dit het geval is dan moet je vooral met de data aan de slag gaan. Je kunt je datakwaliteit pas echt verbeteren door ermee te werken.

Blijf dus vooral niet te lang hangen in het perfectioneren van al je metingen. Uiteindelijk moet je er mee aan de slag om erachter te komen wat er wel of niet klopt. Het beschermen van de datakwaliteit is iets waar je constant aan werkt. Het is de kritische houding van jou als webanalist die de kwaliteit van je data waarborgt. Met behulp van de bovenstaande tips hoop ik je al een beetje op weg te helpen maar er zijn vast nog genoeg andere dingen zijn waar je tegenaan zult lopen. Succes!