12 błędów w testach A/B, przez które wyniki są fałszywe

Błędy w projekcie testu

Błędy projektowe pojawiają się, zanim test wystartuje, i żadna analiza ich później nie naprawi. Dotyczą hipotezy, metryki i wielkości próby.

1. Brak hipotezy i jednej metryki głównej

Test bez spisanej hipotezy („zmiana X zwiększy Y, bo Z”) i bez jednej metryki głównej kończy się wyborem tej metryki, która akurat wyszła najlepiej. Przed startem zapisz metrykę główną (np. odsetek użytkowników z zakupem), 2–3 metryki ochronne (marża, zwroty, przychód na użytkownika) i regułę decyzji. Bez tego każdy wynik da się zinterpretować jako sukces.

2. Za mała próba i zbyt mała moc

Test, który przy Twoim ruchu może wykryć tylko poprawę o 40%, prawie zawsze skończy się wynikiem nieistotnym albo przypadkowym zwycięzcą. Przy konwersji 2% wykrycie poprawy o 10% wymaga ok. 80 700 użytkowników na wariant przy istotności 5% i mocy 80%. Policz próbę przed startem – wzór, tabelę i kod znajdziesz w artykule o wielkości próby i istotności statystycznej.

3. Zbyt wiele wariantów i metryk bez korekty

Przy poziomie istotności 5% i dwudziestu porównaniach (np. 4 warianty × 5 metryk) spodziewasz się średnio jednego „istotnego” wyniku, nawet jeśli żadna zmiana nie działa. Ogranicz liczbę wariantów, ustal jedną metrykę główną i stosuj korektę na wielokrotne porównania, np. Bonferroniego, która dzieli poziom α przez liczbę porównań.

Błędy w losowaniu i przydziale wariantów

Losowanie ma zapewnić, że grupy różnią się tylko testowaną zmianą. Jeśli przydział jest wadliwy, porównujesz różne populacje, a nie warianty.

4. Losowanie na poziomie sesji zamiast użytkownika

Jeśli ta sama osoba w poniedziałek widzi wariant A, a w środę B, nie da się ustalić, który z nich doprowadził do zakupu. Losuj na poziomie użytkownika i utrzymuj przydział przez cały test. Analizę też prowadź per użytkownik, a nie per sesję – inaczej obserwacje nie są niezależne, a przedziały ufności wychodzą zbyt wąskie.

5. Niezrównoważony podział ruchu (SRM)

SRM (sample ratio mismatch) to sytuacja, w której proporcja użytkowników w grupach istotnie odbiega od założonej. Przyczyny to m.in. przekierowanie w jednym wariancie, które gubi część osób, tag uruchamiany tylko w jednej wersji, pamięć podręczna strony albo boty. Sprawdzisz to testem chi-kwadrat:

from statistics import NormalDist

def test_srm(n_a, n_b, udzial_a=0.5):
    n = n_a + n_b
    oczek_a, oczek_b = n * udzial_a, n * (1 - udzial_a)
    chi2 = (n_a - oczek_a) ** 2 / oczek_a + (n_b - oczek_b) ** 2 / oczek_b
    p = 2 * (1 - NormalDist().cdf(chi2 ** 0.5))   # chi-kwadrat z 1 stopniem swobody
    return chi2, p

print(test_srm(50600, 49400))   # chi2 = 14,4, p ≈ 0,00015

Liczbę użytkowników w wariantach pobierzesz z eksportu GA4:

SELECT
  (SELECT value.string_value FROM UNNEST(event_params) WHERE key = 'variant_id') AS wariant,
  COUNT(DISTINCT user_pseudo_id) AS uzytkownicy
FROM `twoj-projekt.analytics_123456789.events_*`
WHERE _TABLE_SUFFIX BETWEEN '20261001' AND '20261028'
  AND event_name = 'experiment_impression'
  AND (SELECT value.string_value FROM UNNEST(event_params)
       WHERE key = 'experiment_id') = 'karta_produktu_cta_2026_10'
GROUP BY wariant;

W praktyce alarm ustawia się przy p < 0,001, żeby ograniczyć fałszywe alarmy. Test z SRM nie nadaje się do oceny – znajdź przyczynę, popraw wdrożenie i zacznij od nowa. Jak przekazywać warianty do GA4, opisujemy w tekście o testach A/B w GA4.

6. Zanieczyszczenie grup: wiele urządzeń i równoległe testy

Użytkownik, który przegląda sklep na telefonie, a kupuje na komputerze, może trafić do obu wariantów. Przy zalogowanych klientach przydzielaj wariant według identyfikatora konta, a w analizie pomijaj osoby, które widziały obie wersje. Drugi problem to równoległe testy na tych samych elementach – zmiana w koszyku i zmiana w karcie produktu mogą się wzajemnie wzmacniać lub znosić. Prowadź rejestr testów i nie uruchamiaj nakładających się eksperymentów bez planu ich rozdzielenia.

Błędy techniczne i pomiarowe

Te błędy sprawiają, że warianty różnią się czymś więcej niż testowaną zmianą albo że pomiar w jednej grupie działa gorzej niż w drugiej.

7. Migotanie i różnice w szybkości ładowania

W testach po stronie przeglądarki wariant może pojawiać się z opóźnieniem, a skrypt ukrywający stronę do czasu zastosowania zmian spowalnia wyświetlenie treści. Testy z przekierowaniem dodają kolejne opóźnienie. Jeśli wariant B ładuje się wolniej, test mierzy efekt szybkości, a nie treści. Porównaj metryki wydajności dla obu wariantów; jak to zrobić, opisujemy w tekście o tagach a Core Web Vitals.

8. Nierówna utrata danych przez zgody i blokery

Jeśli wariant zmienia układ strony tak, że baner zgód jest mniej lub bardziej widoczny, odsetek zgód w grupach się różni, a GA4 widzi inną część każdej grupy. Podobnie działa blokowanie skryptów: użytkownik z blokerem może widzieć wersję kontrolną, ale nie trafić do pomiaru. Porównaj odsetek zgód między wariantami i, jeśli to możliwe, oceniaj test na danych z systemu sprzedaży. Jak Consent Mode wpływa na dane, wyjaśniamy w porównaniu trybu podstawowego i zaawansowanego.

9. Boty, ruch wewnętrzny i duplikaty transakcji

Boty i ruch pracowników zwiększają liczbę użytkowników bez zakupów, a jeśli rozkładają się nierówno, mogą wywołać SRM. Wykluczaj ruch wewnętrzny i testowy, a anomalie, takie jak skoki odsłon z jednego źródła, sprawdzaj metodami opisanymi w tekście o ad fraudzie i botach. Zduplikowane zdarzenia zakupu potrafią sztucznie podnieść konwersję jednego wariantu – usuń je według identyfikatora transakcji, jak pokazujemy w artykule o duplikatach transakcji w GA4.

Błędy związane z czasem trwania testu

Czas trwania decyduje o tym, czy próba jest reprezentatywna. Za krótki test łapie przypadek, a źle ułożony w kalendarzu – nietypowe zachowania.

10. Podglądanie wyników i wcześniejsze zakończenie

Wartość p w trakcie testu naturalnie się waha. Jeśli sprawdzasz ją codziennie i kończysz test przy pierwszym wyniku poniżej 0,05, realne ryzyko fałszywego zwycięzcy jest dużo wyższe niż 5%. Ustal datę zakończenia przed startem albo korzystaj z narzędzia stosującego metody sekwencyjne, które dopuszczają wielokrotną ocenę. Wcześniej wolno sprawdzać tylko poprawność techniczną, np. SRM.

11. Efekt nowości, sezonowość i niepełne tygodnie

Powracający użytkownicy często reagują na samą zmianę: klikają nowy element z ciekawości, a po kilku tygodniach efekt słabnie. Bywa też odwrotnie – stali klienci potrzebują czasu, żeby przyzwyczaić się do nowego układu. Analizuj wynik osobno dla nowych i powracających użytkowników oraz w kolejnych tygodniach testu. Planuj pełne tygodnie i unikaj okresów takich jak Black Friday, chyba że test dotyczy właśnie ich.

Błędy w interpretacji wyników

Nawet poprawnie przeprowadzony test można źle odczytać. Najczęstszy błąd interpretacyjny łączy dwa zjawiska: szukanie wyniku w segmentach i przecenianie zwycięzcy.

12. Szukanie zwycięzcy w segmentach i przecenianie efektu

Gdy test ogólnie nie wyszedł, kusi sprawdzenie urządzeń, źródeł ruchu, województw i nowych klientów. Przy kilkunastu segmentach któryś prawie na pewno pokaże „istotną” poprawę przez przypadek. Segmenty analizuj tylko wtedy, gdy zaplanowałeś to przed startem, a odkrycia z analizy po fakcie traktuj jako hipotezę do kolejnego testu.

Drugie zjawisko to tzw. klątwa zwycięzcy: wyniki, które przekroczyły próg istotności, zwykle przeszacowują prawdziwy efekt, szczególnie w testach o małej mocy. Jeśli test pokazał poprawę o 18%, po wdrożeniu spodziewaj się mniejszej. Dobrą praktyką jest pozostawienie niewielkiej grupy kontrolnej po wdrożeniu, która pokaże efekt w dłuższym okresie. Zasady takich pomiarów opisujemy w tekście o testach inkrementalności.

Jak wyłapać błędy w testach A/B: objawy i lista kontrolna

Większość opisanych błędów zostawia ślady w danych. Poniższa tabela pomaga je rozpoznać.

Do każdego testu stosuj tę samą procedurę kontrolną:

1. Przed startem spisz hipotezę, metrykę główną, metryki ochronne, wielkość próby i datę zakończenia.
2. Uruchom test A/A przy nowym narzędziu lub nowym typie wdrożenia, żeby sprawdzić równowagę podziału.
3. W pierwszych dniach sprawdź SRM, poprawność zdarzeń i wydajność wariantów – bez oceny wyniku.
4. Po zakończeniu usuń boty, ruch wewnętrzny i duplikaty, a potem policz wynik dla metryki głównej.
5. Przed ogłoszeniem porównaj wynik z danymi z systemu sprzedaży i z metrykami ochronnymi.
6. Po wdrożeniu obserwuj efekt przez kilka tygodni lub utrzymaj małą grupę kontrolną.

Wybierając narzędzie, sprawdź, które z tych kontroli wykonuje automatycznie – porównanie znajdziesz w artykule o narzędziach do testów A/B. Te same zasady dotyczą testów kampanii w platformach, opisanych w poradniku o eksperymentach w Google Ads i Meta Ads. Pozostałe materiały znajdziesz w dziale Testy A/B.