Událostní analýza: přístupy a struktura událostí

# Událostní analýza: struktura, přístupy a parametry sledování

Událostní analýza digitálních produktů se opírá o sledování klíčových interakcí uživatelů. Každá událost zaznamenává název, timestamp, user_id a základní parametry: zemi, platformu, zařízení, OS. Další vlastnosti události upřesňují kontext akce, zatímco user properties přidávají demografii a identifikátory (Amplitude ID, Device ID).

Struktura událostí souvisí s cíli produktu. Bez správného označování nelze vypočítat metriky jako DAU, MAU, retention rate nebo revenue breakdowns. Analytici zdědí události po předchůdcích, ale při spuštění nového projektu je navrhují od nuly.

Volba strategie sledování

Určuje objem dat a složitost analýzy. Dva základní přístupy:

Cílový přístup se zaměřuje na události pro konkrétní cíle podniku. Výhody: rychlá implementace, nízké náklady na úložiště, jednoduchá validace. Nevýhody: omezená hloubka, ztráta detailů chování.

Extenzivní přístup zachycuje všechny interakce. Výhody: maximální flexibilita, insights z neočekávaných dat. Nevýhody: nafukování databáze, složitost filtrování, hromadění zastaralých událostí.

| Kategorie událostí | Cílový | Extenzivní |

|-------------------|---------|--------------|

| Registrace | ✅ | ✅ |

| Zobrazení obrazovek | ✅ | ✅ |

| Tlačítka akcí | ✅ | ✅ |

| Platba | ✅ | ✅ |

| Technické chyby | ❌ | ✅ |

| Reklamní banery | ✅ | ✅ |

| Vyskakovací upozornění | ❌ | ✅ |

| Prohlížení bloků v feedu | ❌ | ✅ |

| Uložení/sdílení | ⚠️ | ✅ |

V reálných projektech se přístupy kombinují. Příklad: testování dočasných landing pages se zaměřením na konverzi formuláře. Sledovat pouze klíčové události (zobrazení, kliknutí, submit), ignorovat meziinterakce pro úsporu zdrojů.

Komponenty události

Událost není jen název, ale i parametry. Základní sada:

• Název události: objekt + akce + kategorie (např. main_screen_shown).
• Timestamp: přesný čas zaznamenání.
• User ID: unikátní identifikátor.
• User properties: platforma, OS, jazyk, země, region, Device ID.
• Event properties: kontext (type=landing_1, screen_name=home).

Trackery jako Amplitude, GA, Segment přidávají až 2000 vlastností automaticky, ale praxe ukazuje: 50–300 stačí. Pro malý projekt — 100–150 parametrů (user + event). Překročení limitů (např. v free Amplitude) vede ke ztrátě dat.

Dokumentujte vlastnosti v Google Sheets: popis, typ, příklady hodnot. To usnadňuje předání dev týmu a analýzu.

Nomenklatura a standardy

Jednotná struktura názvů urychluje hledání v databázi. Formát: [object]_[action]_[category] v snake_case.

• Objekty: screen, button, modal, banner.
• Akce: tap, view, swipe, create, delete.
• Kategorie: home, checkout, promo_landing.

Příklady notací:

• snake_case: page_view.
• camelCase: pageView.
• all lowercase: pageview.

Vyhněte se variantám jako button_tap / buttons_tap. Standard se volí jednou pro projekt.

Srovnání s událostmi trackerů:

| Custom | Amplitude |

|--------|-----------|

| main_screen_shown, type=landing_1 | [Amplitude] Page Viewed, Page URL=https://landing_1.comp.org/ |

Vlastní jsou kratší a pohodlnější v kódu. Aktualizujte dokumentaci při aktualizacích.

Vytváření seznamu událostí

Orientujte se na funnel a unit economics. Metody:

• Podle hlavního funelu: registrace → onboarding → purchase.
• Podle obrazovek (z Figma): sekvenční rozbor UI.
• Kompletní dataset: pro A/B testy nebo discovery fázi, s následným ořezáním.

Prohlédněte prototypy, otestujte user flow. Předejte dev: události + parametry. Po implementaci kontrolujte surová data v databázi.

Co je důležité

• Události musí přímo podporovat cíle produktu a metriky.
• Vyvažte objem dat: cílový přístup pro stabilní funkce, extenzivní — pro experimenty.
• Standardizujte naming convention pro škálovatelnost.
• Dokumentujte všechny vlastnosti, omezte parametry na 100–300.
• Pravidelně čistěte databázi od zastaralých událostí.

Událostní analýza vyžaduje porozumění produktu. Správný design událostí minimalizuje šum a maximalizuje actionable insights.

— Editorial Team