Tracking plán je základom vašej analytickej implementácie. Bez neho skončíte s nekonzistentnými názvami udalostí, chýbajúcimi vlastnosťami a reportmi, ktorým nikto neverí. S dobrým tracking plánom získate čisté dáta, ktoré skutočne odpovedajú na obchodné otázky.

Tento sprievodca pokrýva všetko, čo potrebujete na vytvorenie PostHog tracking plánu, ktorý škáluje s vaším produktom.

Čo je tracking plán?

Tracking plán je dokument, ktorý definuje každú udalosť, ktorú sledujete, aké vlastnosti každá udalosť obsahuje a kedy sa má udalosť spustiť. Je to zmluva medzi vaším inžinierskym tímom (ktorý implementuje sledovanie) a vaším produktovým/analytickým tímom (ktorý používa dáta).

Dobrý tracking plán odpovedá na tri otázky pre každú udalosť:

  • Čo sa stalo? Názov udalosti (napr. user_signup)
  • Aký kontext? Vlastnosti (napr. plan_type, signup_source)
  • Kedy sa spúšťa? Podmienka spustenia (napr. po úspešnej registrácii)

Autocapture vs. vlastné udalosti

PostHog ponúka dva prístupy k sledovaniu udalostí a pochopenie, kedy použiť ktorý, je kľúčové pre dobrý tracking plán.

Autocapture

PostHog môže automaticky zachytávať udalosti bez špecifického tracking kódu. To zahŕňa zobrazenia stránok, opustenia stránok, kliknutia, zmeny vstupov a odoslania formulárov spojené s tagmi a, button, form, input, select, textarea a label.

Kedy použiť autocapture:

  • Rýchly štart s minimálnym nastavením
  • Exploračná analýza, keď si nie ste istí, čo sledovať
  • Zachytávanie širokých používateľských interakcií pre heatmapy a session recordings
  • Keď sú čiastočné dáta akceptovateľné (napr. pochopenie používateľských ciest)

Obmedzenia autocapture:

  • Nedostatok signálu: Zachytáva všetko, čím sťažuje nájdenie toho, čo je dôležité
  • Len frontend: Nemôže zachytiť server-side udalosti
  • Krehké pomenovanie: Názvy udalostí sa menia, keď sa zmení text UI (napr. „Kliknuté tlačidlo s textom 'Pridať do košíka'" sa zmení na „Kliknuté tlačidlo s textom 'Pridať'", ak aktualizujete tlačidlo)
  • Obmedzenia SPA: Zachytávanie zobrazení stránok závisí na načítaní stránky, čo vyžaduje konfiguráciu pre single-page aplikácie

Vlastné udalosti

Vlastné udalosti vám dávajú presnú kontrolu nad tým, aké dáta zachytávate a kedy. Sú nevyhnutné pre vysokohodnotové akcie.

Kedy použiť vlastné udalosti:

  • Sledovanie kritických obchodných udalostí (registrácie, nákupy, používanie funkcií)
  • Keď potrebujete špecifické vlastnosti pripojené k udalostiam
  • Server-side sledovanie pre spoľahlivosť
  • Keď názvy udalostí musia zostať stabilné napriek zmenám UI

Osvedčený postup: Použite kombináciu autocapture a vlastných udalostí. Začnite s autocapture pre široké pokrytie, potom pridajte vlastné udalosti pre vaše najdôležitejšie akcie.

Konvencie pomenovania udalostí

Konzistentnosť v pomenovaní udalostí je kľúčová. PostHog odporúča špecifické konvencie, ktoré sa líšia od niektorých iných analytických platforiem.

Framework category:object_action

PostHog odporúča štruktúrovať udalosti ako category:object_action kde:

  • Category: Kontext, kde sa udalosť vyskytla (napr. signup_flow, account_settings, checkout)
  • Object: Komponent alebo element, ktorý je zahrnutý (napr. signup_button, pricing_page)
  • Action: Sloveso popisujúce, čo sa stalo (napr. click, submit, view)

Príklady:

  • signup_flow:signup_button_click
  • checkout:payment_form_submit
  • dashboard:report_generate
  • onboarding:step_complete

Pre jednoduchšie implementácie funguje dobre aj formát [object][verb]:

  • user_signup
  • order_complete
  • project_create
  • feature_flag_evaluate

Pravidlá pomenovania

  1. Používajte len malé písmená: user_signup nie User_Signup alebo USER_SIGNUP
  2. Používajte snake_case: signup_button_click nie signupButtonClick alebo signup-button-click
  3. Používajte slovesá v prítomnom čase: submit, create, view (nie submitted, created, viewed)
  4. Buďte konkrétni: signup_button_click je lepšie ako button_click
  5. Vyhýbajte sa skratkám: user nie usr, configuration nie config
  6. Používajte vlastnosti pre kontext: Namiesto web_user_signup a ios_user_signup použite user_signup s vlastnosťou platform

Vytvorte štandardný zoznam slovies

Obmedzte váš tím na schválený zoznam slovies, aby ste predišli nekonzistencii. Bežné slovesá zahŕňajú:

  • view, click, submit, create, update, delete
  • start, complete, cancel, fail
  • open, close, expand, collapse
  • search, filter, sort, select
  • share, invite, export, download

Štandardy vlastností

Vlastnosti poskytujú kontext pre udalosti. Bez správnych štandardov vlastností budete mať nekonzistentné dátové typy a chýbajúce informácie.

Pomenovanie vlastností

Používajte snake_case pre všetky vlastnosti (rovnako ako názvy udalostí):

  • plan_type (nie planType alebo PlanType)
  • signup_source (nie signupSource)
  • is_premium (nie isPremium alebo premium)

Štandardné typy vlastností

Definujte štandardné vlastnosti, ktoré sa objavujú na viacerých udalostiach:

Vlastnosti používateľa (nastavené raz cez $set alebo $set_once):

  • email – Emailová adresa používateľa
  • name – Zobrazované meno používateľa
  • created_at – Časová značka vytvorenia účtu
  • plan – Aktuálny predplatný plán
  • company_id – Pre B2B, priradená organizácia

Poznámka: Vlastnosti nastavené s $set_once nemožno zmeniť opätovným volaním $set_once—použite to pre nemenné dáta ako pôvodný zdroj registrácie.

Vlastnosti udalosti (odosielané s každou udalosťou):

  • platform – web, ios, android
  • page_path – Aktuálna URL cesta
  • session_id – Pre analýzu na úrovni session
  • experiment_variant – Ak je používateľ v A/B teste
  • feature_name – Pri sledovaní používania funkcií

Dátové typy

Buďte konzistentní s dátovými typmi—PostHog detekuje typy automaticky, ale nekonzistencia spôsobuje problémy:

  • Booleany: is_premium: true (nie "yes" alebo 1)
  • Čísla: price: 49.99 (nie "$49.99")
  • Dátumy: ISO 8601 formát: 2025-01-15T10:30:00Z
  • Polia: features: ["analytics", "reports"]

Osvedčené postupy pre vlastnosti

  • Zahrňte viac vlastností, než si myslíte, že potrebujete. Neexistuje limit na počet vlastností, ktoré môže udalosť mať, a vaše budúce ja vám poďakuje.
  • Vyhýbajte sa PII vo vlastnostiach udalostí, keď je to možné. Používajte ID namiesto mien/emailov pre GDPR compliance.
  • Neduplikujte vlastnosti používateľa vo vlastnostiach udalosti. PostHog automaticky asociuje udalosti s profilmi osôb.

Kategórie udalostí

Organizujte udalosti do kategórií na základe cesty používateľa. Framework AARRR (Pirátske metriky) funguje dobre:

1. Akvizičné udalosti

Sledujte, ako používatelia objavujú a registrujú sa:

  • page_view – Návštevy landing page (alebo použite autocapture $pageview)
  • demo_request – Odoslania formulára
  • user_signup – Registrácia dokončená
  • email_verify – Kliknutie na potvrdzovací odkaz

2. Aktivačné udalosti

Sledujte „aha moment" a počiatočné dodanie hodnoty:

  • onboarding_start
  • onboarding_step_complete (s vlastnosťou step_name)
  • first_project_create
  • team_member_invite

3. Engagement udalosti

Sledujte priebežné používanie produktu:

  • feature_use (s vlastnosťou feature_name)
  • report_generate
  • dashboard_view
  • search_perform

4. Revenue udalosti

Sledujte monetizáciu a upgrade cesty:

  • pricing_page_view
  • checkout_start
  • subscription_create
  • plan_upgrade

5. Referral udalosti

Sledujte word-of-mouth rast:

  • invite_send
  • share_click (s vlastnosťou share_destination)
  • referral_complete

6. Retenčné udalosti

Sledujte signály churn a návratové používanie:

  • session_start – Návratové návštevy
  • subscription_cancel
  • downgrade_request
  • support_ticket_create

Frontend vs. Backend sledovanie

Robustný tracking plán používa frontend aj backend udalosti. Pochopenie, kedy použiť ktoré, je kritické.

Backend analytika je spoľahlivejšia

Existujú tri hlavné dôvody, prečo preferovať backend sledovanie pre kritické udalosti:

  1. Ad blockery: Mnoho používateľov má sledovanie zakázané alebo zablokované v prehliadačoch
  2. JavaScript problémy: Frontend analytika môže byť prerušená sieťovými problémami, CORS alebo nastaveniami prehliadača
  3. Presnosť dát: Server-side udalosti zachytávajú skutočný stav z vašej databázy

Kedy použiť ktoré

Použite frontend analytiku keď:

  • Čiastočné dáta sú akceptovateľné
  • Pochopenie používateľských ciest a sekvencií stránok
  • Sledovanie UI interakcií ako kliknutia, scrollovanie alebo odoslania formulárov
  • Zbieranie client-side performance dát (časy načítania stránky)

Použite backend analytiku keď:

  • Potrebujete presné dáta (napr. presné počty registrácií)
  • Sledovanie vysokohodnotových udalostí (registrácie, nákupy, predplatné)
  • CRUD udalosti (API požiadavky, ktoré vytvárajú, aktualizujú alebo mažú zdroje)
  • Backend joby a workflows

Používajte rozdielne názvy udalostí

PostHog odporúča používať rozdielne názvy udalostí pre frontend a backend udalosti, aby ste predišli duplicitnému počítaniu:

  • Frontend: signup_form_submit
  • Backend: user_create

Verzovanie udalostí

Ako sa vaša aplikácia vyvíja, menia sa aj udalosti, ktoré sledujete. Implementácia systému verzovania zabezpečuje, že môžete rozlíšiť medzi staršími a novšími definíciami udalostí.

Napríklad, ak ste pôvodne sledovali registration:signup_button_click a neskôr ste prepracovali registračný flow, zaveďte novú verziu:

  • Stará: registration:signup_button_click
  • Nová: registration_v2:signup_button_click

Toto zachováva historické dáta a zároveň vám umožňuje porovnať dopad zmien.

Implementačné príklady

JavaScript (Frontend)

// Vlastná udalosť s vlastnosťami
posthog.capture('plan_purchase', {
  price: 1599,
  plan_id: 'XYZ12345',
  frequency: 'monthly',
  features: {
    sso: true,
    custom_branding: true
  }
});

// Nastavenie vlastností používateľa
posthog.identify('user_123', {
  email: 'user@example.com',
  plan: 'enterprise',
  company_id: 'company_456'
});

Python (Backend)

from posthog import Posthog

posthog = Posthog('your-api-key', host='https://app.posthog.com')

# Zachytenie udalosti s vlastnosťami
posthog.capture(
    distinct_id='user_123',
    event='order_complete',
    properties={
        'order_id': '#0054',
        'subtotal': 3599,
        'currency': 'USD'
    }
)

Pridanie vlastností k autocapture

Môžete pridať vlastné vlastnosti k autocaptured udalostiam pomocou data atribútov:

<button
  data-ph-capture-attribute-button-type="primary-cta"
  data-ph-capture-attribute-page-section="hero"
>
  Registrovať sa
</button>

Vytvorenie dokumentu tracking plánu

Váš tracking plán by mal byť živý dokument. Odporúčame tabuľku s týmito stĺpcami:

  1. Názov udalosti: Podľa vzoru category:object_action
  2. Popis: Kedy sa táto udalosť spúšťa
  3. Kategória: Akvizícia, Aktivácia, Engagement, Revenue, Referral, Retencia
  4. Zdroj: Frontend, Backend alebo Oboje
  5. Vlastnosti: Zoznam povinných a voliteľných vlastností
  6. Typy vlastností: String, Number, Boolean, Array, atď.
  7. Príklady hodnôt: Vzorové dáta na testovanie
  8. Stav implementácie: Plánované, Vo vývoji, Live, Deprecated
  9. Vlastník: Kto je zodpovedný za túto udalosť
  10. Verzia: Sledujte zmeny definícií udalostí

Súkromie a compliance

Tracking plán musí zohľadňovať nariadenia o ochrane súkromia ako GDPR a CCPA.

GDPR úvahy

  • Osobné údaje: GDPR sa vzťahuje na akékoľvek dáta, ktoré môžu identifikovať jednotlivca, vrátane emailov, mien, IP adries a dokonca aj ID zariadení v kombinácii s inými dátami
  • Súhlas: Ak zbierame osobné údaje, musíte poskytnúť mechanizmus pre informovaný súhlas
  • Právo na zabudnutie: Použite funkcie vymazania dát PostHog pre splnenie požiadaviek na vymazanie
  • Lokalita dát: Pre robustný GDPR compliance použite PostHog Cloud EU (hostovaný vo Frankfurte)

Stratégie minimalizácie dát

  • Používajte anonymné ID namiesto PII vo vlastnostiach udalostí, keď je to možné
  • Používajte $set pre vlastnosti používateľa radšej ako zahŕňanie PII v každej udalosti
  • Nakonfigurujte maskovacie funkcie PostHog pre session recordings
  • Používajte realtime transformácie PostHog na anonymizáciu dát pred uložením

Cookieless sledovanie

PostHog podporuje cookieless sledovanie cez konfiguráciu cookieless_mode. Toto zabraňuje ukladaniu dát v cookies alebo local storage a zároveň stále počíta používateľov cez privacy-preserving hashe.

Nastavenie reverse proxy

Ad blockery môžu zabrániť tomu, aby udalosti dosiahli PostHog. Nastavenie reverse proxy posiela udalosti cez vašu vlastnú doménu, čím zlepšuje mieru zachytenia dát. Toto je obzvlášť dôležité pre presnú frontend analytiku.

Filtrovanie interných používateľov

Aplikácie s málo používateľmi môžu neúmyselne nafúknuť metriky zahrnutím používania vlastného tímu. Váš tracking plán by mal toto riešiť:

  • Vypnite sledovanie vo vývoji pomocou localhost alebo environment kontroly
  • Použite funkcie filtrovania interných používateľov PostHog
  • Vytvorte kohorty na vylúčenie členov tímu z reportov
  • Zvážte samostatné PostHog projekty pre vývoj a produkciu

Group Analytics

Pre B2B produkty je sledovanie na úrovni spoločnosti/organizácie nevyhnutné. Group analytics PostHog vám umožňuje:

  • Asociovať udalosti so skupinami (spoločnosti, tímy, organizácie)
  • Analyzovať metriky na úrovni skupiny, nielen jednotlivých používateľov
  • Sledovať vlastnosti skupiny oddelene od vlastností používateľa
// JavaScript príklad
posthog.group('company', 'company_id_123', {
  name: 'Acme Corp',
  plan: 'enterprise',
  employee_count: 500
});

Governance a údržba

Tracking plán funguje len ak je udržiavaný. Tu je ako ho udržať zdravý:

Riadenie zmien

  • Vyžadujte schválenie nových udalostí od vlastníka analytiky
  • Dokumentujte breaking changes pred implementáciou
  • Verzujte váš tracking plán (v1.0, v1.1, atď.)
  • Udržiavajte changelog modifikácií
  • Zvážte použitie nástrojov ako Avo alebo Trackingplan pre automatizovanú governance

Zabezpečenie kvality

  • Validujte udalosti v stagingu pred produkciou
  • Nastavte alerty pre chýbajúce povinné vlastnosti
  • Monitorujte objem udalostí pre anomálie (náhle poklesy môžu indikovať pokazené sledovanie)
  • Kvartálne audity na odstránenie nepoužívaných udalostí
  • Používajte funkcie správy dát PostHog na označenie udalostí ako overených, skrytých alebo deprecated

Dokumentácia

  • Udržiavajte tracking plán prístupný všetkým zainteresovaným stranám
  • Zahrňte implementačné príklady pre inžinierov
  • Dokumentujte „prečo" za každou udalosťou
  • Prepojte udalosti s obchodnými otázkami, na ktoré odpovedajú

Používanie Actions na organizáciu udalostí

PostHog Actions vám umožňujú kombinovať viacero udalostí alebo autocapture elementov do jednej sledovateľnej jednotky. Toto je užitočné pre:

  • Premenovanie udalostí: Vytvorte action s jasným názvom na základe mätúco pomenovanej udalosti
  • Kombinovanie súvisiacich udalostí: Zoskupte insight_create, insight_analyze a dashboard_create do action „Product Analytics Interactions"
  • Spracovanie autocapture driftu: Kombinujte „Kliknuté tlačidlo s textom 'Pridať do košíka'" a „Kliknuté tlačidlo s textom 'Pridať'" do jedného action

Bežné chyby, ktorým sa treba vyhnúť

  1. Sledovanie všetkého: Viac udalostí = viac šumu. Sledujte to, čo skutočne budete analyzovať.
  2. Vágne názvy udalostí: button_click vám nič nepovie. Buďte konkrétni.
  3. Nekonzistentné písanie: Miešanie User_Signup, user signed up a user_sign_up vytvára duplicitné udalosti, ktoré je ťažké kombinovať.
  4. Chýbajúce vlastnosti: Udalosti bez kontextu sú na segmentáciu nepoužiteľné.
  5. Žiadna dokumentácia: Ak len jedna osoba vie, čo udalosť znamená, máte problém.
  6. Spoliehanie sa len na frontend sledovanie: Prídete o udalosti od používateľov s ad blockermi.
  7. Nefiltrovanie interných používateľov: Používanie vášho tímu skreslí metriky.
  8. Ignorovanie súkromia: Pokuty GDPR môžu dosiahnuť 20 miliónov eur alebo 4% globálneho obratu.
  9. Žiadne verzovanie: Keď zmeníte definície udalostí, stratíte schopnosť porovnať staré a nové dáta.
  10. Duplikovanie udalostí na frontende a backende: Používajte rozdielne názvy, aby ste predišli dvojitému počítaniu.

Ďalšie kroky

Začnite s malým, zameraným tracking plánom:

  1. Identifikujte vašich top 5 obchodných otázok
  2. Mapujte udalosti potrebné na ich zodpovedanie
  3. Definujte vlastnosti pre každú udalosť
  4. Rozhodnite, či má byť každá udalosť frontend, backend alebo oboje
  5. Dokumentujte v zdieľanom tracking pláne
  6. Implementujte, validujte v stagingu a iterujte
  7. Nastavte monitoring pre anomálie objemu udalostí

Dobre navrhnutý tracking plán je rozdiel medzi analytikou, ktorá zberá prach, a analytikou, ktorá riadi rozhodnutia. Investujte čas vopred a vaše budúce ja vám poďakuje.

Dodatočné zdroje