Produktová analytika: zjistěte, kde lidé v aplikaci ztrácejí cestu
Počet přihlášení neříká, zda uživatelé dokážou udělat práci, kvůli které aplikaci mají. Produktová analytika propojuje důležité činnosti s jejich výsledkem. Začněte jednou rozhodovací otázkou, popište události a ověřte, že znamenají totéž v aplikaci i v přehledu. Teprve potom hledejte místa, kde změna rozhraní nebo procesu může pomoci.
Vedení zákaznického portálu vidí návštěvnost a počet účtů. Podpora ale stále vyřizuje dotazy, které měl portál odstranit. Je potřeba zjistit, zda lidé potřebný dokument nenajdou, neumějí jej stáhnout, nebo si ani neuvědomí, že je k dispozici. Každá možnost vede k jinému zásahu. Jeden souhrnný graf návštěvnosti je nerozliší.
Měření není soutěž o největší počet událostí. Potřebujete spolehlivé odpovědi, které se dají spojit s konkrétním rozhodnutím. Analytika dobře doplňuje rozhovory a pozorování při návrhu UX aplikace. Řekne, kde se problém objevuje a koho zasahuje; samotná čísla obvykle nevysvětlí všechny jeho příčiny.
01Otázka pro rozhodnutí předchází výběru nástroje
Sepište, co potřebujete rozhodnout v nejbližší době. Například zda zjednodušit výběr dokumentu, přesunout důležitou funkci na úvodní obrazovku nebo změnit první nastavení účtu. U každé otázky určete vlastníka a navazující akci. Pokud by odpověď nic nezměnila, není nutné kvůli ní sbírat další detailní data.
Definujte hodnotnou činnost z pohledu uživatele. V pracovním produktu může jít o úspěšně odeslanou nabídku, nikoli každé stisknutí tlačítka. U objednávkové aplikace potřebujete odlišit rozpracování objednávky, její přijetí a případné pozdější zrušení. U dokumentů zase rozlišujte nalezení, otevření a skutečné dokončení potřebného kroku.
Zvolte přiměřené období. Denní aktivita je vhodná pro denní práci, ale nevypovídá stejně o čtvrtletní objednávce nebo sezónním nástroji. Porovnávejte lidi, kteří měli příležitost funkci použít. Firma s přístupem jen pro správce nemá stejnou základnu jako produkt dostupný všem zaměstnancům.
Před vývojem MVP můžete ověřovat zájem rozhovory a prototypem. Po spuštění už potřebujete poznat, zda se plánovaná hodnota skutečně odehrává. Analytiku proto plánujte společně s první funkční verzí a ne až při otázce, proč se nenaplnila očekávání.
02Událost musí mít jeden srozumitelný význam
Událost označuje konkrétní děj. Název „document_opened“ má znamenat otevření dokumentu, nikoli současně kliknutí na položku, pokus o stažení a načtení prázdného náhledu. K události připojte jen potřebné parametry, například typ dokumentu, verzi aplikace a způsob vstupu. Volný text od uživatele mezi ně obvykle nepatří.
Google Analytics rozlišuje automatické, rozšířené, doporučené a vlastní události. Než vytvoříte vlastní název, zkontrolujte, zda existující doporučená událost odpovídá vašemu významu. Nástroj vám ale nepomůže, když do stejného názvu schováte rozdílné činnosti nebo jej posíláte v nesprávný okamžik.
V měřicím plánu zapište spouštěč, očekávané parametry, zdroj pravdy a odpovědnost. „Objednávka dokončena“ se má opírat o skutečné přijetí objednávky; klientské kliknutí je pouze záměr. Vývojář a analytik musí sdílet stejnou definici. Jinak budou oba správně implementovat dvě odlišné věci.
| Událost v modelovém portálu | Kdy vznikne | Co pomáhá rozhodnout |
|---|---|---|
| search_submitted | Uživatel skutečně odešle hledání. | Zda lidé hledání potřebují a používají. |
| search_empty | Hledání vrátí prázdný výsledek. | Které skupiny dokumentů nejde najít. |
| document_opened | Dokument se úspěšně zobrazí. | Zda je nalezený obsah dostupný. |
| download_completed | Potvrzené dokončení odpovídajícího stahování. | Zda cesta končí potřebným výsledkem. |
| download_failed | Systém rozpozná chybu stahování. | Zda jde o technickou překážku. |
03Měřte cestu k výsledku, ne jen seznam kliknutí
Funnel je sled kroků s jasnými pravidly. Například otevření sekce, výběr období, otevření dokumentu a dokončení stažení. Určete, zda kroky musí jít v daném pořadí, v jedné relaci nebo v delším období. Člověk, který pokračuje další den, nemá automaticky vypadat jako neúspěšný uživatel.
Rozlišujte počet událostí a počet lidí. Jeden zákazník může hledat opakovaně; deset hledání neznamená deset zákazníků. Sledujte také počet příležitostí. Stahování dokumentu může dávat smysl jen lidem, kteří už mají dokument vystavený. Jmenovatel vybraný ze všech účtů by zhoršení nadhodnotil.
Pád mezi kroky může mít více významů. Někdo našel informaci už v náhledu, někdo nemá oprávnění a jinému chybí potřebný dokument. Doplňte relevantní stav a kvalitativní kontrolu. Nenechte automatický graf určit řešení dřív, než pochopíte, proč se lidé zastavili.
Vedle dokončení sledujte opakované pokusy, čas mezi významnými kroky a potřebu podpory. Dlouhý čas nemusí být problém při pečlivém rozhodování, zatímco velmi krátký čas nemusí znamenat hladký průchod. Vyberte metriky odpovídající úkolu a vždy ověřte extrémní hodnoty i způsob jejich výpočtu.
04Kohorty a retence ukážou rozdíly v čase
Kohorta sdružuje lidi se společným začátkem nebo událostí, například s prvním dokončeným úkolem v určitém týdnu. Porovnávejte podobně staré skupiny. Nováčci z tohoto týdne ještě neměli možnost ukázat měsíční retenci. Jejich srovnání se starými zákazníky by bylo zavádějící.
Aktivaci definujte jako dosažení první rozpoznatelné hodnoty. Registrace může být nutný předpoklad, ale nemusí jí být. U interní aplikace není další přihlášení důkazem spokojenosti, pokud ji zaměstnanci musejí používat. Zvažte dokončení úkolu, spolehlivost a potřebu pomoci společně.
Retenci měřte podle rytmu produktu a konzistentní definice. Návrat přesně sedmý den je jiné měřítko než návrat kdykoli v následujícím týdnu. V reportu napište, které používáte. Segmentace podle verze aplikace, role nebo délky používání může odhalit problém, který celkový průměr schová.
Nevytvářejte stovky malých segmentů jen proto, že to nástroj umí. Malé skupiny přinášejí nestabilní výsledky a mohou odhalovat konkrétní osoby. Vyberte několik významných rozdělení. Když se rozdíl objeví, ověřte jeho vysvětlení a zda jej nevytváří odlišný způsob sběru nebo souběžná změna nabídky.
05Kvalitu měření ověřujte stejně jako funkce produktu
Na testovacím účtu projděte cestu ručně a porovnejte očekávané události se skutečností. Ověřte úspěch, chybu, opakovaný pokus, obnovení stránky, ztrátu spojení a více zařízení. Dokumentace GA4 popisuje kontrolu událostí a parametrů v Realtime a DebugView; dostupné nástroje využijte před ostrým vyhodnocením.
Zkontrolujte duplicity. Opětovné odeslání při obnovení spojení nebo současný sběr na klientu a serveru mohou započítat jeden výsledek dvakrát. U transakcí navrhněte identifikátor a pravidla odstranění duplicit. U běžných interakcí ověřte, že stejná událost nevzniká automaticky vícekrát při jediném úkonu.
Porovnejte analytické výsledky s provozními záznamy, pokud to jejich účel a oprávnění dovolují. Rozdíl nemusí být chyba: analytika nemusí obsahovat lidi bez odpovídajícího souhlasu, některé zařízení měření omezí a část událostí nedorazí. Důležité je rozdíl znát a neskrývat neúplnou základnu.
Po změně produktu aktualizujte měřicí plán. Přejmenovaná funkce, nový přihlašovací tok nebo změna definice úspěchu mohou přerušit časovou řadu. Zaznamenejte změnu, zachovejte významné verze a ověřte sběr po nasazení. Věta „analytika byla jednou nastavena“ není průběžná kontrola kvality.
06Ochranu soukromí řešte už při návrhu událostí
ÚOOÚ shrnuje zásady omezení účelu, minimalizace a nezbytné doby uložení. U každé skupiny dat si proto určete účel, právní důvod, potřebný detail, přístup a dobu uchování. To platí i při použití identifikátoru místo jména. Nahrazení jména kódem samo o sobě nedokládá anonymitu.
Zásady Google Analytics zakazují předávat údaje umožňující zjištění totožnosti. Dávejte pozor také na URL, názvy stránek, vyhledávací dotazy a parametry kampaně. E-mail v adrese stránky může uniknout i bez samostatně navržené události. Omezujte riziko už před odesláním, ne až po zobrazení reportu.
Nahrávání obrazovek a relací posuzujte zvlášť. Volná pole, dokumenty a přihlášené prostředí mohou obsahovat soukromé nebo obchodně citlivé údaje. Před spuštěním ověřte maskování a skutečně zaznamenaný výsledek. Pro mnoho rozhodnutí postačí několik agregovaných událostí bez záznamu celého chování.
Na webu prověřte také pravidla ukládání a přístupu k informacím v zařízení. Cookie lišta a řízení měření jsou součást implementace, nikoli dekorace. Serverové odesílání samo neřeší právní titul a není důvodem ignorovat uživatelskou volbu. Odmítání měření přiznejte jako omezení reportu.
07Z jednoho zjištění udělejte ověřitelnou změnu
Modelový portál ukáže časté prázdné výsledky při hledání dokumentů. Nevyvozujte okamžitě, že musíte vyměnit vyhledávač. Zkontrolujte, zda dokumenty existují, mají správná oprávnění a lidé používají očekávané názvy. Projděte několik situací s uživateli. Může stačit nabídka období nebo srozumitelnější pojmenování.
Vyberte jednu změnu a předem určete očekávaný dopad. Sledujte nejen méně prázdných výsledků, ale i dokončení potřebné činnosti. Když se lidé hledání pouze přestanou snažit používat, první metrika se zlepší bez skutečného přínosu. Přidejte kontrolu technických chyb a podpory.
U vhodného produktu porovnejte náhodně rozdělené varianty. Když experiment není možný, vyhodnocujte změnu s přiznanými omezeními předchozího období, sezóny a skladby zákazníků. Časová souvislost neprokazuje sama příčinu. Potřebujete rozhodnutí podložené dostupnou evidencí, nikoli přehnaně jistý příběh.
Měsíční přehled omezte na otázku, změnu, výsledek a další krok. Ke každému ukazateli připojte definici a známé omezení. Rozhodovací porada má skončit odpovědností a termínem, ne objednávkou nových grafů. Když data odpověď nedávají, napište, co musíte ověřit jiným způsobem.
08Nejčastější otázky k produktové analytice
Stačí nám počet aktivních uživatelů?
Je to užitečný přehled rozsahu používání, ale neukáže úspěšnost konkrétní práce. Doplňte významné dokončené činnosti, jejich cestu a překážky. Definujte, co u vás znamená aktivita.
Potřebujeme měřit každé kliknutí?
Obvykle začněte menším počtem událostí navázaných na rozhodnutí. Plošný sběr přináší více dat i povinností, bez záruky použitelného vysvětlení. Rozšiřujte jej podle konkrétní potřeby.
Je registrace aktivace?
Pouze pokud registrace sama přináší zamýšlenou hodnotu. Většinou je vhodné sledovat první dokončený úkol nebo jiný prospěšný výsledek. Definici ověřte s týmem a uživateli.
Proč se analytika liší od databáze objednávek?
Může používat jiný okamžik dokončení, obsahovat duplicity nebo měřit jen část uživatelů. Porovnejte definice, základnu a přenos dat. Rozdíl neodstraňujte pouhým ručním přepsáním čísla.
Dokazuje lepší funnel úspěch nové funkce?
Sám o sobě ne. Výsledek může ovlivnit složení lidí, jiná změna či způsob měření. Ověřte celý úkol a srovnávací podmínky. U experimentu stanovte cíl a omezení předem.
Je interní identifikátor anonymní údaj?
Ne nutně. Posuzujte možnost přiřazení ke konkrétnímu člověku a celé prostředí. Pseudonymizace snižuje některá rizika, ale automaticky neodstraňuje povinnosti při zpracování osobních údajů.
Co má obsahovat první zadání analytiky?
Jednu rozhodovací otázku, popis hodnotné činnosti, události s významem, potřebné parametry, pravidla ochrany dat a plán kontroly. Přidejte vlastníka rozhodnutí a datum vyhodnocení.