PostHog kombinuje feature flags a A/B testovanie do jednotnej experimentačnej platformy. To znamená, že môžete kontrolovať rollout funkcií, spúšťať experimenty a analyzovať výsledky na jednom mieste. Tu je návod, ako ho efektívne používať.

Feature Flags vs. Experimenty

Najprv pochopte rozdiel:

Feature Flags kontrolujú, kto vidí funkciu. Používajte ich na:

  • Postupné rollouty (10% → 50% → 100%)
  • Beta testovanie s konkrétnymi používateľmi
  • Kill switches pre rizikové funkcie
  • Cielenie používateľov na základe vlastností
  • Trunk-based development (obalenie nedokončených funkcií)

Experimenty merajú dopad zmeny. Používajte ich na:

  • Testovanie hypotéz so štatistickou prísnosťou
  • Porovnávanie variantov voči kontrole
  • Určenie, či zmena zlepšuje metriky
  • Validáciu produktových rozhodnutí dátami

V PostHog sú experimenty postavené nad feature flags. Vytvoríte flag, nakonfigurujete experiment a PostHog sa postará o štatistickú analýzu pomocou Bayesovských alebo frequentistických metód.

Typy Feature Flags

PostHog podporuje tri typy feature flags:

Boolean Flags: Vracajú true alebo false. Používajte pre jednoduché on/off prepínače funkcií.

Multivariantné Flags: Vracajú jeden z viacerých string variantov (napr. „control", „test-a", „test-b"). Nevyhnutné pre A/B/n testovanie.

Payload Flags: Vracajú akýkoľvek platný JSON typ (objekt, pole, číslo, string, boolean alebo null) ako dodatočné konfiguračné dáta. Umožňujú konfigurovať funkcionalitu bez zmien kódu.

Vytváranie efektívnych Feature Flags

Konvencie pomenovania flagov

Používajte konzistentný vzor pomenovania s popisnými, hierarchickými kľúčmi:

  • feature-new-checkout-flow – Pre nové funkcie
  • experiment-pricing-page-v2 – Pre A/B testy
  • release-dark-mode – Pre kontrolované releasy
  • ops-maintenance-banner – Pre prevádzkové flagy

Best practices pre pomenovanie:

  • Pomenujte flagy tak, aby odrážali ich návratový typ (napr. is_premium_user pre boolean, selected_theme pre string)
  • Používajte pozitívny jazyk pre boolean flagy, aby ste sa vyhli dvojitým záporkám (napr. is_premium_user namiesto is_not_premium_user)
  • Zachovajte popisné názvy: is_v2_billing_dashboard_enabled je jasnejšie ako is_dashboard_enabled

Možnosti cielenia

PostHog ponúka silné cieliace schopnosti:

Percentuálny rollout:

Rollout na percento používateľov. PostHog používa konzistentný hashing, takže používatelia zostávajú v priradenej skupine naprieč sessions a zariadeniami (za predpokladu, že sú identifikovaní).

Vlastnosti používateľa:

Cielenie na základe atribútov používateľa:

  • plan = "enterprise" – Len enterprise zákazníci
  • country = "SK" – Geografické cielenie (vyžaduje povolené GeoIP)
  • is_beta_tester = true – Opt-in beta používatelia

Vlastnosti skupiny (B2B):

Cielenie celých organizácií pomocou group analytics:

  • company_size > 100 – Veľké spoločnosti
  • industry = "finance" – Konkrétne odvetvia

Kohorty:

Cielenie používateľov, ktorí patria do konkrétnych kohort, ktoré ste definovali. Poznámka: Behaviorálne kohorty (tie používajúce event/action filtre) nie sú podporované s feature flags kvôli požiadavkám na výkon dopytov.

Závislosti Feature Flags:

Vytvárajte flagy, ktoré závisia od stavov iných flagov pre komplexné rollout scenáre (napr. ukáž funkciu B len ak je funkcia A povolená).

Spúšťanie A/B testov

Proces experimentu

1. Začnite s hypotézou

Pred použitím PostHog si napíšte:

  • Čo meníte: „Pridanie progress baru do onboardingu"
  • Čo očakávate: „Zvýši dokončenie onboardingu o 10%"
  • Primárna metrika: Udalosť Onboarding Completed
  • Prečo tomu veríte: „Používatelia odchádzajú, lebo nevedia, koľko ešte zostáva"

2. Vypočítajte veľkosť vzorky a trvanie

PostHog obsahuje kalkulačku odporúčaného času behu v nastavení experimentu. Potrebujete vedieť:

  • Základná miera konverzie: Aká je aktuálna miera? (napr. 60%)
  • Minimálny detekovateľný efekt: Aký lift by bol zmysluplný? (napr. 10% relatívne = 66%)
  • Štatistická významnosť: Zvyčajne 95%
  • Štatistická sila: Zvyčajne 80%

PostHog vypočíta minimálnu požadovanú veľkosť vzorky a približne ako dlho bude test trvať na základe vašej návštevnosti. Dobré pravidlo: testy by mali bežať medzi jedným týždňom a jedným mesiacom.

3. Vytvorte experiment

  1. Prejdite na záložku A/B Testing v PostHog
  2. Kliknite „New Experiment"
  3. Pomenujte ho a opíšte vašu hypotézu
  4. Nastavte kľúč feature flag (PostHog vytvorí flag automaticky)
  5. Definujte varianty (Control, Test) alebo pridajte viac pre multivariantné testy
  6. Nastavte cieľovú metriku (funnel, trend alebo pomer)
  7. Voliteľne pridajte sekundárne metriky a guardrail metriky
  8. Najprv uložte ako draft pre testovanie

4. Testujte pred spustením

Pred spustením pre všetkých používateľov urobte testovací rollout (napr. 5% používateľov) na overenie:

  • Používatelia sú priraďovaní k variantom v očakávanom pomere (napr. 50/50)
  • Experiment nespôsobuje pády alebo chyby
  • Metriky sú správne sledované

5. Implementujte varianty

Vo vašom kóde použite feature flag na zobrazenie rôznych skúseností:

const variant = posthog.getFeatureFlag('experiment-onboarding-progress')

if (variant === 'control') {
  // Zobraziť pôvodný onboarding
} else if (variant === 'test') {
  // Zobraziť onboarding s progress barom
}

Dôležité: Odfiltrujte neoprávnených používateľov vo vašom kóde pred kontrolou feature flag. Napríklad, ak testujete nový onboarding flow, nezahrňte používateľov, ktorí už dokončili onboarding.

6. Počkajte na významnosť

Toto je ťažká časť. S Bayesovským prístupom PostHog môžete kedykoľvek skontrolovať výsledky bez štatistických penalizácií. PostHog vám ukáže, keď dosiahnete štatistickú významnosť (typicky 90%+ pravdepodobnosť výhry). Avšak vyhnite sa rozhodnutiam na základe veľmi skorých dát—nechajte credible intervals stabilizovať.

Pochopenie štatistických metód PostHog

PostHog podporuje dva štatistické prístupy:

Bayesovský (predvolený):

  • Priamo odpovedá „Je variant A lepší ako variant B?"
  • Ukazuje pravdepodobnosť výhry (pravdepodobnosť, že každý variant je lepší)
  • Poskytuje credible intervals (95% pravdepodobnosť, že skutočná hodnota leží v tomto rozsahu)
  • Môžete kedykoľvek skontrolovať výsledky bez štatistických penalizácií
  • Používa rôzne modely pre rôzne typy metrík:
    • Funnel metriky: Beta model
    • Count metriky: Gamma-Poisson model
    • Revenue/kontinuálne metriky: Lognormal model

Frequentistický:

  • Používa t-testy a confidence intervals
  • Reportuje p-values (výsledok je významný ak p < 0.05)
  • Používa Welchovu metódu na zohľadnenie nerovných variancií
  • Vyžaduje preddefinované veľkosti vzoriek; kontrola výsledkov skoro nafukuje falošne pozitívne výsledky

Predvolenú metódu môžete nastaviť v Settings > Organization > General, alebo prepísať per experiment.

Interpretácia výsledkov

PostHog vám ukáže:

  • Delta: Percentuálna zmena oproti kontrole (napr. +10%)
  • Pravdepodobnosť výhry (Bayesovský): Pravdepodobnosť, že tento variant je lepší (napr. 97%)
  • Credible/Confidence interval: Rozsah, kde skutočný efekt pravdepodobne leží
  • Štatistická významnosť: Farebne kódovaná (zelená = víťazí, červená = prehráva, bez farby = nie je významné)

Vizuálne indikátory:

  • Ak interval neprechádza nulou, výsledok je štatisticky významný
  • Šípky (↑ alebo ↓) indikujú, či metrika vzrástla alebo klesla

Kedy nasadiť:

  • Pravdepodobnosť výhry > 90% A pozitívny lift → Nasaďte treatment
  • Pravdepodobnosť výhry > 90% A negatívny lift → Ponechajte control
  • Pravdepodobnosť výhry < 90% → Bežte dlhšie alebo akceptujte nepreukazné výsledky

Bežné chyby pri experimentovaní

1. Zahrnutie neovplyvnených používateľov

Zahrnutie používateľov, ktorí nie sú ovplyvnení zmenou, riedi vaše výsledky. Ak testujete nový onboarding flow, odfiltrujte používateľov, ktorí už dokončili onboarding pred vyhodnotením feature flag.

2. Pozeranie a predčasné zastavenie (Frequentistický)

S frequentistickými metódami pozeranie výsledkov každý deň a zastavenie, keď to „vyzerá významne", nafukuje mieru falošne pozitívnych výsledkov. Nastavte veľkosť vzorky vopred a dodržte ju. Poznámka: Bayesovské metódy umožňujú kedykoľvek kontrolovať výsledky.

3. Testovanie príliš veľa vecí naraz

Ak zmeníte 5 vecí naraz, nebudete vedieť, ktorá spôsobila výsledok. Testujte jednu hypotézu naraz. Výhrada: zmeny, ktoré sú príliš malé, môžu spomaliť váš tím, takže vyvažujte granularitu s rýchlosťou.

4. Nesprávna metrika úspechu

Optimalizácia pre kliky na tlačidlo nezáleží, ak tieto kliky nevedú ku konverziám. Používajte obchodné metriky, nie vanity metriky.

5. Ignorovanie guardrail metrík

Váš treatment môže zvýšiť registrácie, ale znížiť retenciu. Vždy monitorujte counter metriky na zachytenie neočakávaných dôsledkov. Napríklad, ak testujete zmenu sign-up stránky, monitorujte aj čas strávený v aplikácii, aby ste sa uistili, že nezavádzate používateľov.

6. Príliš krátke bežanie

Efekty dní v týždni sú reálne. Bežte experimenty aspoň jeden celý týždeň, ideálne dva, aby ste zachytili variáciu v správaní používateľov. Sezónne obdobia môžu tiež spôsobiť významné zmeny.

7. Nepredvypočítanie času behu

Začatie bez rozhodnutia, ako dlho bežať, môže spôsobiť „peeking problem". Použite kalkulačku času behu PostHog na určenie, či máte dostatočnú štatistickú silu.

Pokročilé vzory

Holdout skupiny

PostHog má vstavanú podporu holdout skupín na meranie kumulatívneho dopadu viacerých zmien. Holdouty sú náhodne priradené zoznamy používateľov vylúčených z experimentov. Môžete:

  • Vylúčiť používateľov z konkrétnych experimentov alebo všetkých experimentov
  • Merať dlhodobé efekty po skončení experimentov
  • Overiť, že experimenty nemajú negatívne dlhodobé dopady

Keď je priradený k experimentu, váš holdout sa zobrazuje ako ďalší variant v analýze s úplnými štatistickými metrikami.

Postupné rollouty

Po víťazstve experimentu:

  1. Rollout na 10% a monitorujte chyby
  2. Zvýšte na 50% a sledujte metriky
  3. Rollout na 100%
  4. Odstráňte kód feature flagu v cleanup sprinte

Dôležité: Ponechanie flagov vo vašom kóde príliš dlho vytvára technický dlh a môže zmiasť budúcich vývojárov.

Experimenty cielené na skupiny

Pre B2B produkty spúšťajte experimenty na úrovni organizácie namiesto úrovne používateľa. Každý člen skupiny dostane rovnaký variant, čo zabezpečuje konzistentné skúsenosti a umožňuje meranie dopadu na skupinu ako celok.

Dokumentácia experimentov

Udržiavajte log každého experimentu:

  • Hypotéza a odôvodnenie
  • Dátumy začiatku/konca
  • Veľkosť vzorky a trvanie
  • Výsledky a štatistická významnosť
  • Rozhodnutie a poznatky

Toto zabraňuje opätovnému spúšťaniu neúspešných experimentov a buduje inštitucionálne znalosti. PostHog vám umožňuje pridávať popisy a screenshoty priamo k experimentom.

Tipy špecifické pre PostHog

Optimalizácia výkonu

  • Používajte lokálne vyhodnocovanie pre vysoký objem: Namiesto požiadavky pre každý flag PostHog periodicky načítava a ukladá definície flagov lokálne, čo umožňuje vyhodnocovanie bez sieťových volaní. Latencia klesne z ~100-500ms na menej ako 50ms.
  • Bootstrap flagy pre okamžité načítanie: Odovzdajte predvypočítané hodnoty flagov v počiatočnom načítaní stránky, aby ste sa vyhli oneskoreniam asynchrónneho vyhodnocovania a zabránili blikaniu.
  • Používajte server-side flagy pre kritické cesty: Client-side flagy môžu blikať. Pre checkout flows vyhodnocujte flagy server-side.

Spoľahlivosť

  • Nasaďte reverse proxy: Ad blockery môžu zakázať feature flags. Použitie vlastnej domény pre PostHog požiadavky znižuje zachytenie tracking blockermi.
  • Ošetrujte chyby elegantne: Obaľte SDK metódy PostHog do try-catch blokov. Nastavte vhodné timeouty pomocou feature_flag_request_timeout_ms.
  • Identifikujte používateľov konzistentne: Rôzne distinct IDs môžu spôsobiť, že ten istý používateľ dostane rôzne hodnoty flagov naprieč sessions. Vždy identifikujte používateľov, aby ste zabezpečili konzistentné skúsenosti.

Hygiena flagov

  • Minimalizujte umiestnenia flagov: Čím viac miest, kde sa flag objavuje v kóde, tým pravdepodobnejšie problémy. Obaľte flagy do jednej funkcie, ak sa používajú na viacerých miestach.
  • Upratujte po rolloutoch: Odstráňte kód flagu po plnom rolloute, aby ste znížili technický dlh.
  • Používajte evaluation environments: Kontrolujte, kde sa flagy vyhodnocujú (client-side vs. server-side), aby ste zabránili vyhodnocovaniu flagov v neočakávaných prostrediach a znížili zbytočné náklady na vyhodnocovanie.

Experimentálne funkcie

  • Zobrazujte nahrávky sessions: Pozrite presne, čo používatelia zažili v každom variante prístupom k nahrávkam naviazaným na výsledky experimentu.
  • Používajte toolbar na testovanie: Prepíšte hodnoty feature flagov vo vašom prehliadači na testovanie variantov bez ovplyvnenia iných používateľov.
  • Nastavte alerty: Nechajte sa upozorniť, keď experimenty dosiahnu významnosť, aby ste mohli rýchlo konať.

Metriky úspechu

Nebuďte prekvapení, keď experimenty zlyhajú. Odborové benchmarky ukazujú:

  • V Bing len 10-20% experimentov generuje pozitívne výsledky
  • Booking.com spúšťa ~25 000 testov ročne; len 10% generuje pozitívne výsledky

Hodnota je v učení. Každý experiment—výhra alebo prehra—vás niečo naučí o vašich používateľoch. Feature flags a experimenty sú najrýchlejšou cestou k zlepšeniu produktu. Každá funkcia sa stáva hypotézou, každý release sa stáva príležitosťou učiť sa. Začnite v malom, budujte sval a nechajte dáta riadiť vaše rozhodnutia.