Úvodní V zralém produktu je často obtížné dosáhnout statisticky významného dopadu na klíčové obchodní metriky, jako jsou příjmy na uživatele nebo počet objednávek. Většina změn je zaměřena na bodové zlepšení v tunelu nebo jednotlivých fázích uživatelské cesty, a dopad těchto změn na obchodní metriky je obvykle ztracen v hluku. Nicméně čas od času si všimneme, že metriky funnelů se nepohybují v souladu s dynamikou ukazatelů nejvyšší úrovně. Navíc v některých testech se konverze ve stádiích, které předcházejí provedeným změnám, mohou měnit statisticky významným způsobem. Jako příklad uvažujte o službě, kde uživatel vytvoří objednávku, obdrží nabídky od různých dodavatelů, vybere vhodnou službu a čeká na dokončení úkolu. Předpokládejme, že jsme vyvinuli novou funkci, která zdůrazňuje nejlepší nabídku a očekává se, že zvýší podíl objednávek, kde dojde k shodě mezi zákazníkem a výkonným umělcem. Během experimentu můžeme pozorovat, že: 
 
 
 
 Podíl úspěšných objednávek klesá. Celkový počet objednávek a dokončených objednávek se zvyšuje. Podíl objednávek, které obdržely alespoň jednu nabídku, klesá. Takový vzorec může nastat, pokud má uživatel možnost vrátit se do předchozích fází a například znovu zveřejnit objednávku. Podobné vzorce jsme objevili v našich vlastních experimentech. V aplikaci inDrive mohou cestující navrhnout svou vlastní cenu, poté obdrží nabídky od řidičů a vyberou nejvhodnější.Mnoho uživatelů aktivně využívá funkce vyjednávání a snaží se získat lepší cenu, může změnit podmínky objednávky a vytvořit ji znovu. Náš tým pro vyhovění cestujícím je zodpovědný za cestu uživatele od okamžiku vytvoření objednávky až po dokončení cesty.V tomto článku vysvětlíme, jak jsme tyto vzorce chování zkoumali a na jejich základě zavedli nové metriky, které pomohly zlepšit interpretovatelnost výsledků testů. Tento článek bude užitečný pro produktové analytiky a produktové manažery, kteří pracují s produkty, které mají složitou, nelineární uživatelskou cestu, kde metrická interpretace vyžaduje zohlednění vzorců chování a opakovaných uživatelských akcí. Jak se chovají klíčové metriky a metriky tunelu? V našem produktu je tunel přibližně následující: cestující vytvoří objednávku, obdrží nabídky od řidičů, vybere vhodnou, čeká na příchod řidiče a pak začíná a dokončuje cestu. Představte si, že spustíme malou změnu v rozhraní uživatelského rozhraní: zobrazíme uživateli řádek pokroku při hledání řidiče, abychom snížili nejistotu. Očekáváme, že s řádkem pokroku budou uživatelé častěji čekat na nabídky řidičů a v důsledku toho podniknout více cest. Je logické zvolit konverzi od vytvoření objednávky k obdržení nabídky jako cílovou metriku pro takový test. Na základě výsledků testu vidíme: 
 
 
 
 
 Počet jízd: ↑ (statisticky významný nárůst) Počet objednávek: ↑ ↑ (statisticky významný nárůst) CR od objednávky k nabídce: ↓↓ (statisticky významný pokles) Done Rate: ↓↓ (statisticky významný pokles) Vidíme mírný nárůst počtu jízd, statisticky významný nárůst počtu objednávek, ale zároveň pokles konverze od vytvoření objednávky k obdržení nabídky a pokles podílu úspěšných jízd. Uživatel interaguje s funkcí až po vytvoření objednávky, takže na první pohled se zdá, že nemůžeme ovlivnit počet vytvořených objednávek.Pokud se testovací skupina stalo, že zahrnuje uživatele, kteří mají tendenci vytvářet objednávky častěji, zvýšení počtu objednávek by mohlo zkreslit ukazatele funnelu a vysvětlit pozitivní dynamiku v jízdách. Nicméně, hlubší analýza ukázala, že se nejedná o problém randomizace.Po pokroku bar se objevil, někteří uživatelé, kteří měli tendenci dlouho čekat na nabídky řidičů začali zrušit objednávku dříve a udělat další pokus o výlet. V důsledku toho se nejvíce zvýšil počet opětovných objednávek (statisticky významný růst). Jak reordery ovlivňují metriky klíčů a tunelů? Po vytvoření objednávky může uživatel upustit v různých fázích: pokud neobdržel nabídky od řidičů, pokud nabídková cena nebyla vhodná, nebo později, pokud řidič přijel příliš dlouho. Namísto očekávaného lineárního uživatelského toku pozorujeme opakující se cykly – uživatelé se snaží projít stejným scénářem několikrát. Při analýze účinnosti opakovaných pokusů jsme si všimli, že jejich míra úspěchu je často výrazně nižší.Pokud uživatelé začnou častěji přepisovat, ovlivňuje to všechny fáze funnelu – včetně těch, které předcházejí skutečné změně. Kolaps řidičů Naším cílem je pochopit, zda záměry uživatelů (ne jednotlivé pokusy) začaly končit v cestách častěji. Po diskusích s týmy jsme dospěli k závěru, že dvě objednávky by měly mít následující vlastnosti, aby byly považovány za jeden záměr vzít výlet: 
 
 
 
 Pick-up a drop-off body obou objednávek by se neměly výrazně lišit. Čas vytvoření objednávky by měl být blízko (objednávky umístěné v krátkém intervalu). Předchozí objednávka nesmí být dokončena cestou. Zbývajícím úkolem bylo definovat prahové hodnoty – to, co by mělo být považováno za „blízko v čase“ a „malou změnu trasy.“ Zpočátku byly tyto prahy definovány na základě obchodních potřeb, takže první věc, kterou jsme se rozhodli udělat, bylo znovu zkontrolovat, jak dobře tyto hodnoty odpovídají skutečnému chování uživatelů. Našli jsme tohle: 
 
 
 
 
 V případě opětovného objednání uživatelé zřídka mění cílový bod (bod B). Bod vyzvednutí (bod A) se mění častěji, ale ve většině případů zanedbatelně - asi o 50 metrů od původní polohy. Většina objednávek probíhá během prvních 10–20 minut. Poté jsme fixovali body A a B v rozmezí 500 metrů a pokoušeli jsme se zjistit, jaký podíl reorderů se provádí nejpozději X minut. 
 
 Původní škrty nám vyhovovaly: pokrývají více než 90% opětovných objednávek a další zvýšení prahových hodnot téměř neovlivňuje podíl pokrytí. V případech, kdy uživatel vytvoří tři nebo více příkazů v řadě, kolaps se provádí postupně: nejprve jsou první a druhé příkazy kontrolovány a sloučeny, pak druhé a třetí a tak dále - pokud jsou splněny podmínky blízkosti času a místa. Alternativy Jako alternativní přístup jsme zvážili použití identifikátoru mobilní relace pro seskupení objednávek v rámci jediného záměru. Tato možnost se však ukázala jako méně spolehlivá ze dvou důvodů: 
 
 
 Session může být přerušena nebo „přilepená“, například když uživatel zadá objednávku, poté se vydá na cestu a brzy vytvoří a dokončí novou. Mobilní analytická data jsou méně přesná než backendová data: časy událostí a jejich objednávka mohou být zaznamenány se zpožděním nebo ztraceny. V důsledku toho jsme se rozhodli nepoužívat identifikátor relace jako základ pro definici zájmu o cestu. Nové metriky V důsledku toho jsme vytvořili novou entitu a definovali pravidlo pro vytvoření jedinečného identifikátoru. Na základě této entity jsme vytvořili několik odvozených metrik: 
 
 
 Agregovaný funnel – umožňuje vyhodnotit konverze bez zkreslení souvisejících s reordery a umožňuje interpretovat výsledky testů. Funnely prvního, druhého a následných pokusů – pomáhá nám pochopit, které akce stimulují uživatele k opakovanému pokusu a zvyšují pravděpodobnost jeho úspěchu. Nyní se vraťme k testu, který jsme diskutovali dříve, a porovnejme získané hodnoty v různých přístupech. 
 
 
 
 
 
 
 
 
 
 
 
 Metric 
 Classic Funnel 
 Aggregated Funnel 
 Interpretation 
 
 
 
 
 
 Rides 
 ↑ (not statistically significant growth) 
 Same counting 
 No change 
 
 
 
 
 
 Orders 
 ↑↑ (statistically significant growth) 
 ~0 (not statistically significant) 
 The number of intentions hardly changed — the growth in orders is explained by reorders 
 
 
 
 
 
 Done rate 
 ↓↓ (statistically significant drop) 
 ↑ (not statistically significant growth) 
 The shares of successful orders and successful intentions move in different directions 
 
 
 
 
 
 Order → bid 
 ↓↓ (statistically significant drop) 
 ↓ (not statistically significant drop) 
 Within an intention, users began to receive bids less often; the effect is close to statistical significance Jízda ↑ (není statisticky významný růst) Stejné počítání Žádná změna příkazy ↑ ↑ ↑ (statisticky významný růst) 0 (nejsou statisticky významné) Počet záměrů se sotva změnil – růst objednávek je vysvětlen reordery Úroková sazba ↓↓ (statisticky významný pokles) ↑ (není statisticky významný růst) Podíl úspěšných objednávek a úspěšných záměrů se pohybuje v různých směrech Nabídka na objednávku ↓↓ (statisticky významný pokles) ↓ (nestatisticky významný pokles) V rámci záměru začali uživatelé dostávat nabídky méně často; účinek je blízký statistickému významu Abychom vysvětlili, proč se souhrnná míra dokončení zvyšuje, zatímco konverze „order → bid“ klesá, podívali jsme se na to, jak přesně uživatelé provádějí reordery. Ukázalo se, že chování je rozděleno do dvou vzorců: 
 
 
 Někteří uživatelé začali rychleji přestat hledat, aniž by čekali na nabídku. Jiná skupina naopak začala při opětovném objednání zvyšovat cenu častěji a takové objednávky byly po přijetí zrušeny méně často. Další pozorování : 
 
 
 CR na zvýšení ceny po opětovném uspořádání: ↑ ↑ (statisticky významný růst) Shromážděná nabídka → dokončeno: ↑ ↑ (statisticky významný růst) Závěr Pozorované výsledky se mohou zdát rozporuplné, a v takových případech je důležité používat metriky, které odrážejí vzorce chování zákazníků nebo, jako v našem případě, vytvořit nové entity, které popisují realitu přesněji.

This story contains new, firsthand information uncovered by the writer.

inDrive.Tech

Tento zvuk je produkován v původním jazyce příběhu!

Měření nelineárních cest uživatelů: Přehodnocení metrik tunelů v A/B testování

About Author

KOMENTÁŘE

ZAVĚŠIT ZNAČKY

TENTO ČLÁNEK BYL PŘEDSTAVEN V

Related Stories

Coinshift Launches csUSDL, Announces Strategic Partnerships

Coinshift Launches csUSDL, Announces Strategic Partnerships

Light-Mode

Classic

Newspaper

Minty

Dark-Mode

Neon Noir

Minty

HN StartUps