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”?
Zeptej se svých dat: BigQuery vs. Fabric vs. Copilot | Mňamka #558
Je to sen skoro každého manažera: místo čekání na analytika prostě napíšu do chatu „jak nám rostly tržby po regionech za poslední kvartál?" a za pár vteřin mám odpověď, ideálně i s grafem. Říká se tomu konverzační analytika a tři velcí hráči ji dnes nabízejí. My jsme si všechny tři osahali. Tady je upřímné srovnání, co funguje a kde to zatím drhne.
Postavili jsme stejného AI chatbota nad firemními daty v Googlu i v Microsoft Azure. | Mňamka #557
Skoro každá firma dneska sedí na hromadě vlastních dokumentů - produktové listy, FAQ, smlouvy, zápisy z projektů. A skoro každá firma by chtěla to samé: chatbota, kterému napíšete otázku a on odpoví z vašich dat, ne z toho, co si kde přečetl na internetu. Zní to jednoduše. My jsme si to chtěli osahat pořádně, a tak jsme jedno a to samé řešení postavili dvakrát - jednou v Google Cloudu, podruhé v Microsoft Azure. Tady je, co z toho vypadlo.
Microsoft Fabric vs. dbt | Mňamka #556
Když firmy modernizují svou datovou platformu, narazí dřív nebo později na otázku, jaký datový stack zvolit a co je pro jejich byznys nejvhodnější. Migrovat na Microsoft Fabric? Nasadit dbt? Otázka je ale položená trochu zavádějícím způsobem, jde totiž o srovnání dvou věcí, které stojí na jiné úrovni datového stacku: Fabric je platforma, dbt je transformační nástroj, který na takové platformě běží. Přesto má smysl se ptát, jak se tyto dva světy doplňují, kde si uvnitř Fabricu konkurují nativní nástroje a dbt, a kdy se vyplatí sáhnout po dbt jako standardní transformační vrstvě.
