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”?
Tableau - Performance Tuning (časť 3.) | Mňamka #506
Chcete vědět, jak zlepšit rychlost a efektivitu vašeho dashboardu v Tableau? Tento článek vás seznámí s významem materializace výpočtů, výhodami agregace dat a důležitostí specifikace datových zdrojů. Navíc se dozvíte o nové funkci "workbook optimizer", která vám nabídne automatizované doporučení pro dosažení optimálního výkonu vašeho dashboardu. Přečtěte si více a dozvíte se, jak dosáhnout rychlejšího a hladšího provozu vašich vizualizací v Tableau.
Tableau - Performance Tuning (časť 2.) | Mňamka #503
Dnes nadviažeme pokračovaním na minulotýžďnový článok a pozrieme na niektoré ďalšie možnosti zrýchlenia vašeho pomalého dashboardu. V prípade filtrov tiež platí, že pre performance je lepšie držať ich počet na uzde. Je to spôsobené tým, že načítanie hodnôt pre každý jeden interaktívny filter predstavuje jednu query. Negatívny vplyv na performance sa ešte umocňuje v prípade využitia možnosti “Only Relevant Values”.
Tableau - Performance Tuning (časť 1.) | Mňamka #500
Naimplementovali ste dashboard, vyhrali ste sa s vizuálom, čísla na vám sedia. Násadíte dashboard na Tableau server a idete ho otestovať, tu však narazíte na problém. Dashboard sa načítava extrémne dlho. Pre časovo vyťažený klienta, ktorý potrebuje mať dáta nie len správne, ale aj dostupné v rozumnom čase, je samozrejme takýto stav neakceptovateľný. Čo teraz? Určite nezúfajte, v tomto článku sa s vami podelíme o skúsenosti čo v takom prípade robiť.