En händelse utlöses. Den registrerar ett köp. Köpbeloppet ska vara $99. Men den registrerar $990. En decimal är fel. Det är dålig data. En händelse utlöses. Den ska fånga en produktkategori. Men den fångar ingenting. Det är saknad data. Dålig data snedvrider din analytics. Fel slutsatser följer. Du fattar beslut utifrån fel siffror. Datakvalitet är avgörande. Varje händelse måste fånga exakt data. Varje parameter måste ha rätt värde. Det kräver noggrann uppsättning och löpande uppföljning.
Den här artikeln förklarar hur du ser till att händelseparametrar fångar data av hög kvalitet.
Varför datakvalitet är viktig
Analytics är bara användbar om datan är exakt. Du analyserar konverteringsgrader. Du optimerar utifrån siffrorna. Men om konverteringssiffrorna är fel blir din optimering fel. Du kanske optimerar fel sak. Du kanske missar möjligheter.
Dålig data växer. Ett litet fel i en händelse blir ett stort fel i sammanställningen. Om 10 procent av köphändelserna har fel belopp är dina intäktssiffror fel med 10 procent. Det är ett betydande fel i affärsbeslut.
Datakvalitet bygger förtroende. Ditt team litar på analytics när siffrorna är exakta. De fattar beslut utifrån den. Om datan är opålitlig slutar de lita på den. De slutar använda analytics.
Definiera händelseparametrar exakt
Bestäm innan du skapar en händelse vad varje parameter ska innehålla. Parameternamn. Parameterbeskrivning. Parameterns datatyp. Förväntat värdeintervall. Var värdet kommer från.
En parameter för köpbelopp bör definieras tydligt. Är det totalen inklusive moms och frakt. Eller bara produktkostnaden. Är det i cent eller dollar. Är det text eller ett tal. Definiera det exakt. Genomförandet beror på det.
Dokumentera varje parameter. Dokumentation förhindrar förvirring. En utvecklare som genomför händelsen vet exakt vad som ska fångas. En analytiker som läser datan vet vad den representerar.
Hämta data från rätt källa
Datakvalitet beror på att du hämtar från rätt källa. Ett köpbelopp ska komma från ditt orderhanteringssystem. Inte en uppskattning. Inte ett värde som användaren skrivit in. Det faktiska bekräftade beloppet.
En produktkategori ska komma från din produktdatabas. Inte från vad användaren skrev. Inte en gissning. Den auktoritativa kategorin.
Hämta data så nära källan som möjligt. Verkliga transaktionssystem känner till de verkliga beloppen. Verkliga databaser känner till den verkliga kategoriseringen. Hämta därifrån. Räkna inte ut eller uppskatta.
Validera data innan händelser utlöses
Validera data innan du skickar den till analytics. Kontrollera att köpbeloppet är ett tal. Kontrollera att det är positivt. Kontrollera att produkt-ID finns.
Validering fångar fel innan de blir analytics-problem. En utvecklare gör ett misstag. Valideringen fångar det. Datan når aldrig analytics. Händelsen utlöses med bra data.
Vanliga valideringar är typkontroll (är det text, tal eller datum), intervallkontroll (ligger det inom förväntade värden) och existenskontroll (finns den refererade posten).
Använd konsekventa parameternamn
Parameternamn spelar roll. Om en händelse kallar en parameter amount och en annan kallar den purchase_amount behandlar dina rapporter dem som olika parametrar. Du kan inte jämföra dem.
Skapa en namnstandard. Alla penningvärden använder suffixet _amount. Alla ID använder suffixet _id. Alla antal använder suffixet _count. Tillämpa standarden konsekvent.
När du har namngett en parameter, ändra den inte. Ändrade parameternamn delar upp din data. Gammal data ligger under det gamla namnet. Ny data ligger under det nya namnet. Rapporterna visar delad data. Få namngivningen rätt innan du lanserar.
Hantera specialfall och saknad data
Viss data är svår att fånga. Transaktioner offline. Transaktioner i äldre system. Ofullständig användarinformation. Hur hanterar du saknad data.
Skicka aldrig händelser där viktiga parametrar saknas. Om du inte kan få fram köpbeloppet, utlös inte köphändelsen. Skicka händelsen bara när du har komplett data.
För valfri data, använd null eller tom sträng konsekvent. Använd inte unknown på ett ställe och N/A på ett annat. Konsekvent hantering av saknad data gör analysen enklare.
Följ datakvaliteten över tid
Datakvaliteten försämras med tiden. Integrationer går sönder. System ändras. Det som fungerade förra månaden kan gå sönder den här månaden. Följ upp löpande.
Leta efter oväntade mönster. Nullvärden där de inte ska finnas. Extrema värden i belopp. Saknade parametrar. Ställ in larm. Om något ser fel ut, undersök.
Gå igenom rapporter om datakvalitet regelbundet. De flesta analytics-plattformar har rapporter om datakvalitet. Använd dem. Fånga problem tidigt.
Vanliga frågor
Hur testar vi om händelseparametrar fångas rätt?
Använd realtidsrapporter. Gör handlingen. Titta på rapporten. Kontrollera att händelsen syns med rätt parametrar och värden. Använd webbläsarens utvecklarverktyg. Granska datan innan den skickas till analytics. Kontrollera att den stämmer med förväntningarna. Med WEMASY webbplatsbyggare kan du ställa in det här direkt på din webbplats.
Vad gör vi om ett parametervärde alltid är tomt?
Datan fångas inte. Kontrollera ditt genomförande. Är parametern rätt konfigurerad. Finns datan tillgänglig när händelsen utlöses. Finns det ett problem med timing. Felsök källan. Skicka inte tom data. Rätta grundorsaken.
Kan vi byta namn på en parameter efter att data har samlats in?
Tekniskt sett ja, men gör det inte. Gammal data ligger kvar under det gamla namnet. Ny data hamnar under det nya namnet. Dina rapporter visar delad data. Få namnet rätt från början. Om du måste byta namn, planera för att datan delas upp.
Hur hanterar vi valuta i händelseparametrar?
Fånga det numeriska beloppet och valutakoden separat. Beloppet i en parameter som purchase_amount. Valutan i en parameter som currency_code med värden som USD eller EUR. Då kan du analysera över valutor.
Ska vi lagra rådata eller formaterad data i parametrar?
Lagra rådata. Belopp i cent, inte dollar. Tidsstämplar i ISO-format, inte läsbara för människor. Formaterad data är svårare att analysera och jämföra. Rådata är mer flexibel. Formatera den i rapporterna vid behov.
Vilken felfrekvens är rimlig för händelsedata?
Noll är målet. Men i praktiken är under 1 procent acceptabelt. Vissa specialfall får problem. Äldre system kanske saknar data. Men om felfrekvensen överstiger 1 till 2 procent, undersök och rätta grundorsaken.