Design pattern #6: Události v datech | Mňamka #237
Máme tu další várku design patternů! Pojďme si ukázat, jak můžeme pracovat s událostmi v datech - zajímá vás, co předcházelo zákaznické registraci? Průměrný počet dní mezi objednávkami? Nebo jak se mění zdroj návštěv u jednotlivých klientů? Není to nic složitého!
1. Absolutní pořadí v rámci “partition” (např. klienta)
Typickým use casem pro tohle řešení je například analytika akvizičního “funnelu”, kdy sledujete jakým způsobem (a odkud) uživatel přicházel na Váš produktový web předtím, než se zaregistroval nebo udělal nákup. Může Vám to velmi pomoci v pochopení patternů chování jednotlivých zákazníků, nebo skupin, nebo třeba odhalit mezery v akvizičním procesu
Podobně jako v případě “prvního výskytu” události, First = yes / no, můžeme očíslovat pořadí výskytu událostí v rámci jedné partition (např. 1., 2., 3. objednávka, návštěva webu apod. konkrétního zákazníka).
Níže se můžete podívat na příklad konkrétního SQL (Snowflake), kterým se tohle řeší. Napadá Vás k čemu dalšímu by se tenhle vzor dal použít?
2. Days_since_previous jako fakt i sgroupovaný atribut
Dny od předchozí události, typicky objednávky, ukládáme jako fakt (počet dní) i jako zgroupovaný atribut (tj. uplynulo od poslední objednávky třeba měně než 7 dní, 14 dní, 30 dní, 90+ dní…). Případně mohou být kategoie disjunktní (0-7 dní, 8-14 dní...), záleží na konkrétním use-case.
Proč? Z počtu dní od poslední objednávky můžeme sledovat metriky jako průměrný počet dní mezi objednávkami. Přes sgupované atributy může uživatel snadno slicovat a sledovat chování zákazníků v jednotlivých kategoriích (např. nejvíce zákazníků udělá další objednávku jednou do měsíce, pokud se konkrétní zákazník posune do kategorie ‘90+ dní’, pravděpodobně ho firma ztratí...) Jedná se o typický use case, na který se hodí mít data připravená tak, aby si uživatel mohl snadno vytvářet reporty a metriky. Nehodí se jen pro e-shopy, ale třeba i pokud sledujeme návštěvnost libovolného webu a další use-cases.
Previous atributy
Previous atributy se typicky hodí pro vyhodnocení marketingových kampaní (např. zda se podařilo dostat návštěvníky z cpc do directu, nebo naopak, pokud přišli návštěvníci na web minule přímo a nyní přes placenou kampaň, je kampaň špatně zacílená...). V kombinaci s days_since_previous lze namodelovat celý acquisition funnel. V SQL spočítáme obdobně, pomocí window funkce LAG. Opět se jedná o typický use case.
Máte nějaký další tip, který děláte “vždycky a všude”?
Síla dobře navržených dashboardů a KPI | Mňamka #535
V dnešní době chce být každý "data-driven" – rozhodovat se na základě dat, a ne podle pocitů. Jedním z klíčových způsobů, jak toho dosáhnout, jsou správně nastavené KPI a přehledné dashboardy. Ty poskytují jasný přehled o výkonnosti a pomáhají firmám činit rozhodnutí, která opravdu stojí na datových základech, ne na odhadech.
Klíčové ukazatele výkonnosti (KPI): Jak je správně nastavit a efektivně vyhodnotit pomocí business intelligence | Mňamka #534
Jak efektivně řídit růst a sledovat dosažení cílů? Jak klíčové ukazatele výkonnosti (KPI) pomáhají firmám zlepšovat výkon a naplňovat strategické záměry?V článku najdete příklady KPI pro oblasti jako finance, marketing, zákaznický servis, výroba, lidské zdroje a IT, včetně praktických příkladů jejich využití. Zjistěte, jak zavést a sledovat KPI, abyste získali lepší přehled o efektivitě klíčových procesů.
Datové sklady, jezera a lakehouse: Jak vybrat správnou architekturu pro správu dat? | Mňamka #533
Svět správy dat prošel rychlým vývojem, který je poháněn rostoucí potřebou zpracovávat a analyzovat obrovské množství dat v reálném čase. Firmy, které chtějí porozumět svým datům, narazily na různé architektury – datové sklady, datová jezera a nyní i tzv. lakehouse – které nabízejí různé možnosti pro ukládání a správu dat. Tento článek se zabývá těmito třemi architekturami, porovnává jejich výhody a nevýhody a podrobněji se zaměřuje na lakehouse, nejnovější inovaci, která se snaží řešit problémy z dřívějších systémů.
