Monday, December 30, 2019

Jak děláme A/B testování

 Technika A/B testování je velmi mocný nástroj jak posouvat business dopředu testováním a měřením nových nebo existujících featur či jejich dalších iterací na reálných zákaznících.

Proč A/B testy?

Ve chvíli, kdy se ve startupu rozhodnete implementovat nějaký nápad, investujete vaše peníze. Jistě chcete mít nějakou návratnost této investice nebo alespoň dohlédnout, kdy se tak stane.

Jak ovšem poznat, že nový kus kódu opravdu přinesl nějakou pozitivní změnu? V Liftagu třeba jízdy.

Určitě můžete měřit jak často se používá nová featura, nás ale zajímá její dopad na hlavní metriky businessu.

Potřebujete zodpovědet otázku: nenastala by pozitivní či negativní změna metrik i kdybychom neudělali vůbec nic?

Od toho existují A/B testy.

Zdroj: https://www.invespcro.com/

V Liftagu jsme historicky mnoho nápadů implementovali na základě přesvědčení, že to prostě musí fungovat. A/B testování přineslo mnoho překvapení. Zjistili jsme, že i ty nejskvělejší nápady mohou skončit naopak poklesem business metrik, i když na začátku bychom na tuhle variantu vsadili klidně celou výplatu :-)

Jak postupujeme, když realizujeme nějaký A/B test?

  1. Nejprve je třeba se shodnout na zadání a měřených metrikách
  2. Zvolíme vhodné možnosti řešení: A, B, C, atp.
  3. Zvolíme segmenty zákazníků, na kterých to budeme testovat
  4. Zvážíme riziko a zvolíme procenta, která bude daný segment pro danou variantu mít
  5. Pustíme to konečně na zákazníky
  6. Měříme metriky až do chvíle statistické signifikance
  7. Vyhodnocujeme -> analyzujeme -> aplikujeme nové nastavení -> vracíme se do bodu #4
  8. Iterujeme dokud nedosáhneme kýženého úspěchu nebo nevyčerpáme všechny nápady na řešení

1. Problém a metriky

Definovat správně problém a najít vhodné metriky je pochopitelně naprosto zásadní. Někdy máte nápad na featuru, ale nevíte, co vlastně řeší za problém pro business. Konkrétní definici problému jsme často rozlouskli až úvahou nad tím, jaké metriky vlastně chceme měřit, a kam doufáme, že s nimi pohneme. Některé věci se nám původně zdály krásné, ale vůbec nakonec nevedly tou správnou cestou.

Metriky je dobré sepsat, ověřit, zda je vůbec umíme měřit, projít s týmem.

Ve chvíli, kdy víme proč a jak to proč budete měřit, máme krásnou definici zadání s týmem.

2. Možnosti řešení

Pokud známe problém a to proč, v týmu kreativních lidí, kterých je v Liftagu snad většina, vždycky vymyslíme kupu variant řešení.

Důležité je si uvědomit, že jedno must-have řešení je nedělat nic. Bez komparace s ním nikdy nezjistíte, zda váš inkrement práce je k něčemu dobrý. Jedná se o klasickou kontrolku.

3. Segmenty zákazníků

Dalším krokem je zvolit na koho vlastně s danou featurou míříme a s kým ji svážeme. Je možné, aby každá nová objednávka měla jinou variantu řešení, nebo je nutné, aby každý pasažér či řidič viděli konzistentně jeden typ?

Někdy se z definice problému hodí jedno řešení, jindy zase druhé.

4. Riziko a procenta segmentů

Vždy, když něco sázíme do produkce, snažíme se to udělat vypnutelné pomocí konfigurace feature flagů nebo databáze. Budujeme prostředí, kde je možné udělat chybu, ze které se umíme snadno vybrousit.

Stejné pravidlo roll-outu používáme u A/B testů. Na začátku pustíme featuru na malé procento uživatelů a postupně stoupáme na definovaný target. Pochopitelně risk ratio záleží na typu vylepšení. Pokud se jedná o okrajovou věc, můžeme jít do většího rizika, pokud leží na kritické cestě appkou, nemůžeme riskovat puštění rovnou na větší procento uživatelů.

5. Spuštění na reálné zákazníky

Po spuštění featury na živé zákazníky koukáme především na metriky či na logy, zda vše vůbec funguje, není nulová konverze atp.

V tuhle chvíli nemá smysl koukat na konkrétní hodnoty business metrik, tzn. zda je nějaká z nich 55 nebo 64, ale spíš na kontext: funguje to dle očekávání pro danou objednávku či zákazníka, proč si daný pasažér nevybral tohoto řidiče nebo zda to není moc drahé.

Čím dál tím víc se nám vyplácí mít možnost sledovat všechno v real-time a ne zpožděně druhý den přes BI stack.

6. Měření metrik a statistická signifikance

První AB testy v Liftagu se nám nepodařilo dotáhnout do konce právě kvůli chybné interpretaci výsledků. Ať už zle zvolených metrik či neznalosti funkce statistické signifikance.

Zdroj: https://cxl.com/blog/magical-95-statistical-significance/

Každá metrika má totiž tendenci se vlnit. Během určitého časového období nám konverze létá klidně o deset procentních bodů. Podle toho, jak se vyspí pár našich uživatelů, zda zaprší nebo mrzne či je konec prázdnin, samozřejmě nechcete odpískat nějakou naprogramovanou featuru. Všechno má nějaký vliv. Čím kratší období, tím jsme měli větší šanci, že náš test má prostě smůlu a tahle smůla se může lepit pouze na jednu z variant. Existuje mnoho článků, kde je statistická signifikance hezky popsaná, např. tady.

My používáme prostý kalkulátor, který vám říká s jak velkou pravděpodobností můžete věřit výsledku.

Krom statistické signifikance také pozorujeme něco čemu říkáme business cyklus. Ten je v Liftagu roven délce měsíce. Experimentálně jsme přišli na to, že chování uživatelů se opakuje v měsíčním cyklu, takže první týden může signifikantně vítězit jedna varianta leč čtvrtý je to ale už agregovaně varianta B.

Proto testy necháváme dokud nejsou výsledky signifikantní a testy neběží alespoň měsíc.

7. Kolečko iterace

Snažili jsme se vždy udělat jedno celé kolečko od měření, analýzy dat, vymyšlení dalšího kroku a přenastavení.

Tahle část typicky obsahuje analýzu větších — měsíčních — dat, takže rádi používáme náš BI stackDalší kroky se snažíme vymýšlet v cross Liftago teamu s business ownerem. Ten je vtažený do každého vyhodnocení, účastní se “standupu”, prezentace dat atp. Jsme tak velmi akční a můžeme během pár minut do testů zahrnout klidně nějakou odvážnější variantu.

Jakmile víme co dál, provedeme další nastavení, reset testů a zahájíme další iteraci.

8. Iterování

Fungujeme stejně jako phases v rugby. Někdy trvá deset fází než dojdete pro pětku, někdy lehce proběhnete půlku hřiště a někdy prostě o míč přijdete ve druhé fázi.

Přeloženo ze sportovní řeči: iterujete, dokud nepřijdete na variantu s kladným výsledkem, a nebo nerezignujete s tím, že vám došly varianty a ta kontrolní zůstává ta nejlepší.

V některých případech jsme si došli během jednoho kolečka pro vítěznou variantu, která šla rychle na všechny uživatele. V jiném případě jsme za šest iterací našli určité nastavení, které vyhovovalo nějakému procentu našich zákazníků, ale o nějakém plošném globálním vítězství ani potuchy.

A/B testování je prostě hledání, které může skončit vypnutím a zahozením naprogramovaného kusu kódu. V takovém případě ani nic lepšího udělat nemůžeme, protože díky relevantním A/B testům víme, že nám to přináší zápornou hodnotu. Tedy je lepší nedělat nic :-)

Speciální bod bych věnoval tomu, kdy s A/B testem skončit a vítěznou variantu pustit na všechny uživatele. Moje zkušenost je taková, že vše se mění. Vítězná konfigurace může dobře fungovat pár měsíců, trh se změní a najednou může házet horší výsledky. Tohle potřebujete ale vědět. Osobně bych tedy doporučoval držet kontrolku, např. 5 procent, delší dobu a občas ověřit zda vítězná varianta stále dává nejvíc. Přijdete sice u těch pěti percent o increment, ale za cenu, že máte měření z trhu. To je k nezaplacení.

Co nám A/B testy přinesly?

  1. Důvěru v to, že naši zákazníci používají featury a nastavení, které přináší největší hodnotu ze všech verzí, které jsme vymysleli a naprogramovali.
  2. Férový process na vyhodnocení všech názorů na řešení problému. Když neděláte A/B testy, někdy zvítězí názor nejvíc křičícího účastníka debaty v teamu nebo nejvýše postaveného v “org chartu”. S A/B testy se dostane na všechny a realita pak ukáže.
  3. Nemusíme trávit čas neproduktivní analýzou před implementací problému, která je vždy plná pouhých dohadů. Měříte až ve chvíli, kdy máte reálné výsledky od zákazníků. Tvrdá data.
  4. Propojení firmy, když v jednom teamu sedí datový člověk, business owner i backend engineer. Přesah, buy-in a celkově zainteresovanost.
  5. Oprášení matematiky a statistiky ze školních lavic :-)

Tuesday, April 2, 2019

Jak v Liftagu ověřujeme hypotézy na datech pomoci Omnisci

 V minulém článku jsem psal o tom, jak necháváme lidi pracovat s daty, aby si mohli ověřit nápady přímo na nich a nemuseli tak čekat na typicky přehlcené BI oddělení.

Abyste si mohli analyzovat všelijaké nápady, musíte projít dvěma kroky:

  1. Předpřipravit si data, používáme je ve formě super table
  2. Začít skládat nápady do grafů a začít ověřovat svoje hypotézy

Plachta aka super-table

Visualizace v OmniSci jsou silné nad jednou tabulkou. Neumí to dělat vůbec žádné joiny. Což se nakonec ukazuje jakou featura a ne bug.

Fungujeme tak, že máme jednu obrovskou tabulku, kde je všechno pro danou doménu, třeba objednávky či uživatele. Každá řádka má typicky dvě části:

  1. Data spojená s danou entitou. Třeba objednávkou. Její datum, čas, idčka, souřadnice, adresy, platby atp.
  2. Napočítaná data k určitým atributům entity. Např. k příslušnému pasažerovi u objednávky máme napočítaný celkový počet objednávek, které udělal za poslední dobu, počet jízd za poslední dobu, průměrný nabídnutý tarif za poslední dobu atp.

Sloupců prvního typu máme tak 80, druhého 150. Vtip je v tom, že ty dopočítané atributy časem přidáváme podle toho jak hluboko se dostáváme k jádru daného problému.

V tomhle bodě je důležité lidem nebránit v tom, aby si k dané plachtě připočítali cokoliv dle libosti. V tom je ten point rychlého ověření v datech.

Napočítání řešíme takhle:

  1. Všechno máme ideálně v jednom view tak, aby ho šlo snadno upravovat. A časem i refactorovat. Svoje změny tak vidíte ihned v datech.
  2. Výpočet view běží nad Snowflake. Nepotřebujete řešit indexy, Snowflake umí window funkce, takže můžete dělat i velmi složité věci pro připočítaná data. Např. agregace pro objednávky v časovém okolí.
  3. Přes S3 potom data putují do Omnisci.

OmniSci core database je optimalizovaná pro miliony řádků a zjevně stovky sloupců. Za realtimu. GPU podporu zatím vynechme, k tomu se můžeme vrátit později.

Event oriented přístup

Výše jsem nakousl strukturu plachty. Časem se nám velmi osvědčilo podvolit se přístupu OmniSci, takže to rád rozeberu do detailů.

Jak jsem již zmiňoval, jednotlivé plachty mají dva druhy fieldů: ty přímo spojené s doménou a ty dopočítané pro určitou vlastnost.

Lze na to koukat i jiným způsobem: daná entita je event v systému. Například jedna konkrétní vygenerovaná objednávka v určitém čase, místě atp. K němu vy potom lepíte v čase a místě platné informace.

Co to přesně znamená? Uvedu příklad.

Objednávka vznikla v daném čase a místě pro dané pasažéra. Tento pasažér v daném momentu měl určité statistiky. Dejme tomu za předchozích 90 dní k tomuto datu udělal deset objednávek a z nich bylo pět jízd. Zároveň těch pět jízd bylo odjeto s průměrným tarifem 24,5 czk. Těchto dopočítaných hodnot platných pro daný čas máme hromadu.

Jak s tím pracovat? Pojďme do části použití v OmniSci.

Bádání nad problémem

V OmniSci lze pár kliknutími přidávat grafy do boardu. Nemusíte nic předpočítávat ani sestavovat. Všechno si uděláte hezky za online a realtime.

Začínám vždycky tím, že si vyberu nějaký datum či den. Třeba úterý za několik posledních týdnů. Na histogramu mohu vybrat třeba jen dopoledne.

Protože mě zajímá jen pražské centrum, tak přidám mapu.

Dál se chci zaměřit na objednávky, které hodnotíme jako populární.

A celé jsem to dělal, abych podíval, jak dlouhé jízdy naši zákazníci jezdí a čím je platí.

Tady teď mohu zapojit ten eventový přístup. Na předchozích grafech máme vybrané určité objednávky pro určitý typ lidí. Pokud mám u každé z nich napočítané určité statistiky, mohu se hravě podívat, jací pasažéři to jsou. Tedy jaké vzdálenosti běžně jezdí a zda se liší od těch, které vidíme teď.

Jak to funguje doopravdy?

No, úplně stejně. Začnete s nějakou hypotézou a přidáváte a přidáváte grafy. V nich pak vybíráte segmenty, které vás nejvíc zajímají. Dokud nedojdete ke kořenu tohoto problému.

Naposled jsme takhle koukali na to jak se nám daří ve špičče a zda naše chování můžeme vylepšit. Nejdříve si vyberete opět datum, čas, místo na mapě. Potom si přidáte určité charakteristiky řidičů. Do druhého grafu vedle si dáte poptávku. A pomocí dopočítaných statistik se koukáte co a jak se v ty dané časy děje, kdo jezdí, jakou má dostupnost a jak se třeba akceptuje.

Celkem snadno se takhle doberete odpovědi na vaši otázku, zda má smysl programovat featuru XYZ, která řeší problém ABC. A nebo obráceně: zda ten problém vůbec máte. Ale to je námět na další článek 🙂