Produktová analytika: čo používatelia v aplikácii naozaj robia

01Otázka má predchádzať udalosti aj nákupu nástroja

Majiteľ produktu potrebuje vedieť, či ľudia získajú hodnotu, vracajú sa a zaplatia za službu v dohodnutom modeli. Počet kliknutí na tlačidlo nemusí odpovedať ani na jednu otázku. V rezervačnej aplikácii môže desať pokusov o potvrdenie znamenať jednu dokončenú rezerváciu alebo desať chýb.

Dohodnite jednu hlavnú činnosť pre aktuálnu fázu. Pri novom produkte môže ísť o úspešné vytvorenie prvého projektu. Pri zavedenom nástroji o opakované dokončenie pracovnej úlohy. Metrika má jasnú jednotku, obdobie a podmienky. „Aktívny používateľ“ bez definície je názov stĺpca, nie spoločné zadanie.

Spíšte aj rozhodnutie, ktoré po meraní urobíte. Ak odpad vzniká pri výbere pobočky, zjednodušíte ponuku alebo preveríte dostupnosť. Ak pri potvrdení, skontrolujete formulár a serverové chyby. Meranie desiatok nepoužívaných detailov nevytvára lepší produkt, keď sa výsledok nedostane k človeku schopnému konať.

Prvé zadanie môže byť malé: jeden proces, niekoľko dôležitých udalostí a jeden pravidelný prehľad. Takto sa ľahšie odhalí chybné meranie aj nejasný slovník. Ďalšie udalosti pridávajte, keď vznikne konkrétna otázka, ktorú existujúce dáta nedokážu zodpovedať.

02Plán merania určuje význam a vlastníka každej udalosti

Amplitude opisuje plán merania ako definíciu udalostí, ich vlastností, účelu a zdroja. Rovnaký princíp je užitočný bez ohľadu na vybraný nástroj. Vývojár a analytik potom nepracujú s odlišnými predstavami o tom, čo znamená „objednávka dokončená“.

U každej udalosti zaznamenajte vlastníka, povolené typy hodnôt, miesto odoslania a podmienky opakovania. Zdrojový názov môže zostať technický, obchodná definícia musí byť zrozumiteľná. Premenovanie tlačidla nemá automaticky vytvoriť novú historicky neporovnateľnú metriku.

Vyhýbajte sa vlastnostiam s nekontrolovaným voľným textom. Text poznámky zákazníka môže obsahovať citlivé údaje, pravopisné varianty aj stovky jedinečných hodnôt, ktoré reportu nepomôžu. Pre rozhodovanie o chybách je často užitočnejšia overená kategória než celý obsah správy.

Plán má zahŕňať aj udalosti, ktoré sa nemajú zbierať. Spíšte zakázané hodnoty a umiestnenia, kde sa analytika neuplatní. Takáto dohoda je praktickejšia než všeobecná požiadavka „merať všetko“, ktorá neskôr komplikuje odstránenie nepotrebných dát.

03Kliknutie a dokončenie procesu merajte oddelene

Klient vie, že používateľ stlačil tlačidlo. Server vie, či rezervácia naozaj vznikla. Obe udalosti môžu mať zmysel, ale majú odlišný význam. Ak sa konverzia odosiela už pri kliknutí, môže report rásť počas výpadku, keď ľudia opakovane skúšajú tú istú neúspešnú činnosť.

Pri úspešnej obchodnej činnosti zvoľte dôveryhodný bod potvrdenia. Opakované odoslanie po prerušení siete nesmie vytvoriť ďalšiu úspešnú objednávku v analytike. Dohodnite identifikátor udalosti alebo iný mechanizmus odstránenia duplicít podľa použitej platformy. Surový počet záznamov nemá nahrádzať počet reálnych výsledkov.

Aplikácia môže udalosti odoslať neskôr, napríklad po návrate pripojenia. Preto rozlišujte čas činnosti a čas prijatia dát. Pri denných reportoch uveďte časové pásmo a toleranciu oneskorenia. Slovenské obchodné obdobie nemá bez vysvetlenia meniť hranice podľa nastavenia analytického účtu v inom regióne.

Pred nasadením prejdite jeden úspešný aj neúspešný proces a porovnajte záznamy s databázou. Overte zrušenie, dvojité kliknutie, návrat späť a zmenu účtu. Zmeny merania patria do odovzdania verzie rovnako ako zmeny funkcie. Inak bude tím vysvetľovať technickú chybu ako náhle zlepšenie správania.

04Lievik ukáže miesto straty, kohorta ďalší návrat

Konverzný lievik sleduje postup cez definované činnosti. Dokumentácia Amplitude rozlišuje poradie udalostí a výber segmentu. Nastavenie ovplyvňuje, ktorých používateľov výsledok zaradí medzi tých, ktorí proces dokončili. Preto si význam konfigurácie nechajte vysvetliť pri každom dôležitom reporte.

Pre rezerváciu môžete sledovať výber služby, termínu, odoslanie a potvrdenie. Pri strate medzi dvoma krokmi sa pozrite na rozdiely podľa verzie aplikácie, platformy alebo typu zákazníka. Celkový priemer môže prekryť chybu, ktorá sa týka iba jednej konkrétnej skupiny.

Kohorta združuje ľudí s rovnakým východiskovým obdobím alebo podmienkou. PostHog pri retencii pracuje so štartovou a návratovou udalosťou aj intervalom. Musíte preto povedať, či návrat znamená otvorenie aplikácie alebo opakované vykonanie hodnotnej činnosti.

Neúplné obdobie neporovnávajte s uzavretým. Skupina registrovaná včera ešte nemohla prejaviť mesačnú retenciu. Rovnako odlíšte návrat presne v danom intervale od návratu v tomto alebo neskoršom intervale. Obe metriky môžu byť užitočné, ale zodpovedajú odlišné otázky.

05Identita musí zodpovedať tomu, komu služba prináša hodnotu

Zariadenie, osoba a firemný účet môžu vytvárať odlišný obraz používania. Pri firemnom produkte používa jeden zákazník viac zamestnancov. Jeden človek zase môže pracovať na počítači aj telefóne. Pred výpočtom retencie rozhodnite, či chcete sledovať konkrétnu osobu alebo pokračovanie celého zákazníckeho účtu.

Anonymné používanie pred prihlásením potrebuje jasný postup spojenia s účtom, ak takú funkciu používate. Po odhlásení sa nemá aktivita ďalšieho človeka pripísať predchádzajúcemu používateľovi. Skontrolujte zdieľaný počítač, prepnutie organizácie a odstránenie účtu. Tieto situácie menia report aj spracúvanie údajov.

Google pri User-ID vyžaduje vhodné vlastné identifikátory a upozorňuje, že nesmú obsahovať údaje, z ktorých tretia strana určí identitu. Rovnaký identifikátor pre viacerých ľudí skreslí report. E-mail neposielajte ako jednoduchú náhradu za náhodný interný identifikátor.

Pseudonymný identifikátor však nie je automaticky anonymný údaj. Firma môže vedieť, ku komu patrí. Určte účel, prístup, uchovávanie a postup odstránenia dát. Informácia, ktorá je nevyhnutná pre fakturáciu, nemusí byť nevyhnutná v samostatnom analytickom nástroji.

06Čísla vysvetlite rozhovorom a potom overte zmenu

Analytika ukáže, že určitá skupina nedokončuje formulár. Sama nepovie, či ju odradila cena, nezrozumiteľné pole alebo chýbajúca pobočka. Vyberte ľudí z relevantnej skupiny a nechajte ich vykonať úlohu. Ak používate záznamy relácií, osobitne nastavte rozsah, maskovanie a pravidlá prístupu.

Zistenie, že používatelia jednej funkcie častejšie zostávajú, nepreukazuje, že funkcia retenciu spôsobila. Mohli ju používať už motivovanejší zákazníci. Preto si pripravte hypotézu a spôsob overenia, napríklad riadenú skúšku zmeny alebo porovnanie s jasne opísanými obmedzeniami.

Zmena môže zlepšiť jeden krok a zhoršiť ďalší. Jednoduchšie vytvorenie projektu prinesie viac projektov, no nemusí viesť k ich dokončeniu. Sledujte aj následnú hodnotu, chybovosť a požiadavky podpory. Metrika úspechu a kontrolné metriky majú vzniknúť pred nasadením, aby sa výsledok nevyberal až podľa najkrajšieho grafu.

Modelová chyba pri interpretácii: tím premení povinnú registráciu na voliteľnú a počet prihlásených účtov klesne. Ak sleduje iba účty, môže úpravu označiť za neúspech. Zákazníci však možno úspešne dokončujú rezervácie ako hostia. Preto porovnajte výsledky celého procesu, nie iba jeden technický krok. Pre novú verziu zapíšte, čo sa zmenilo v dostupných identifikátoroch a ktoré historické metriky zostávajú porovnateľné. Rozhodnutie musí zohľadniť aj kvalitu následnej komunikácie a možnosť zákazníka rezerváciu spravovať. Ak hosťovská objednávka funguje, ale zákazník nedostane potvrdenie, samotný rast dokončení nestačí. Takýto príklad ukazuje, prečo má obchodná definícia prežiť zmenu rozhrania a prečo je potrebné kontrolovať viac než jeden ukazovateľ.

Pri malom počte zákazníkov je často užitočnejšie spojiť dáta s detailnou skúškou použiteľnosti. Nemusíte predstierať presný štatistický záver tam, kde nie je dostatok pozorovaní. Zapíšte neistotu aj predpoklad a zvoľte zmenu, ktorej dopad dokážete priebežne kontrolovať.

07Z merania spravte pravidelnú zodpovednosť

Report má mať vlastníka, ktorý pravidelne preverí kvalitu dát a navrhne rozhodnutie. Na jednej porade vyberte problém, dohodnite zmenu a termín vyhodnotenia. O mesiac sledujte, čo sa stalo. Dashboard bez tohto cyklu sa ľahko stane obrazovkou, ktorú všetci otvoria a nikto podľa nej nekoná.

1. Vyberte otázku a hodnotnú činnosť.
2. Dohodnite slovník, identitu a ochranu údajov.
3. Overte udalosti proti skutočným procesom.
4. Vyhodnoťte problém, upravte produkt a znovu skontrolujte výsledok.

Pri zmene aplikácie sledujte náhle zmiznutie udalosti alebo rast nepovolených hodnôt. Opravte aj historickú interpretáciu, ak zistíte chybu. Tím má vedieť, odkedy sú čísla porovnateľné a ktoré obdobie je neisté. Nenápadná poznámka v reportoch môže zabrániť drahému rozhodnutiu o funkcii, ktorá iba zmenila názov udalosti.

Na odovzdanie žiadajte plán merania, zoznam reportov, prístupové roly a postup kontroly po vydaní. Vlastníctvo analytického účtu má zostať firme. Ak sa dodávateľ zmení, nový tím potrebuje rozumieť definíciám bez toho, aby ich odhadoval z historických grafov. Pri onboardingu používateľov sa táto kontinuita prejaví veľmi rýchlo.

08Časté otázky o produktovej analytike