Statystyka eksperymentów: istotność, moc, MDE

Statystyka A/B testing to obszar, w którym 80% zespołów marketingowych podejmuje decyzje na podstawie niezrozumianych liczb. Test trwa 7 dni, wariant B wygrywa o 12%, wdrażamy wariant B – brzmi dobrze, ale czy to wynik prawdziwy czy szum? Dobra odpowiedź wymaga zrozumienia trzech pojęć: istotności statystycznej, mocy testu i minimalnego wykrywalnego efektu (MDE). Ten tekst tłumaczy je po polsku, bez żargonu akademickiego, z praktycznymi regułami, kiedy uruchamiać test, a kiedy odpuścić.

Materiał jest częścią klastra analityka marketingowa 2026. Zakładamy, że macie już wybrane narzędzie do testowania – jeśli nie, zacznijcie od alternatyw dla Google Optimize. Dla praktycznego projektowania eksperymentów zajrzyjcie też do projektowania testów A/B.

Spis treści

1. Podstawy – dlaczego statystyka w ogóle jest potrzebna
2. Istotność statystyczna – co naprawdę znaczy p-value
3. Moc testu – ile razy przegapicie prawdziwego zwycięzcę
4. MDE – czego test nie wykryje
5. Wielkość próbki – jak ją policzyć
6. Bayes vs frequentist – dwa podejścia
7. Praktyczny przepływ uruchomienia testu
8. Najczęstsze błędy statystyczne
9. FAQ – najczęstsze pytania
10. Co dalej

Podstawy – dlaczego statystyka w ogóle jest potrzebna

Wyobraźcie sobie, że rzucacie monetą 100 razy i wypada 54 orłów. Moneta uczciwa? Prawdopodobnie tak – 54 z 100 mieści się w zakresie losowych wahań. A 100 rzutów i 72 orłów? Też może być uczciwa, ale prawdopodobieństwo, że to się przytrafiło przypadkiem, jest już bardzo małe. Statystyka daje nam narzędzia do ustalania, gdzie jest granica między „wahanie losowe” a „różnica rzeczywista”. Szczegóły opisujemy w alternatywy dla Google Optimize.

A/B testing to dokładnie ten problem. Wariant A ma 2,1% konwersji, wariant B ma 2,4%. Czy B jest lepszy, czy to szum? Odpowiedź zależy od tego, na ilu użytkownikach mierzyliście. Na 200 użytkowników różnica 0,3 pp to niemal na pewno szum. Na 200 tys. – to już twarda różnica, warta wdrożenia.

Trzy pytania, na które odpowiada statystyka

1. Czy widziana różnica jest prawdziwa? (istotność)
2. Jak duża jest ta różnica? (wielkość efektu + przedziały ufności)
3. Czy mieliśmy szansę ją wykryć? (moc i MDE)

Decyzja biznesowa wymaga odpowiedzi na wszystkie trzy. „P-value < 0,05″ odpowiada tylko na pierwsze.

Istotność statystyczna – co naprawdę znaczy p-value

P-value to prawdopodobieństwo, że obserwowana różnica (lub większa) zdarzyłaby się przez przypadek, gdyby oba warianty były tak naprawdę identyczne. Ważne – to nie jest prawdopodobieństwo, że wariant B jest lepszy. To jest prawdopodobieństwo takich wyników w świecie, gdzie nie ma różnicy. Temat ten rozwijamy w projektowanie testów A/B.

Próg p < 0,05 – skąd ta magiczna liczba

Próg 0,05 jest konwencją z lat 20. XX wieku, zaproponowaną przez Ronalda Fishera. Nie ma matematycznego uzasadnienia – to tylko wyraźna linia. Oznacza – jesteśmy skłonni zaakceptować 5% ryzyka, że wdrożymy zmianę, która jest tak naprawdę neutralna (false positive, błąd typu I).

Praktyczny wniosek – jeśli uruchamiacie 20 testów z progiem 0,05, na podstawie czystej losowości 1 z nich pokaże „istotność”, choć nic nie zmieniła. Dlatego przy wielu jednoczesnych testach trzeba stosować korekty (Bonferroni, Holm-Bonferroni) albo bayesowskie podejście.

Typowe nieporozumienia wokół p-value

Częste przekonanie	Prawda
P = 0,03 oznacza, że jest 97% szans, że B jest lepszy	Błędnie. P-value nie jest prawdopodobieństwem hipotezy. Mówi tylko o prawdopodobieństwie danych przy założeniu braku różnicy.
P = 0,51 oznacza, że nie ma różnicy	Błędnie. Brak istotności to brak dowodu, nie dowód braku. Może być różnica, której test nie wykrył.
Można oglądać p-value co godzinę, wyłączyć test, gdy spadnie poniżej 0,05	Bardzo błędnie. „Peeking” (podglądanie) multiplikuje błąd typu I. P-value jest ważne tylko przy próbce zaplanowanej z góry.
P = 0,048 i p = 0,052 to fundamentalnie różne wyniki	Błędnie. Próg 0,05 jest umowny. Różnica między 0,048 a 0,052 jest niemal zero – oba mówią to samo.

Moc testu – ile razy przegapicie prawdziwego zwycięzcę

Moc testu (power, statistical power) to prawdopodobieństwo, że test wykryje różnicę, która naprawdę istnieje. Standard w branży – moc 80%. To znaczy – jeśli różnica naprawdę jest, test ją wykryje w 80% uruchomień. W 20% przypadków test powie „brak istotności”, choć jest różnica – to błąd typu II. Szczegóły opisujemy w GA4 dla zaawansowanych.

Co wpływa na moc testu

1. Wielkość próbki – większa próbka = większa moc. Podwojenie ruchu zwiększa moc z 50% do 70-80% dla typowych testów.
2. Wielkość efektu – im większa różnica między wariantami, tym łatwiej ją wykryć. Wykrycie różnicy 20% jest proste nawet na 500 użytkowników; wykrycie 2% wymaga 50 tys.+
3. Wariancja metryki – metryki o wysokiej wariancji (przychód na użytkownika, czas na stronie) wymagają 2-5 razy większych próbek niż metryki binarne (kupił/nie kupił).
4. Próg istotności – niższy próg (0,01 zamiast 0,05) zmniejsza moc. To standardowa zamiana – mniejsze ryzyko false positive, większe ryzyko false negative.

Dlaczego moc 80%

Konwencja – przy moc 80% akceptujemy, że co piąty prawdziwy zwycięzca zostanie przegapiony. Przy moc 90% zwiększacie próbkę 30-40%, ale zmniejszacie ryzyko przegapienia do 10%. Wybór zależy od kosztu błędu – w e-commerce testy B2C akceptują 80%, w medycynie testy klinicznych wymagają 90-95%.

MDE – czego test nie wykryje

Minimum Detectable Effect (MDE) to najmniejsza różnica między wariantami, którą test wykryje przy zadanej próbce, moc 80% i istotności 0,05. MDE jest kluczowym pojęciem planowania – mówi wam, czy w ogóle ma sens uruchamiać test.

Formuła MDE (uproszczona)

MDE ≈ 2 × sqrt(p × (1-p) / n) × 2,8 gdzie p to baseline conversion rate, n to liczba użytkowników w grupie. Liczba 2,8 to suma z-score dla istotności 0,05 (1,96) i mocy 80% (0,84).

Przykład liczbowy

Baseline conversion rate – 2%. Macie 5 000 użytkowników na wariant.

MDE = 2 × sqrt(0,02 × 0,98 / 5000) × 2,8 ≈ 1,1 punktu procentowego, czyli wzrost z 2% do 3,1% (relatywnie +55%).

Wniosek – test na 10 tys. użytkowników wykryje tylko zmianę > 55% relatywnie. Wariant, który podnosi konwersję z 2% do 2,3% (relatywnie +15%), pozostanie niewykryty. Jeśli wasze realne zmiany dają 10-20% wzrostu, potrzebujecie 50-200 tys. użytkowników w grupie. Temat ten rozwijamy w pillar o analityce marketingowej 2026.

Tabela MDE dla typowych przypadków

Baseline CR	Użytkownicy/grupa	MDE relatywny	MDE absolutny
2%	5 000	+55%	+1,1 pp
2%	20 000	+28%	+0,55 pp
2%	50 000	+18%	+0,35 pp
2%	200 000	+9%	+0,18 pp
5%	5 000	+35%	+1,8 pp
5%	50 000	+11%	+0,55 pp
10%	5 000	+24%	+2,4 pp
10%	50 000	+7%	+0,7 pp

Kluczowe spostrzeżenie – niskie baseline (2% konwersji) wymagają 4-10 razy większych próbek niż wysokie (10%+). Dla e-commerce typowo trzeba 30-100 tys. użytkowników na wariant; dla SaaS z 10-20% trial→paid konwersją wystarcza 3-10 tys.

Wielkość próbki – jak ją policzyć

Odwrotność MDE – zamiast pytać „ile wykryję przy danej próbce”, pytacie „ile próbki potrzebuję, żeby wykryć daną różnicę”.

Formuła próbki (dla metryki binarnej)

n ≈ (z_α + z_β)² × (p1(1-p1) + p2(1-p2)) / (p2 – p1)² gdzie z_α i z_β to wartości krytyczne dla istotności i mocy, p1 to baseline, p2 to oczekiwany wariant.

Praktyczne kalkulatory

• Evan Miller’s A/B test calculator – najczęściej używany, darmowy, web-based.
• Optimizely sample size calculator – prosty interfejs.
• G*Power – zaawansowany, desktop, darmowy, dla metryk ciągłych i kompleksowych designu.
• VWO Sample Size Calculator – dla eksperymentów multivariate.

Przykład pełnego planowania

Sklep e-commerce, baseline CR 2,5%, ruch 180 tys. unikalnych użytkowników/miesiąc, test na stronie produktowej (100% ruchu widzi wariant). Cel – wykryć zmianę o 10% relatywnie (z 2,5% na 2,75%).

1. Wchodzimy w kalkulator – baseline 2,5%, MDE 10% relatywnie, moc 80%, istotność 0,05 (two-sided).
2. Wynik – 62 000 użytkowników na wariant, czyli 124 000 łącznie.
3. Podzielone przez 180 tys./miesiąc = 0,69 miesiąca ≈ 21 dni testu.
4. Rekomendacja – planowany czas testu 3 tygodnie (uwzględniając cykl tygodniowy).

Zasady minimalnego czasu trwania

• Minimum 7 dni – ze względu na cykl tygodniowy (inny behavior pon-pt vs weekend).
• Minimum 2 pełne cykle tygodniowe (14 dni) jeśli metryka jest wrażliwa na dzień tygodnia.
• Maksimum 8 tygodni – dłużej i zmieniają się okoliczności (sezonowość, konkurencja), walidacja testu przestaje być jednoznaczna.
• Nawet jeśli próbka jest osiągnięta przed 7 dniami, test trzymajcie do końca tygodnia.

Bayes vs frequentist – dwa podejścia

Dwie szkoły statystyki mają dwa różne sposoby oceny testu. Frequentist (klasyczny) – to, co opisaliśmy powyżej (p-value, moc, MDE). Bayesowski – inne narzędzia, inny sposób myślenia.

Frequentist – co jest standardem

Test stawia hipotezę zerową „warianty są identyczne”. Zbiera dane. Oblicza, jak prawdopodobne są te dane przy hipotezie zerowej (p-value). Jeśli < 0,05 – odrzuca hipotezę zerową. Wymaga zdefiniowania próbki z góry.

Bayesowski – co oferuje

Test zaczyna od „prior” (wstępne przekonania) o rozkładach konwersji. Aktualizuje te przekonania na podstawie danych (posterior). Zwraca prawdopodobieństwo, że wariant B jest lepszy niż A, bezpośrednio (np. „93% prawdopodobieństwo, że B wygrywa”). Pozwala na wcześniejsze zakończenie testu, gdy wynik jest oczywisty.

Które wybrać dla marketingu

W 2026 dla typowych testów A/B w e-commerce i SaaS bayesowskie podejście ma 2-3 zalety. Pierwsze – intuicyjność wyniku („83% że B jest lepszy” jest zrozumiałe dla managera). Drugie – możliwość wcześniejszego zakończenia. Trzecie – brak pułapki „peeking” (można patrzeć na wyniki w trakcie). Narzędzia, które domyślnie używają Bayesa – VWO, AB Tasty, Convert, Optimizely X.

Ograniczenie Bayesa – wybór priora. Złe priory dają złe wyniki. Dla testów marketingowych używajcie priorów „non-informative” (uniform) lub opartych na historii testów w tej samej organizacji.

Praktyczny przepływ uruchomienia testu

Poniżej checklist, który domyka teorię w siedem kroków do wdrożenia.

1. Zdefiniujcie hipotezę – „Zmiana CTA z niebieskiego na pomarańczowy zwiększy konwersję o co najmniej 8%”. Bez hipotezy nie ma co mierzyć.
2. Wybierzcie metrykę kluczową – jedna, maksymalnie dwie. Reszta to metryki pomocnicze (guardrail metrics).
3. Obliczcie próbkę – na podstawie baseline, oczekiwanego MDE, mocy 80%, istotności 0,05. Użyjcie kalkulatora.
4. Obliczcie czas trwania – próbka / dzienny ruch, minimum 7 dni.
5. Uruchomcie test i nie podglądajcie wyników (jeśli frequentist) lub ustalcie próg decyzyjny (jeśli Bayes – np. „zakończ, gdy PBB > 95%”).
6. Po zakończeniu – raport – p-value/posterior, przedział ufności, wielkość efektu, guardrail metrics.
7. Decyzja – wdrożyć / nie wdrożyć / powtórzyć test.

Najczęstsze błędy statystyczne

• Peeking (podglądanie wyników w trakcie testu) – zwiększa ryzyko false positive 3-5 razy. W frequentist podejściu jest nielegalne.
• Test zbyt krótki – 3 dni to za mało; cykl tygodniowy nie został uwzględniony.
• Brak kalkulacji MDE przed startem – test kończy się bez istotności, nie wiadomo, czy to brak efektu czy mała moc.
• Test na niezależnej próbce – ten sam user widział oba warianty (zły routing cookies) – wyniki bez wartości.
• Wielokrotne testowanie jednej hipotezy – test nie wyszedł, odpalamy znów, znów, aż wyjdzie – false positive gwarantowany.
• Ignorowanie guardrail metrics – wariant B zwiększa konwersję, ale też zwiększa refund rate – łączna marża spada.
• Testowanie kilku zmian naraz jako jeden eksperyment – nie wiadomo, która zmiana dała efekt. Używajcie multivariate testing albo testujcie pojedynczo.
• Stosowanie testu t-Studenta dla metryk binarnych – dla konwersji używajcie testu z dwóch proporcji (chi-square), nie t-test.
• Brak kontroli Novelty Effect – użytkownicy powracający reagują inaczej w pierwszym tygodniu na nowość. Włączcie segmentację new vs returning.

FAQ – najczęstsze pytania

Czy 95% confidence i 0,05 p-value to to samo?

Praktycznie tak, formalnie nie. 95% confidence oznacza, że przedział ufności pokrywa prawdziwą wartość parametru w 95% powtórzeń eksperymentu. P = 0,05 oznacza, że obserwowane dane (lub ekstremalniejsze) zdarzają się w 5% przypadków przy hipotezie zerowej. Te dwie metryki są matematycznie powiązane – próg istotności 0,05 daje 95% poziom ufności przedziału. W praktyce używa się ich wymiennie, ale w komunikacji do managerów lepiej mówić „95% ufności, że efekt jest między X% a Y%” niż „p-value 0,03″.

Co zrobić, gdy test trwa 4 tygodnie i nic nie wykazał?

Trzy możliwości. Pierwsza – efekt naprawdę jest mały lub zerowy. Przed wnioskiem sprawdźcie, czy MDE testu był w ogóle rozsądny (np. dla MDE 20% nie dziwi, że efekt 8% nie wyszedł). Druga – test zaplanowany źle, moc za mała. Jeśli po 4 tygodniach p-value oscyluje wokół 0,12-0,25, prawdopodobnie trzeba 2-3 razy więcej ruchu. Trzecia – problem z implementacją (rozproszone grupy, błąd SRM – sample ratio mismatch, glitch w tagowaniu). Zanim zakończycie test, zawsze zróbcie audyt SRM (Chi-square test na proporcji użytkowników w grupach – jeśli p < 0,01, coś jest nie tak z routingiem).

Czy mogę zakończyć test wcześniej, gdy p-value spada poniżej 0,05?

Nie, jeśli używacie frequentist bez correction. P-value jest ważne tylko w zaplanowanej próbce. Podglądanie i wcześniejsze kończenie zwiększa false positive rate 3-5 razy. Jeśli chcecie elastycznego zakończenia, użyjcie metod sekwencyjnych – np. Alpha Spending (O’Brien-Fleming, Pocock), SPRT, lub przejście na bayesowskie podejście. Narzędzia typu Optimizely, VWO, Statsig oferują wbudowane sequential testing – warto je włączyć w projektach z dużym ruchem, gdzie szybkie decyzje są wartością.

Jak liczyć próbkę dla metryk ciągłych (AOV, czas na stronie)?

Metryki ciągłe wymagają innej formuły – przy t-teście próbka zależy od wariancji (odchylenia standardowego), nie od proporcji. Wzór – n ≈ 2 × (z_α + z_β)² × σ² / δ² gdzie σ to odchylenie standardowe metryki, δ to MDE. Wariancja AOV jest zwykle wysoka – 40-80% średniej. Dla AOV 200 PLN z σ 120 PLN i oczekiwanym MDE 10 PLN (5%) potrzebujecie około 45-60 tys. obserwacji na grupę. Alternatywnie – używajcie metryk proxy (conversion rate zamiast AOV, bo łatwiej testowalne) lub trimmujcie outliery (np. 95 percentyl), co obniża wariancję 2-3 razy.

Czym jest Sample Ratio Mismatch (SRM) i dlaczego to ważne?

SRM to sytuacja, gdy ruch nie rozkłada się zgodnie z oczekiwanym podziałem (np. zaplanowaliście 50/50, a dostaliście 52/48). Różnica może wydawać się niewielka, ale SRM jest często sygnałem błędu technicznego – wyciek cookies, redirect, cache’owanie wariantu. Każdy test powinien być sprawdzony pod kątem SRM przed analizą wyników. Test chi-square z progiem p < 0,01 – jeśli SRM istotny, wyniki testu są niewiarygodne, niezależnie od p-value metryki głównej. SRM wykrywa 90% błędów implementacji testu; ignorowanie go to najczęstsza przyczyna „dziwnych wyników” w testach.

Ile testów jednocześnie mogę uruchamiać na tej samej stronie?

Zależy od ruchu i narzędzia. Reguły praktyczne – do 5 niezależnych testów jednocześnie, jeśli są na różnych stronach lub różnych segmentach ruchu. Do 2-3 na tej samej stronie, jeśli narzędzie wspiera orthogonal bucketing (każdy użytkownik wpada do losowych grup wszystkich testów). Więcej testów – korzystajcie z frameworka multi-arm bandit albo pełnego multivariate testingu. Przy 10+ równoczesnych testach i progu 0,05 statystycznie oczekujcie 0,5 false positive miesięcznie – warto wtedy stosować korektę Bonferroni (próg 0,05/10 = 0,005) albo bayesowskie metody. Praktyczny test multi-variate opisujemy w materiale o projektowaniu testów A/B.

Co robić, gdy zarząd nie akceptuje testu ze względu na „zdrowy rozsądek”?

Trzy odpowiedzi działają. Pierwsza – pokażcie MDE aktualnej próbki. „Żeby ten test wykazał 20% wzrost z istotnością 0,05 i mocą 80%, potrzebowaliśmy 12 tys. użytkowników. Mieliśmy 1800. Test bezwartościowy statystycznie, niezależnie od wyniku”. Druga – historia testów „oczywistych”. W branży e-commerce około 65% testów, które zespół uznał za „oczywiste wygrane”, nie pokazało istotnej różnicy lub pokazało stratę. Testowanie chroni przed zgadywaniem. Trzecia – propozycja testu pilotażowego na 10-20% ruchu. Zbierze dane, pokaże kierunek, nie blokuje wdrożenia dla większości klientów.

SME vs enterprise – statystyka A/B testingu w różnej skali

Podejście do statystyki testów zależy od wolumenu ruchu i dojrzałości analitycznej organizacji. Oto dwa kontrastujące profile.

Profil SME – ruch 10 000-500 000 sesji/mies.

Przy tej skali możliwe jest 1-3 testy miesięcznie, każdy 3-6 tygodni. Narzędzia: VWO, Convert.com, Optimize Next (po śmierci Google Optimize) – 100-500 USD/mies. Frameworki: frequentist z kalkulatorem próbki, decyzja po zakończeniu (nigdy peeking). Testowane hipotezy: CTA color/text, headline, pricing display, formularze. Zespół: 1 CRO specjalista shared z marketing/analytics.

Typowe błędy SME: (1) testowanie zbyt małych zmian w zbyt małym ruchu – MDE niemożliwe do wykrycia, (2) peeking (codzienne sprawdzanie) – prowadzi do false positive’ów, (3) zbyt wiele hipotez testowanych jednocześnie bez Bonferroni correction. Pełen obraz tematu znajdziesz w kompletnym przewodniku analityka marketingowa 2026.

Profil enterprise – ruch 5M+ sesji/mies.

Enterprise prowadzi 10-50 testów równolegle, używa sequential testing (wcześniejsze zakończenie gdy p-value stabilnie niskie), multi-armed bandit dla continuous optimization, Bayesian frameworks dla niepewności. Zespół: 2-4 data scientists, 1-2 experimentation engineers, 1 head of experimentation. Stack: Statsig, Optimizely Stats Accelerator, Eppo, internal platform. Framework: strict OKR — minimum % tests yielding positive lift, experimentation velocity, decision quality score.

Tabela porównawcza

Wymiar	SME	Enterprise
Testów/miesiąc	1-3	10-50
Framework	Frequentist + kalkulator	Bayesian + sequential
Narzędzie	VWO, Convert 100-500 USD/mies.	Statsig, Eppo 5-20 tys. USD/mies.
SRM check	Manualny po teście	Automatyczny w real-time
Zespół	0,5 FTE CRO	5-10 FTE experimentation
Czas do decyzji	3-6 tygodni	3-14 dni (sequential)

Integracje – GA4, CRM, n8n

Integracja z GA4 – cross-reference z real behavior

Narzędzia A/B testing (VWO, Optimize Next) mają własny tracker, ale warto duplikować events do GA4 (custom dimension: experiment_id, variant_id). Korzyści: porównanie, co A/B tool widzi vs co GA4, analiza cohorts (czy wariant A jest lepszy dla new users, gorszy dla returning), długoterminowy impact (30-90 dni post-experiment) – czy winning variant nie wygasa.

Integracja z CRM – lead quality verification

A/B test na form submit może pokazać winning variant, ale CRM może pokazać że te leady są gorszej jakości (niższy MQL rate). Integracja: push variant_id do CRM jako atrybut leada, porównanie downstream metrics (MQL rate, SQL rate, closed won rate) w 30-60 dni po zakończeniu testu. Jeśli variant A daje +15% CR ale -30% SQL rate – rollback. Bez tej walidacji niektórzy podejmują decyzje na bazie vanity metrics.

Integracja z n8n – automated alerts

n8n workflow: daily check statystyki testu przez API VWO/Optimize, alert gdy p-value stabilnie 1% różnicy, weekly summary dla stakeholderów. Bez automation zespół sam musi codziennie sprawdzać, co jest męczące i ryzykowne (peeking).

Zespół i wynagrodzenia 2026

• CRO Specialist (hipotezy, implementacja, analiza): 13 000-22 000 zł mid, 22 000-32 000 zł senior.
• Data Scientist (statystyka, Bayesian models): 18 000-35 000 zł mid, 35 000-55 000 zł senior.
• Experimentation Engineer (platforma, server-side testing): 20 000-38 000 zł.
• Head of Experimentation: 28 000-50 000 zł.
• Product Analyst (downstream analysis): 14 000-24 000 zł.

Roadmap 30/60/90 dni – dojrzała kultura A/B testingu

Dni 1-30: fundament

• Dzień 1-10: audit obecnych testów (jakie były, ile prowadziło do wdrożenia, ile do rollbacku). Analiza statystyki — ile było valid, ile z peeking’iem.
• Dzień 11-20: wybór narzędzia (VWO/Optimize Next dla SME, Statsig/Eppo dla enterprise), setup tracking.
• Dzień 21-30: pierwszy test z pełną dokumentacją (hipoteza, MDE, próbka, plan decyzyjny).

Dni 31-60: statystyczny rygor

• Dzień 31-45: wdrożenie SRM check’u jako obowiązkowego pre-analysis.
• Dzień 46-55: setup integracji GA4 i CRM dla downstream validation.
• Dzień 56-60: pierwsze testy z weryfikacją downstream (30-60 dni post-test).

Dni 61-90: velocity i kultura

• Dzień 61-70: batch testing – 3-5 testów równolegle z Bonferroni correction.
• Dzień 71-80: regularna retrospektywa testów (raz/tydzień 30 min): co działa, co nie.
• Dzień 81-90: dashboard experimentation KPIs (tests/mies., velocity, win rate, decision quality).

Case detaliczny – polski e-commerce i 3 miesiące poprawionej statystyki

Polski e-commerce (beauty, 120 tys. sesji/mies.) wdrożenie dojrzałej kultury A/B testingu w Q2 2025. Baseline: testowano 2 hipotezy na miesiąc, decyzje często bez istotności statystycznej.

Przed wdrożeniem

• Próbki testowane: typowo 2 000-5 000 użytkowników na wariant (za mało dla MDE 5%).
• Peeking: codzienny przez marketera, zakończenie testu gdy „wydaje się że już widać różnicę”.
• Decyzje wdrożeniowe: 12 w półroczu, po 3 miesiącach post-verification tylko 4 pokazały trwały efekt (33% truly positive).

Intervention 3 miesięcy

• Miesiąc 1: obowiązkowy kalkulator próbki przed startem. Minimum 15 tys. użytkowników/wariant. SRM check automatyczny.
• Miesiąc 2: zakaz peeking’u. Narzędzie (VWO) z blokadą wczesnego zakończenia. Decyzje po zaplanowanym czasie (zwykle 3-4 tygodnie).
• Miesiąc 3: integracja CRM – analiza downstream quality (MQL rate, LTV) dla każdego wdrożonego wariantu.

Wynik po 6 miesiącach (3 mies. intervention + 3 mies. stabilizacji)

• Liczba testów: 2/mies. → 5/mies. (mimo dłuższego czasu, więcej równolegle).
• Truly positive rate (3 mies. verification): 33% → 68%.
• Roczny ROI z wdrożonych winning variants: +380 tys. zł incremental revenue.
• Koszt intervention: 15 tys. zł (narzędzia) + 60 tys. zł czas data scientist contract (3 mies.) = 75 tys. zł.
• ROI: 5×.

Lessons: (1) dyscyplina statystyczna to nie akademickie ograniczenie, to ekonomia — decyzje na bazie złej statystyki kosztują realnie. (2) Narzędzie (VWO) z blokadą peeking’u zadziałało jak „zewnętrzne sumienie” — usunęło pokusę. (3) Downstream quality analysis (CRM) to differentiator: 2 z naszych wdrożonych winnerów miały lower MQL rate mimo wyższego form_submit CR, po weryfikacji rolled back.

FAQ rozszerzone

Jak uzasadnić inwestycję w platforme A/B testingu dla zarządu?

Trzy argumenty: (1) ROI z jednej pozytywnej optymalizacji (np. +3% CR na checkout z 500 tys. zł miesięcznego przychodu = +15 tys. zł/mies. = 180 tys. zł/rok) zazwyczaj pokrywa 2-5 lat narzędzia. (2) Koszt błędnych decyzji bez testowania — w e-commerce 40-60% „intuicyjnych zmian” okazuje się neutralnych lub negatywnych. Testowanie chroni przed tym. (3) Velocity decyzyjna – dobra platforma z sequential testing daje decyzje w 2-3 tygodni zamiast 6-8, co podwaja tempo optymalizacji rocznie.

Co z AI (Claude, ChatGPT) do analizy wyników A/B?

AI pomaga w trzech sposobach: (1) interpretacja segmentacji – wklej dane test’u z breakdown per segment (device, new/returning, traffic source), Claude identyfikuje nietrywialne patterns (np. „winning variant A wygrywa dla mobile ale przegrywa dla desktop”). (2) Hypothesis generation – Claude z user research notes + current funnel data generuje 20-30 hypothesis do priorytyzacji. (3) Post-test write-up — automatyczne generowanie raportu z wniosków. AI NIE zastępuje data scientist’a w decyzjach statystycznych (czy p-value jest istotne, czy SRM), ale przyspiesza pracę analityczną.

Czy sequential testing jest warte ryzyka?

Dla dużych organizacji – tak, pod warunkiem kompetencji. Sequential testing (SPRT, Alpha Spending) pozwala zakończyć test wcześniej gdy dane są jednoznaczne, oszczędza 30-50% czasu. Ale implementacja wymaga data scientist’a – źle zastosowane sequential methods dają false positive rate 3-5× wyższy niż frequentist. Dla SME bez dedykowanego DS: lepiej zostać przy frequentist z fixed sample size — prościej, bezpieczniej, tylko wolniej.

Co dalej

Statystyka w testach A/B nie jest ozdobą – jest podstawą podejmowania decyzji. Zespół, który uruchamia testy bez kalkulacji próbki, podglada wyniki codziennie i wdraża „intuicyjne zwycięstwa” – traci pieniądze równie pewnie jak zespół, który nie testuje w ogóle. Dobra praktyka to – kalkulator próbki obowiązkowo przed startem, wyniki oglądane po zakończeniu, decyzja bazująca na liczbach zebranych w planie.

Ostatnia uwaga praktyczna – dokumentujcie każdy test. Gdy po 6 miesiącach wraca temat „czy to CTA było pomarańczowe czy niebieskie”, dobra dokumentacja oszczędzi kilku godzin dyskusji. Template dokumentu testu – hipoteza, próbka planowana, czas, wynik (p-value, przedziały), decyzja. Archiwum testów z roku jest kopalnią wiedzy o tym, co działa w waszym produkcie, a co jest zgadywaniem.