Přeskočit na obsah

Jak jsme poprvé A/B testovali

Jednou z našich nejnovějších služeb je Private Marketplace. Ten slouží k domlouvání tzv. Private Deals v online reklamním byznysu. Pro příklad, obchodní zástupce aktualne.cz se domluví se Škodovkou a nabídne jim možnost nakupovat mobilní reklamu na stránkách deníku v kategorii Auto za cenu osmi korun za tisíc zobrazení, přičemž běžná cena na trhu je třeba deset korun. Tuto dohodu potom obchoďák zapíše do systému, a tím systémem je právě Private Marketplace. 

Důležitou částí je nástroj, který kontroluje, zda se Škodovce opravdu daří nakupovat zobrazení reklamy — jmenuje se Deal Check. Po cestě totiž existuje spousta děr, do kterých může škodovácká reklama zapadnout a koncovému uživateli se v prohlížeči nakonec zobrazí reklama na něco jiného. Například se může Škodovka snažit kupovat čtvercovou 300px × 300px reklamu v prohlížečích Chrome na iPhonech a jen těm, kteří jsou zrovna na jižní Moravě. A může se stát, že se za den najde jen minimum lidí, kteří tuhle kombinaci splňují. Deal Check má za cíl ukázat, ve kterém kroku se ztratilo nejvíce uživatelů (ztratili jsme více uživatelů filtrací na jižní Moravu, nebo na iPhony?). Výsledkem může být, že si Škodovka všimne, že největší problém je formát a kromě 300px × 300px reklamy vytvoří i 300px × 100px banner a rázem se může počet zobrazení reklamy zdesetinásobit.

Kdysi jsme provozovali ještě starý Private Marketplace, který také obsahoval Deal Check. Byla to těžko srozumitelná tabulka s hromadou čísel a s popisky, kterým skoro nikdo nerozuměl. Byl to takový ten design “od programátora pro uživatele”. Znalost tohoto nástroje se předávala z generace na generaci, jinak to ani nebylo možné. Při programování nového Private Marketplacu jsme se rozhodli, že to zkusíme nějak lépe. Naším cílem bylo vytvořit Deal Check tak, aby každý, i nepříliš zkušený člověk, byl schopen na první pohled zjistit, ve kterém kroku se ztrácí nejvíce zobrazení a zároveň mu měl nástroj napovědět, co může udělat pro to, aby tuto ztrátu vyřešil. 

Vytipovali jsme si naše uživatele, kteří budou nový Deal Check používat, připravili jsme si sadu otázek a začali jsme s nimi vést rozhovory. Po předchozích zkušenostech jsme se rozhodli vést je vždy jen ve dvou lidech, ne ve skupině. Při skupinovém rozhovoru s deseti lidmi přirozeně dochází k tomu, že se vyjadřují ti nejvíce komunikativní a zbylých devět lidí mlčí. Kombinací dotazníků, které mohli uživatelé vyplnit, a rozhovorů ve dvou lidech jsme získali poměrně přesný obrázek toho, co z nástroje potřebují zjistit. Ne, jak má vypadat, ale co z něj chtějí vyčíst. 

Navrhujeme nový Deal Check

V tuto chvíli začala fáze navrhování vzhledu nástroje. Nejtěžší bylo vymyslet, jakým způsobem vizualizovat ztráty, kterých bylo i za běžných podmínek strašně moc. Na aktualne.cz přijde dejme tomu milion lidí denně, ale reklamu na Škodovku zobrazíme jen stovce z nich a 999 900 lidí tu reklamu nezobrazíme. To není výjimečný případ, to je běžný případ. A my potřebujeme tu ztrátu 999 900 vizualizovat a zobrazit důvody, proč jsme jim tu reklamu na Škodovku nezobrazili. Chceme tak uživatelům ukázat, že 300 000 lidí jsme vyfiltrovali, protože měli jiný prohlížeč, dalších 600 000 nebylo z jižní Moravy, dalších 50 000 nemělo iPhone a tak dále. Pokud bychom to zobrazovali běžnými sloupečky s klasickou lineární stupnicí, byl by první sloupec zobrazující milion uživatelů desettisíckrát větší než poslední sloupec se stovkou výsledných zobrazení. 

Po dlouhém boji jsme nakonec přišli se dvěma návrhy. Prvním byl “dice arrow chart”. 

Na začátku jsme si vydefinovali nějaké kroky či fáze, které během pokusu o zobrazení reklamy nastávají. Těch kroků je sedm a v každém z nich se typicky odfiltruje část uživatelů. Tento “dice arrow chart” každý krok reprezentoval jako šipku vpravo. Nalevo začínáme s 87 miliony potenciálními uživateli a v každém kroku ztratíme část z nich. Červená šipka značí, že ztráta byla velká, zelená, že ztráta byla malá. Na konci vidíme, že jsme reklamu zobrazili jen 9 812 uživatelům z celkového počtu. 

Druhý návrh se jmenoval “pie chart” a využíval kolečka:

Graf opět zobrazoval fáze a postupné ubývání uživatelů. Červená část byl úbytek v daném kroku, zelená část prošla do dalšího kroku.

Vybíráme vítěze

Protože jsme se nemohli rozhodnout, která z těchto verzí by měla zvítězit, rozhodli jsme se naprogramovat obě a provést A/B testování. Myšlenka byla, že opravdu naprogramujeme obě verze plně funkční a budeme sledovat, kterou verzi uživatelé používají radši. Pro nás to byl první takový pokus, ještě nikdy jsme nezkoušeli skutečně naprogramovat dvě plně funkční verze jednoho nástroje s tím, že jednu z nich časem zahodíme. Řekli jsme si, že když stejně nevíme, která verze vyhraje, že to zkusíme jen tak narychlo naprogramovat, ať to nějak funguje a časem tu vítěznou verzi přepíšeme pořádně — ať máme co nejrychleji výsledek. 

Na vyhodnocení jsme nasadili mimojiné Hotjar. Ten umí nahrávat, jak uživatel prochází webem a jakým způsobem web používá. Měli jsme tedy k dispozici videa uživatelů a mohli jsme pozorovat, kterou verzi používají radši a jaké trable mají s kterou verzí. Po několika týdnech jsme měli vítěze. Pie chart v hlasování, které probíhalo souběžně, vyhrál drtivě 5:1 nad dice arrow chartem. Čtete správně, opravdu pět ku jedné. Ona totiž nastala docela paradoxní situace: starý Private Marketplace musel obsluhovat docela velký tým lidí, nicméně když jsme vytvářeli nový Private Marketplace, snažili jsme se spoustu úkonů zoptimalizovat a zjednodušit. Výsledkem bylo, že na obsluhu nové verze Marketplacu bylo třeba řádově méně lidí. Luddité nás před tím varovali správně, stroje berou lidem práci! 

Po cca dvou měsících jsme měli jasno o vítězi a chtěli jsme přepsat vítěznou variantu, aby splňovala všechny naše náročné standardy na hezký a čistý kód. Všechen kód jsme smazali, najeli jsme na TDD a párové programování a za tři týdny bylo hotovo. Pak jsme se probudili ze sna, zjistili jsme, že po dvou měsících už tým, který Private Marketplace vytvářel, ani neexistuje a lidé jsou přiděleni na jiné úkoly. Rychlým pohledem na kód jsme zjistili, že to není zase tak špatné a nechali jsme to ležet. Funguje to doteď, uživatelé jsou spokojení, ideální to ale není.

Jaká poučení jsme si z toho vzali?

  • V žádné fázi navrhování se nemusíme rozhodovat sami. Když jsme si nebyli jisti, co uživatelé od Deal Checku očekávají, zeptali jsme se jich. Když jsme potřebovali pomoci s návrhem vzhledu, uživatelé nám zhodnotili, co jim připadá přehledné a co už ne. A nakonec když jsme měli dvě finální verze, mezi kterými jsme se neuměli rozhodnout, naprogramovali jsme obě a nechali rozhodnout uživatele. 
  • “Teď to naprogramujeme ledabyle a pak to přepíšeme” prostě nefunguje, i když jsme se desetkrát ujišťovali, že pak bude čas na přepis. Uncle Bob říká the only way to go fast is to go well. I když člověk programuje prototyp, o kterém ví, že ho jednou vyhodí, je nakonec rychlejší ho naprogramovat správně hned napoprvé. Jinak to zkrátka nefunguje.

Líbil se ti tento článek?

Napsat komentář

Vaše e-mailová adresa nebude zveřejněna. Vyžadované informace jsou označeny *