Een gebeurtenis gaat af. Ze legt een aankoop vast. Het aankoopbedrag moet $99 zijn. Maar ze legt $990 vast. Een decimaalteken staat verkeerd. Dat is slechte data. Een gebeurtenis gaat af. Ze moet een productcategorie vastleggen. Maar ze legt niets vast. Dat is ontbrekende data. Slechte data vertekent je analytics. Verkeerde conclusies volgen. Je neemt beslissingen op basis van verkeerde cijfers. Datakwaliteit is cruciaal. Elke gebeurtenis moet nauwkeurige data vastleggen. Elke parameter moet de juiste waarde hebben. Dat vraagt een zorgvuldige opzet en voortdurende controle.
In dit artikel lees je hoe je ervoor zorgt dat gebeurtenisparameters data van goede kwaliteit vastleggen.
Waarom datakwaliteit ertoe doet
Analytics is alleen nuttig als de data klopt. Je analyseert conversiepercentages. Je optimaliseert op basis van de cijfers. Maar als de conversiecijfers niet kloppen, klopt je optimalisatie niet. Je optimaliseert misschien het verkeerde. Je mist misschien kansen.
Slechte data stapelt zich op. Een kleine fout in één gebeurtenis wordt een grote fout in het totaal. Hebben 10 procent van de aankoopgebeurtenissen een verkeerd bedrag, dan zijn je omzetcijfers 10 procent fout. Dat is een flinke fout voor zakelijke beslissingen.
Datakwaliteit bouwt vertrouwen op. Je team vertrouwt analytics als de cijfers kloppen. Ze nemen beslissingen op basis ervan. Is data onbetrouwbaar, dan stoppen ze met vertrouwen. Dan stoppen ze met het gebruiken van analytics.
Gebeurtenisparameters precies definiëren
Bepaal voordat je een gebeurtenis maakt wat elke parameter moet bevatten. Naam van de parameter. Beschrijving van de parameter. Datatype van de parameter. Verwacht bereik van waarden. Waar de waarde vandaan komt.
Een parameter voor een aankoopbedrag moet duidelijk zijn gedefinieerd. Is het het totaal inclusief btw en verzendkosten? Of alleen de kosten van het product? Is het in centen of in dollars? Is het tekst of een getal? Definieer dit precies. De invoering hangt ervan af.
Documenteer elke parameter. Documenteren voorkomt verwarring. Een ontwikkelaar die de gebeurtenis invoert, weet precies wat er vastgelegd moet worden. Een analist die de data leest, weet wat ze betekent.
Data uit de juiste bron halen
Datakwaliteit hangt af van het vastleggen uit de juiste bron. Een aankoopbedrag moet uit je systeem voor bestellingen komen. Geen schatting. Geen invoer van een gebruiker. Het echte bevestigde bedrag.
Een productcategorie moet uit je productdatabase komen. Niet uit wat de gebruiker typte. Niet uit een gok. De categorie die klopt.
Haal data zo dicht mogelijk bij de bron. Echte systemen voor transacties kennen de echte bedragen. Echte databases kennen de echte indeling. Haal het daar vandaan. Reken niet en schat niet.
Data valideren voordat gebeurtenissen afgaan
Valideer data voordat je haar naar analytics stuurt. Controleer dat het aankoopbedrag een getal is. Controleer dat het positief is. Controleer dat het product-id bestaat.
Validatie vangt fouten voordat ze analyticsproblemen worden. Een ontwikkelaar maakt een fout. Validatie vangt haar. De data bereikt analytics nooit. De gebeurtenis gaat af met goede data.
Veelgebruikte validaties zijn controle van het type (is het tekst, een getal of een datum), controle van het bereik (valt het binnen de verwachte waarden) en controle van het bestaan (bestaat het item waarnaar wordt verwezen).
Consistente namen voor parameters gebruiken
Namen van parameters zijn belangrijk. Noemt de ene gebeurtenis een parameter "amount" en een andere "purchase_amount", dan behandelen je rapporten ze als verschillende parameters. Je kunt ze niet vergelijken.
Maak een standaard voor namen. Alle geldbedragen krijgen het achtervoegsel "_amount". Alle id's krijgen het achtervoegsel "_id". Alle aantallen krijgen het achtervoegsel "_count". Pas deze standaard consequent toe.
Als je een parameter eenmaal een naam geeft, wijzig die dan niet. Wijzigen van parameternamen splitst je data. Oude data staat onder de oude naam. Nieuwe data staat onder de nieuwe naam. Rapporten tonen gesplitste data. Zorg dat de naamgeving klopt voordat je live gaat.
Randgevallen en ontbrekende data afhandelen
Sommige data is moeilijk vast te leggen. Offline transacties. Transacties uit oude systemen. Onvolledige gebruikersinformatie. Hoe ga je om met ontbrekende data?
Stuur nooit gebeurtenissen met ontbrekende kritieke parameters. Kun je het aankoopbedrag niet krijgen, laat de aankoopgebeurtenis dan niet afgaan. Stuur de gebeurtenis alleen als je complete data hebt.
Gebruik voor optionele data consequent null of een lege tekst. Gebruik niet "unknown" op de ene plek en "N/A" op een andere. Consequent omgaan met ontbrekende data maakt analyse makkelijker.
Datakwaliteit in de loop van de tijd bewaken
Datakwaliteit gaat achteruit. Koppelingen breken. Systemen veranderen. Wat vorige maand werkte, kan deze maand breken. Houd voortdurend toezicht.
Let op onverwachte patronen. Null-waarden waar ze niet horen. Uitschieters in bedragen. Ontbrekende parameters. Stel meldingen in. Ziet iets er verkeerd uit, zoek het dan uit.
Bekijk rapporten over datakwaliteit regelmatig. De meeste analyticsplatformen hebben rapporten over datakwaliteit. Gebruik ze. Vang problemen vroeg.
Veelgestelde vragen
Hoe testen we of gebeurtenisparameters goed worden vastgelegd?
Gebruik realtime-rapporten. Voer de actie uit. Kijk naar het rapport. Controleer dat de gebeurtenis verschijnt met de juiste parameters en waarden. Gebruik de ontwikkelaarstools van je browser. Bekijk de data voordat ze naar analytics gaat. Controleer of ze overeenkomt met je verwachting. Met de websitebouwer van WEMASY stel je dit direct in op je website.
Wat als een parameterwaarde altijd leeg is?
De data wordt niet vastgelegd. Controleer je invoering. Is de parameter goed ingesteld? Is de data beschikbaar op het moment dat de gebeurtenis afgaat? Is er een probleem met timing? Zoek de bron uit. Stuur geen lege data. Los de oorzaak op.
Kunnen we een parameter hernoemen nadat er data is verzameld?
Technisch wel, maar doe het niet. Oude data blijft onder de oude naam staan. Nieuwe data komt onder de nieuwe naam. Je rapporten tonen gesplitste data. Zorg dat de naam vanaf het begin klopt. Moet je toch hernoemen, houd dan rekening met de splitsing van data.
Hoe gaan we om met valuta in gebeurtenisparameters?
Leg het numerieke bedrag en de valutacode apart vast. Het bedrag in een parameter als "purchase_amount". De valuta in een parameter als "currency_code" met waarden als "USD" of "EUR". Zo kun je over valuta's heen analyseren.
Moeten we ruwe data of opgemaakte data in parameters opslaan?
Sla ruwe data op. Bedragen in centen, niet in dollars. Tijdstempels in ISO-formaat, niet leesbaar voor mensen. Opgemaakte data is moeilijker te analyseren en te vergelijken. Ruwe data is flexibeler. Maak haar in rapporten op als dat nodig is.
Wat is een redelijk foutpercentage voor gebeurtenisdata?
Nul is het doel. Maar in de praktijk is minder dan 1 procent acceptabel. Sommige randgevallen hebben problemen. Oude systemen hebben misschien geen data. Maar komt het foutpercentage boven 1 tot 2 procent, zoek dan uit wat er speelt en los de oorzaak op.