Testy A/B dla analityków — moc testu i dwa podejścia

Testy A/B rzadko psują się na matematyce. Psują się na decyzjach: zła metryka, podglądanie wyniku co godzinę, ogłaszanie zwycięzcy przy dwustu konwersjach. Ten tekst to skrót tego, czego nauczyłem się, prowadząc testy i kampanie — podręcznik dla analityka, który chce robić testy A/B dla analityków dobrze, a nie tylko „odpalić eksperyment”. Jak technicznie postawić test, pisałem osobno: własne testy A/B w GTM i Firebase. Tu jest o tym, jak je zaprojektować i przeczytać.

Macierz błędów: dwa sposoby, żeby się pomylić

Każda decyzja po teście może być błędna na dwa sposoby:

	Decyzja na podstawie testu
	Wdrażamy wariant	Nie wdrażamy
Faktycznie brak różnicy	Błąd typu I (α) wdrażasz bubel	OK ✓ trafny brak wdrożenia
Wariant naprawdę lepszy	OK ✓ trafne wdrożenie	Błąd typu II (β) chowasz zwycięzcę

Poziom ufności (np. 95%) tnie ryzyko błędu I (α). Moc testu (np. 80%) tnie ryzyko błędu II (β = 1 − moc). Błąd I wdraża coś, co nie działa; błąd II przegapia realny zysk.

Błąd I (α, false positive): wdrażasz wariant, który nic nie zmienia. Wyższy poziom ufności (95%) ogranicza to ryzyko.
Błąd II (β, false negative): odrzucasz wariant, który naprawdę był lepszy. Wyższa moc (80%) ogranicza to ryzyko; β = 1 − moc (moc 80% → β 20%).

Koszt nie jest symetryczny: błąd I to wdrożony bubel (czasem drogi do wycofania), błąd II to cichy, przegapiony zysk. Wybór ufności i mocy to decyzja, którego błędu bardziej się boisz.

Ile danych naprawdę potrzebujesz: MDE i moc

MDE (minimalny wykrywalny efekt) to najmniejsza zmiana, jaką chcesz wyłapać:

<5% — bardzo dużo danych (świetnie, jeśli masz ruch)
5–10% — realne
>10% — tylko duże zmiany; testowanie koloru przycisku przy takim MDE nie ma sensu, bo nie masz mocy, by wykryć drobny efekt

Przed odpaleniem policz wielkość próby z założonego MDE, mocy i ufności. Bez tej kalkulacji odpalasz test, który i tak niczego nie rozstrzygnie. Policz to dla swojej strony w kalkulatorze wielkości próby testu A/B, a liczby do niego weź z eksportu GA4 w BigQuery.

Którą metrykę robisz królem: OEC vs metryki lokalne

OEC (Overall Evaluation Criterion) to jedna, nadrzędna, user-based metryka decyzyjna — wdrażamy / nie. W e-commerce zwykle RPU (Revenue Per User) lub PPU (Profit per user). Ta druga jest lepsza, bo pokazuje realny zysk, ale wymaga przekazania marży do tagów — zwykle przez tagowanie po stronie serwera, jak przy POAS zamiast ROAS. OEC służy do ostatecznej decyzji, ma najwyższy priorytet, jest stałe między eksperymentami i najlepiej koreluje z długoterminowym sukcesem.

CR (conversion rate) to metryka lokalna/diagnostyczna — szybki, stabilny sygnał kierunkowy, ale to nie OEC. CR szybciej się stabilizuje (mniejsza wariancja); RPU i PPU lepiej oddaje biznes, ale wymaga większej próby lub redukcji wariancji.

Zasada nadrzędna: liczysz użytkowników, nie sesje. Testy statystyczne zakładają niezależność obserwacji, a sesje tego samego usera nie są niezależne (konwersja może paść w kolejnej sesji). Sprzedajesz userom, nie sesjom. To zresztą działa tylko wtedy, gdy masz solidną warstwę danych pod spodem — o architekturze danych pisałem osobno.

Dwa podejścia: częstościowe vs bayesowskie

Częstościowe opiera się na p-value — prawdopodobieństwie uzyskania tak (lub bardziej) ekstremalnego wyniku, zakładając, że nie ma różnicy (H₀ prawdziwa). Istotność, gdy p < α (zwykle 0,05). Uwaga na pułapkę interpretacyjną: p-value nie mówi „jest 95% szans, że wariant jest lepszy”.
Bayesowskie liczy wprost prawdopodobieństwo, że wariant jest lepszy („jest 95% szans, że B > A”). Łatwiejsze do wytłumaczenia interesariuszom, bo odpowiada na pytanie, które naprawdę zadają.

W praktyce bayesowskie wygrywa w komunikacji z biznesem; częstościowe to wciąż standard w wielu narzędziach. Ważniejsze niż wybór szkoły: dyscyplina (patrz niżej).

Pułapki, które unieważniają wynik

SRM (Sample Ratio Mismatch): przydział miał być 50/50, a jest 54/46. To sygnał, że coś jest zepsute (bug randomizacji, filtrowanie botów, redirect). Wynik z SRM idzie do kosza, nie do interpretacji.
Podglądanie (peeking): sprawdzanie p-value co chwilę i kończenie, gdy spadnie poniżej 0,05, zawyża błąd I. Albo ustal próbę z góry, albo użyj metod sekwencyjnych/bayesowskich z korektą.
Wielokrotne porównania: im więcej metryk/segmentów/wariantów, tym większa szansa, że coś wyjdzie „istotne” przypadkiem. Przy jednym porównaniu A vs B na OEC korekty nie stosujesz. Przy kilku wariantach porównywanych z kontrolą na OEC — tak: Bonferroni (α dzielone przez liczbę porównań) jest konserwatywny, ale prosty i tak liczy kalkulator istotności. Przy wielu metrykach i segmentach w eksploracji lepszy jest FDR (Benjamini–Hochberg) — kontroluje odsetek false positives bez nadmiernej utraty mocy.
Regresja do średniej: ekstremalny wynik ma tendencję wracać bliżej średniej przy kolejnym pomiarze — nawet bez realnej zmiany. Sprawdź stabilność metryk w pre-periodzie i porównaj z analogicznym okresem, zanim ogłosisz sukces.
One-sided vs two-sided: dwustronny, gdy nie wiesz, czy zmiana pomoże czy zaszkodzi (eksploracja). Jednostronny tylko przy silnej hipotezie i jednym kierunku — łatwo go nadużyć, żeby „dobić” istotność.

Prawo Twymana: jeśli wynik wygląda wyjątkowo ciekawie, najpewniej jest błędny. Zanim ogłosisz spektakularny lift — wyklucz SRM, sezonowość i bug.

Zaawansowane: więcej mocy bez więcej ruchu (CUPED)

CUPED wykorzystuje dane przed-eksperymentalne (pre-period) do redukcji wariancji — zwiększa moc bez zwiększania ruchu. Intuicja: user, który wcześniej wydawał podobne kwoty, zachowa się podobnie w teście; „odejmujesz” tę przewidywalną część i zostaje czystszy sygnał efektu.

Czy się opłaca? Sprawdź korelację pre vs test (Pearson):

-- np. ~0,47 → wariancja spada o ρ² ≈ 22%
-- → CUPED ma sens
SELECT CORR(revenue_pre, revenue_test) AS corr_pre_post
FROM user_level_data;

Mniej formalnie: nawet zwykła korekta o metryki pre-period (bez pełnego CUPED) to powszechna, sensowna praktyka. Jeszcze dalej — model (np. regresja w BigQuery ML) policzy efekt skorygowany o pre-period, np. „wariant zwiększa przychód o +5,6 zł na użytkownika, p = 0,002”. Wszystko po to, by pewniej i szybciej wykryć prawdziwy efekt.

Jak przekazać wynik (i nie zgubić go po miesiącu)

Biznesowi: zacznij od decyzji, nie od statystyki. „Rekomendujemy wdrożenie / nie — z wpływem na przychód i ryzykiem.” Potem które metryki zdecydowały i dlaczego. P-value i istotność są tłem, nie przekazem — klient ma wyjść z jasnym „co robimy dalej”.

I rzecz, o której łatwo zapomnieć: pamięć instytucjonalna — dziennik testów (hipoteza, wynik, decyzja). Bez niego firma testuje w kółko to samo i traci wiedzę z każdym odejściem analityka.

Metoda przed narzędziem

Narzędzie do testów wybierzesz w godzinę. Wiarygodność wyniku zależy od decyzji podjętych przed startem: policzonej próby, jednej metryki, która rozstrzyga, i zakazu zaglądania do wyniku przed końcem. Test bez nich też da liczbę — tylko nikt nie powinien na niej decydować.