Spustí se událost. Zaznamená nákup. Částka nákupu by měla být $99. Ale zaznamená se $990. Špatně je desetinná čárka. To jsou špatná data. Spustí se událost. Měla by zachytit kategorii produktu. Ale nezachytí nic. To jsou chybějící data. Špatná data zkreslují vaši analytiku. Následují špatné závěry. Rozhodujete se podle špatných čísel. Kvalita dat je zásadní. Každá událost musí zachytit přesná data. Každý parametr musí mít správnou hodnotu. To vyžaduje pečlivé nastavení a průběžnou kontrolu.
Tento článek vysvětluje, jak zajistit, aby parametry událostí zachycovaly kvalitní data.
Proč na kvalitě dat záleží
Analytika je užitečná jen tehdy, když jsou data přesná. Analyzujete konverzní poměry. Optimalizujete podle čísel. Ale pokud jsou konverzní čísla špatně, je špatně i vaše optimalizace. Můžete optimalizovat špatnou věc. Můžete přijít o příležitosti.
Špatná data se násobí. Malá chyba v jedné události se v souhrnu změní ve velkou chybu. Pokud má 10 procent událostí nákupu špatné částky, vaše čísla tržeb jsou o 10 procent mimo. To je významná chyba v obchodních rozhodnutích.
Kvalita dat buduje důvěru. Váš tým věří analytice, když jsou čísla přesná. Rozhoduje se podle ní. Pokud jsou data nespolehlivá, přestane jim věřit. Přestane analytiku používat.
Definujte parametry událostí přesně
Než událost vytvoříte, definujte, co má každý parametr obsahovat. Název parametru. Popis parametru. Datový typ parametru. Očekávaný rozsah hodnot. Odkud hodnota pochází.
Parametr částky nákupu by měl být jasně definován. Jde o celkovou částku včetně daně a dopravy? Nebo jen o cenu produktu? Je v centech, nebo v dolarech? Je to řetězec, nebo číslo? Definujte to přesně. Závisí na tom implementace.
Dokumentujte každý parametr. Dokumentace předchází zmatku. Vývojář, který událost implementuje, přesně ví, co zachytit. Analytik, který data čte, ví, co představují.
Zachycujte data ze správného zdroje
Kvalita dat závisí na zachycení ze správného zdroje. Částka nákupu by měla pocházet z vašeho systému zpracování objednávek. Ne z odhadu. Ne ze vstupu uživatele. Ze skutečné potvrzené částky.
Kategorie produktu by měla pocházet z vaší databáze produktů. Ne z toho, co uživatel napsal. Ne z odhadu. Z autoritativní kategorie.
Získávejte data co nejblíže zdroji. Skutečné transakční systémy znají skutečné částky. Skutečné databáze znají skutečné zařazení. Čerpejte odtud. Nepočítejte ani neodhadujte.
Ověřte data dřív, než se události spustí
Data ověřte dřív, než je pošlete do analytiky. Zkontrolujte, že částka nákupu je číslo. Zkontrolujte, že je kladná. Zkontrolujte, že ID produktu existuje.
Validace zachytí chyby dřív, než se stanou problémem analytiky. Vývojář udělá chybu. Validace ji zachytí. Data se do analytiky nikdy nedostanou. Událost se spustí se správnými daty.
Běžné validace zahrnují kontrolu typu (je to řetězec, číslo, nebo datum), kontrolu rozsahu (je hodnota v očekávaném rozmezí) a kontrolu existence (existuje odkazovaná položka).
Používejte jednotné názvy parametrů
Na pojmenování parametrů záleží. Pokud jedna událost nazývá parametr „amount“ a jiná „purchase_amount“, vaše reporty je berou jako různé parametry. Nemůžete je porovnat.
Vytvořte standard pojmenování. Všechny peněžní hodnoty používají příponu „_amount“. Všechna ID používají příponu „_id“. Všechny počty používají příponu „_count“. Tento standard uplatňujte důsledně.
Jakmile parametr pojmenujete, neměňte ho. Změna názvů parametrů rozděluje vaše data. Stará data jsou pod starým názvem. Nová data pod novým názvem. Reporty ukazují rozdělená data. Pojmenování nastavte správně dřív, než nasadíte.
Zvládněte okrajové případy a chybějící data
Některá data se těžko zachycují. Offline transakce. Transakce ze starších systémů. Neúplné informace o uživatelích. Jak naložit s chybějícími daty?
Nikdy neposílejte události s chybějícími kritickými parametry. Pokud nemůžete získat částku nákupu, událost nákupu nespouštějte. Událost pošlete jen tehdy, když máte kompletní data.
U nepovinných dat používejte null nebo prázdný řetězec jednotně. Nepoužívejte „unknown“ na jednom místě a „N/A“ na jiném. Jednotné zacházení s chybějícími daty usnadňuje analýzu.
Sledujte kvalitu dat v čase
Kvalita dat se časem zhoršuje. Integrace se rozbíjejí. Systémy se mění. Co fungovalo minulý měsíc, se může rozbít tento měsíc. Sledujte průběžně.
Hlídejte neočekávané vzorce. Prázdné hodnoty tam, kde nemají být. Extrémy v částkách. Chybějící parametry. Nastavte upozornění. Pokud něco vypadá špatně, zjistěte proč.
Pravidelně procházejte reporty o kvalitě dat. Většina analytických platforem má reporty o kvalitě dat. Používejte je. Problémy zachyťte brzy.
Často kladené otázky
Jak otestujeme, zda parametry událostí zachycují správně?
Použijte reporty v reálném čase. Proveďte akci. Sledujte report. Zkontrolujte, že se událost objeví se správnými parametry a hodnotami. Použijte vývojářské nástroje prohlížeče. Prohlédněte data dřív, než se odešlou do analytiky. Ověřte, že odpovídají očekávání. S Tvůrcem webů WEMASY to můžete nastavit přímo na svém webu.
Co když je hodnota parametru pořád prázdná?
Data se nezachytávají. Zkontrolujte implementaci. Je parametr nastaven správně? Jsou data k dispozici, když se událost spustí? Nejde o problém s načasováním? Odladte zdroj. Neposílejte prázdná data. Opravte základní příčinu.
Můžeme parametr přejmenovat po sběru dat?
Technicky ano, ale nedělejte to. Stará data zůstanou pod starým názvem. Nová data půjdou pod nový název. Vaše reporty ukážou rozdělená data. Název nastavte správně od začátku. Pokud musíte přejmenovat, počítejte s rozdělením dat.
Jak zacházet s měnou v parametrech událostí?
Zachyťte číselnou částku a kód měny zvlášť. Částku v parametru jako „purchase_amount“. Měnu v parametru jako „currency_code“ s hodnotami jako „USD“ nebo „EUR“. Umožní vám to analyzovat napříč měnami.
Máme v parametrech ukládat surová, nebo formátovaná data?
Ukládejte surová data. Částky v centech, ne v dolarech. Časové značky ve formátu ISO, ne čitelné pro člověka. Formátovaná data se hůř analyzují a porovnávají. Surová data jsou flexibilnější. Formátujte je v reportech, pokud je to potřeba.
Jaká míra chyb u dat událostí je rozumná?
Cílem je nula. V praxi je ale přijatelné méně než 1 procento. Některé okrajové případy budou mít problémy. Starší systémy nemusí data mít. Pokud však míra chyb překročí 1 až 2 procenta, zjistěte a opravte základní příčinu.