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.
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?
- Nejprve je třeba se shodnout na zadání a měřených metrikách
- Zvolíme vhodné možnosti řešení: A, B, C, atp.
- Zvolíme segmenty zákazníků, na kterých to budeme testovat
- Zvážíme riziko a zvolíme procenta, která bude daný segment pro danou variantu mít
- Pustíme to konečně na zákazníky
- Měříme metriky až do chvíle statistické signifikance
- Vyhodnocujeme -> analyzujeme -> aplikujeme nové nastavení -> vracíme se do bodu #4
- 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.
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 stack. Další 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?
- 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.
- 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.
- 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.
- Propojení firmy, když v jednom teamu sedí datový člověk, business owner i backend engineer. Přesah, buy-in a celkově zainteresovanost.
- Oprášení matematiky a statistiky ze školních lavic :-)
