Testy A/B w ecommerce: jak testować, żeby uzyskać wiarygodne wyniki #133

Czym są testy A/B i na czym polegają

Testy A/B to metoda badawcza, w której dwie różne wersje tego samego elementu strony internetowej pokazujesz jednocześnie dwóm losowo podzielonym grupom użytkowników. Wersja A to najczęściej stan obecny (kontrolna), wersja B – wariant, który chcesz sprawdzić. Ruch dzieli się zwykle po 50%, a system analityczny mierzy, która wersja lepiej realizuje wcześniej zdefiniowany cel.

Kluczowe słowo to jednocześnie. To odróżnia testy A/B od testów porównawczych typu „przed i po”, w których zestawiasz wyniki z dwóch różnych okresów. W tym drugim przypadku na uzyskane wyniki wpływa sezonowość, kampanie reklamowe, zmiany w źródłach ruchu i dziesiątki innych czynników, których nie kontrolujesz. Test A/B eliminuje ten problem, bo obie grupy działają w tych samych warunkach.

Prawdziwa definicja jest jednak szersza niż mechanika. Test A/B to sposób sprawdzenia decyzji projektowej i biznesowej, zanim zostanie wdrożona. Nie pytamy więc, czy przycisk ma być czerwony czy zielony, tylko czy to jest właściwy komunikat, we właściwym miejscu i we właściwym momencie.

I tu leży najczęstsze nieporozumienie. Testy A/B kojarzą się z banałem: zmieńmy kolor przycisku, przesuńmy coś w lewo, zobaczmy, czy ktoś kliknie. To najwęższe możliwe rozumienie tematu. Problem z mikrooptymalizacją kolorów polega na tym, że nawet jeśli wygrasz, nie dowiesz się dlaczego, a bez odpowiedzi na „dlaczego” nie masz czego zastosować w kolejnym miejscu sklepu.

Zamiast pytać, czy zielony przycisk generuje większą liczbę kliknięć, zapytaj: czy użytkownik w tym momencie ścieżki ma wszystkie informacje, żeby podjąć decyzję? Czy komunikat odpowiada na jego realną obawę? Czy element strony jest w miejscu, w którym go szuka?

Dobrze oddaje to metafora jednorożca i osła. Jednorożce to rozwiązania efektowne, modne, dobrze wyglądające w prezentacji dla zarządu. Osły są przyziemne, brzydsze, mniej ambitne za to działające:

„Często w projektowaniu ecommerce kuszą nas rozwiązania, które brzmią świetnie i wyglądają świetnie. Problem w tym, że to jeszcze nie znaczy, że działają lepiej. Jeśli daje to lepszy wynik, no to wtedy osioł jest naszym jednorożcem.”

Testy A/B pozwalają sprawdzić, którym z tych zwierząt jest nowy pomysł zanim zostanie wdrożona wersja produkcyjna.

Trzy case studies, które uczą pokory

Pole na kod rabatowy, które obniżyło przychód o 6,5%. Klasyczne badanie z 2011 roku. Sklep dodał w podsumowaniu zamówienia pole na kod promocyjny — funkcję uważaną za oczywisty standard. Wersja bez tego pola wypadła o 6,5% lepiej w przejściu do checkoutu. Mechanizm okazał się czysto psychologiczny: widok pola „wpisz kod rabatowy” uruchamiał myśl „skoro istnieje kod, to teraz płacę za dużo”. Użytkownicy opuszczali koszyk, żeby poszukać kodu w wyszukiwarce — i znaczna część z nich nigdy nie wracała.

Wniosek praktyczny: zanim skopiujesz funkcję od konkurencji, sprawdź ją u siebie. W sklepach B2B, gdzie ceny są indywidualne i negocjowane, ryzyko takiego efektu bywa jeszcze wyższe.

Mniejszy przycisk „Dodaj do koszyka”, który podniósł konwersję. Testowano dwie wersje karty produktu. Wersja A: ogromny, dominujący przycisk. Wersja B: mniejszy przycisk, ale nad nim wyeksponowane informacje o dostawie, metodach płatności i zasadach zwrotu. Wygrała wersja B, użytkownicy konwertowali się lepiej, bo mogli bardziej zaufać sklepowi.

Wniosek praktyczny: klienci nie kupują dlatego, że przycisk jest duży. Kupują, kiedy przestają się bać. Usunięcie wątpliwości działa mocniej niż agresywne CTA.

Amazon 2006: rekomendacje, które zarząd chciał zablokować. Dział UX zaproponował dodanie do koszyka sekcji „użytkownicy, którzy kupili to, kupili także“. Zarząd był przeciwny. Koszyk miał zawierać wyłącznie podsumowanie i przejście do płatności, bez rozpraszaczy. Test rozstrzygnął spór bezlitośnie: wersja z rekomendacjami przyniosła na start ok. 3% wzrostu przychodu i rosła dalej. Dziś to standard branżowy.

Wniosek praktyczny: największa wartość testów A/B nie polega na dopieszczaniu detali. Polega na tym, że dają zespołowi argument silniejszy niż hierarchia w firmie.

Co testować i jak zbudować hipotezę

Jeśli nie wiesz, od czego zacząć, użyj czterech obszarów jako filtra. To one najczęściej dają najlepsze rezultaty:

• Eliminowanie błędów i wahań użytkownika – trudne formularze, niejasne komunikaty walidacji, zbyt wiele pól wymaganych. Niski wskaźnik wypełnienia formularza rejestracji B2B to pierwsze miejsce, które możesz przetestować.
• Budowanie pewności zakupowej – informacje o dostawie, zwrotach, dostępności towaru, warunkach płatności odroczonej.
• Skracanie ścieżki do zakupu – uproszczenie koszyka, nawigacji, checkoutu. W B2B: szybkie zamawianie z pliku, listy zakupowe, historia zamówień jako punkt startowy.
• Walidacja skarg od klientów – jeśli obsługa trzy razy w tygodniu słyszy to samo pytanie, masz gotową hipotezę.

Warto też patrzeć na miejsca, gdzie analityka pokazuje wysoki współczynnik odrzuceń albo wyraźne drop-offy w lejku. Wysoki współczynnik odrzuceń na kluczowej kategorii to sygnał, nie diagnoza — ale dobry punkt startu.

Zanim rozpoczniesz test, spisz hipotezę. Nie „sprawdźmy, czy będzie lepiej”, tylko konkret zawierający trzy elementy: co zmieniamy (jeden element strony), na co ma to wpłynąć (metryka główna) i na co ma to nie wpłynąć negatywnie. Przykład: przeniesienie informacji o darmowej dostawie nad przycisk dodania do koszyka zwiększy współczynnik dodań o min. 5%, nie obniżając średniej wartości zamówienia.

Nie każdą hipotezę warto testować — i to jest w porządku. Całą listę warto przepuścić przez potrójny filtr:

Chodzi o zbieranie niskowiszących owoców. Kolejność ma też znaczenie w skali: idź od ogółu do szczegółu – najpierw sprawdź duży układ (nowy szablon kategorii vs stary), a dopiero potem optymalizuj poszczególne elementy w zwycięskiej wersji.

Sześć kroków poprawnego testu A/B

Cały proces składa się z sześciu etapów. Pominięcie któregokolwiek zwykle kończy się wynikiem, któremu nie można ufać.

1. Wybierz jedną zmianę. Jedna zmiana, jeden test. Nie pięć elementów naraz, nie cały redesign. Jeśli zmienisz kilka konkretnych elementów jednocześnie, wynik może być pozytywny – ale nie będziesz wiedzieć, co go wywołało.
2. Ustal, co mierzysz. Metryka musi być blisko testowanej zmiany. Zmieniasz kartę produktu – mierzysz dodania do koszyka. Zmieniasz koszyk – mierzysz przejście do płatności. Mierzenie ogólnego współczynnika konwersji sklepu przy zmianie jednego elementu to prosta droga do wyniku, którego nie da się zinterpretować.
3. Daj testowi czas. Minimum jeden pełny tydzień i zebranie zaplanowanej wielkości próby. Oba warunki muszą być spełnione jednocześnie.
4. Wdróż test poprawnie. To etap, który najłatwiej zlekceważyć i który najczęściej niszczy wiarygodność wyników. Sprawdź obie wersje na urządzeniach mobilnych, w różnych przeglądarkach, przy wolnym łączu. Jeśli w wersji B przycisk znika na iPhonie, nie testujesz hipotezy – testujesz błąd frontendowy. Zwróć uwagę na flicker: jeśli narzędzie podmienia treść po załadowaniu strony w przeglądarce, część użytkowników zobaczy przez moment wersję A.
5. Pilnuj jakości danych. W trakcie trwania testu monitorujesz wyłącznie higienę danych: czy ruch dzieli się równo, czy zdarzenia zapisują się poprawnie, czy nie ma anomalii w źródłach ruchu. Nie patrzysz, kto wygrywa. Podglądanie wyników w czasie rzeczywistym to nie ciekawość, tylko statystyczny problem – im częściej patrzysz i im wcześniej reagujesz, tym większa szansa, że zamkniesz test na przypadkowym szczycie.
6. Podejmij decyzję biznesową. Ostatni krok to nie „która wersja wygrała”, tylko „czy ta wygrana ma sens”. Wzrost o 1,5% na mikroelemencie, który wymaga trzech tygodni pracy developerskiej i utrudnia przyszłe utrzymanie sklepu, może być decyzją nieopłacalną – nawet jeśli wynik jest istotny statystycznie.

Czas trwania, wielkość próby i istotność statystyczna

Minimum to jeden pełny cykl tygodniowy, a w praktyce lepiej dwa tygodnie lub miesiąc. Powód jest prosty: zachowania użytkowników zmieniają się w zależności od dnia tygodnia. W B2B poniedziałkowy ruch z działów zakupów wygląda zupełnie inaczej niż piątkowe popołudnie. Test zakończony w środę po trzech dniach mierzy dzień tygodnia, nie zmianę.

Drugi warunek to zebranie zaplanowanej próby. Wylicz ją przed startem, korzystając z kalkulatora (np. Optimizely Sample Size Calculator). Potrzebujesz trzech danych: obecnego współczynnika konwersji, poziomu istotności statystycznej (standardowo 95%) oraz MDE.

Minimal detectable effect (MDE) to najmniejsza różnica, jaką chcesz umieć wykryć – najważniejszy i najczęściej pomijany parametr. Im mniejszą zmianę chcesz wychwycić, tym większa próba jest potrzebna. Wykrycie różnicy 1% wymaga wielokrotnie większego ruchu niż wykrycie różnicy 15% i to właśnie tu rozbijają się plany testowe mniejszych sklepów.

Wynik uznajemy za wiarygodny, gdy jest statystycznie istotny – czyli gdy prawdopodobieństwo, że różnica wynika z przypadku, jest odpowiednio niskie. Bez osiągnięcia statystycznej istotności różnica między wersją A a wersją B jest szumem, nawet jeśli wygląda przekonująco na wykresie.

A co, gdy wynik jest na granicy? To nie wyjątek, tylko norma, dotyczy nawet 80% realnych testów A/B. Kolejność działań: najpierw przedłuż test, jeśli masz taką możliwość. Jeśli po przedłużeniu nadal nie ma rozstrzygnięcia, albo odpuszczasz wdrożenie zmian (skoro nie widać różnicy, prawdopodobnie jej nie ma), albo modyfikujesz rozwiązanie i łączysz je z inną hipotezą, tworząc kolejny test A/B z mocniejszym wariantem.

Czego nie robić: nie przedłużaj testu w nieskończoność, czekając aż „w końcu wyjdzie”. To już nie jest badanie, tylko szukanie potwierdzenia z góry przyjętej tezy.

Metryka główna a metryki pomocnicze

Do ecommerce trzeba podchodzić holistycznie. Optymalizacja konwersji w jednym miejscu bardzo łatwo psuje coś w innym, dlatego zawsze patrzymy na oba poziomy: metryka główna jest najważniejsza, ale obok niej obserwujemy wskaźniki pomocnicze.

Zestaw minimum:

• AOV (średnia wartość zamówienia)-czy uproszczenie koszyka nie zabiło cross-sellingu?
• CTR na kluczowych elementach ścieżki
• Drop-offy w poszczególnych krokach checkoutu
• Współczynnik odrzuceń na zmienionych podstronach
• Czas spędzony na stronie i głębokość sesji
• Liczba kliknięć w elementy poboczne (nawigacja, filtry, wyszukiwarka)

Klasyczna pułapka: agresywne uproszczenie koszyka podnosi współczynnik konwersji o 4%, ale obniża AOV o 9%. Netto tracisz. Bez metryk pomocniczych nigdy byś tego nie zobaczył.

Narzędzia do testów A/B i analityki

Do wdrażania testów:

Warto pamiętać, że Google Optimize przez lata domyślne darmowe narzędzie do testów A/B – został wyłączony. Jeśli natrafisz na starszy poradnik oparty na Optimize, jest nieaktualny.

Po stronie analityki: Google Analytics 4 do twardych danych ilościowych i cykliczności tygodniowej, Adobe Analytics jako alternatywa enterprise przy złożonej segmentacji, Amplitude do analityki produktowej i lejków, a do warstwy jakościowej Microsoft Clarity(darmowe heatmapy i nagrania sesji) oraz Hotjar. Te dwa ostatnie są niezwykle przydatne z jednego powodu: liczby mówią Ci, że wersja B wygrała, a nagrania sesji pokazują dlaczego. Bez tej drugiej warstwy trudno przenieść wniosek na inne obszary sklepu.

Zostaje dokumentacja: Notion, Confluence albo zwykły arkusz Google. Ważne, żeby istniało jedno miejsce z historią: hipoteza, daty, wielkość próby, wynik, wpływ na metryki pomocnicze, decyzja. Bez tego testy A/B będą tylko chwilowymi sprawdzeniami, do których nie da się wrócić. Brzmi jak biurokracja, dopóki nie zmieni się osoba odpowiedzialna za ecommerce w firmie i nowy zespół nie zacznie testować od zera rzeczy sprawdzonych dwa lata wcześniej.

Testy A/B przy małym ruchu

To pytanie pada na każdym szkoleniu: mam kilkaset zamówień miesięcznie, czy testy A/B mają u mnie sens? Klasyczne mikrotesty nie mają. Dla firm z obrotem do ok. 10 mln zł rocznie testowanie koloru przycisku czy tekstu na CTA zupełnie się nie spina.

Przy ruchu poniżej ok. 50 tysięcy wizyt miesięcznie zebranie próby wystarczającej do wykrycia różnicy 2–3% zajęłoby wiele miesięcy. W tym czasie zmieni się sezon, asortyment i struktura źródeł ruchu, a test przestanie być czysty.

Rozwiązaniem są tzw. testy grube (quasi-testy). Zamiast jednego elementu testujesz całe rozwiązania:

• kompletnie nowy layout koszyka vs obecny,
• nowy szablon karty produktu vs stary,
• nowa wersja kluczowej podstrony kategorii,
• dwa różne modele procesu składania zamówienia w B2B (klasyczny koszyk vs szybkie zamawianie z listy).

Logika jest prosta: skoro nie możesz zwiększyć próby, musisz zwiększyć MDE. Duża zmiana adresuje wiele potrzeb użytkownika naraz i ma szansę wygenerować efekt na tyle wyraźny, że będzie widoczny nawet przy skromnym ruchu.

Cena tego podejścia: tracisz precyzję. Nie dowiesz się, który z pięciu elementów nowego layoutu zadziałał. Przy małym ruchu to akceptowalny kompromis, lepiej wiedzieć, że nowy koszyk działa lepiej, niż nie wiedzieć nic. Uzupełnieniem są metody jakościowe: nagrania sesji, heatmapy, wywiady z klientami, analiza zgłoszeń do obsługi. Nie dają statystycznej pewności, ale generują hipotezy o dużym potencjale.

Najczęstsze błędy

Optymizm we wstępnych wynikach. Najpopularniejszy błąd na świecie. Po trzech dniach wersja B prowadzi o 12%, więc zamykamy test i wdrażamy. Po miesiącu okazuje się, że wzrostu nie ma. To były wahania ruchu, nie efekt zmiany.

Testowanie wielu zmian naraz. Wynik pozytywny, ale bez wiedzy o przyczynie. Zero nauki na przyszłość.

Mieszanie kilku eksperymentów w tym samym miejscu. Dwa niezależne testy na tej samej ścieżce dla tej samej grupy użytkowników to gwarantowany chaos analityczny.

Zaniedbania techniczne we wdrożeniu. Wersja B psuje się na urządzeniach mobilnych, przycisk znika przy wąskim viewporcie, event nie odpala się w Safari. Uzyskane wyniki mierzą wtedy błąd, nie hipotezę.

Brak zdefiniowanego celu przed rozpoczęciem testu. Jeśli nie wiesz, co dokładnie chcesz sprawdzić, po zakończeniu testu znajdziesz w danych to, co chcesz znaleźć.

Brak dokumentacji. Wiedza zostaje w głowie jednej osoby i znika razem z nią.

Traktowanie wygranej jako automatycznego wdrożenia. Wynik istotny statystycznie to jeszcze nie decyzja biznesowa.

Osobna uwaga o testach wielowymiarowych (MVT). Pozwalają badać kilka zmiennych o wielu cechach jednocześnie i sprawdzać ich kombinacje, ale wymagają ruchu o rząd wielkości większego niż zwykły test A/B – każda kombinacja to osobna grupa, która musi zebrać własną próbę. Dla większości polskich sklepów, także w segmencie B2B, sekwencja pojedynczych testów A/B jest szybsza, tańsza i daje czystsze wnioski. Warto też pamiętać, że testy A/B nie kończą się na stronie: tematy wiadomości e-mail, kreacje reklamowe i oferty w kampaniach rządzą się tą samą metodyką, a próbę często łatwiej tam zebrać.

FAQ

Ile powinien trwać test A/B?
Minimum jeden pełny tydzień, żeby objąć cały cykl tygodniowy zachowań użytkowników. W praktyce zwykle 2–4 tygodnie. Test kończysz dopiero wtedy, gdy jednocześnie minął zaplanowany czas i zebrałeś wyliczoną wielkość próby.

Jaki ruch jest potrzebny, żeby uruchomić test A/B?
Nie ma jednej liczby – zależy od obecnego współczynnika konwersji i MDE. Przy ruchu poniżej ok. 50 tys. wizyt miesięcznie zrezygnuj z mikrotestów i przejdź na testy grube.

Czy mogę testować kilka rzeczy jednocześnie?
Tak, ale w różnych, niezależnych obszarach sklepu i dla rozdzielnych grup. Nigdy dwóch testów na tej samej ścieżce dla tych samych użytkowników.

Co zrobić, gdy wynik nie jest istotny statystycznie?
Przedłuż test. Jeśli to nie pomoże, odpuść wdrożenie albo wzmocnij wariant B i zaplanuj kolejny test z większą różnicą między wersjami.

Czy testy A/B mają sens w B2B?
Tak, ale metodyka wygląda inaczej. Ruch jest mniejszy, za to wartość pojedynczej konwersji dużo wyższa, a użytkownicy wracający. Testuj duże zmiany w procesie zamawiania, panelu klienta i ścieżce rejestracji, a wyniki uzupełniaj rozmowami z realnymi kupcami.

Podsumowanie: ciągłe testowanie zamiast jednorazowej akcji

Testy A/B nie są projektem, który się kończy. To sposób pracy: zbierasz hipotezy, priorytetyzujesz, testujesz, dokumentujesz, wracasz do listy. Amazon utrzymuje w gruncie rzeczy ten sam interfejs od dwóch dekad, cały czas testując szczegóły i to jest właściwy model, nie kolejny redesign co trzy lata.

Najważniejsza lekcja nie jest jednak metodyczna:

„Ta lekcja jest o pokorze. Brakuje nam tutaj zazwyczaj pokory wobec tego, jak często użytkownik i biznes reagują inaczej, niż zakładaliśmy.”

Jeśli chcesz sprawdzić, gdzie w Twoim sklepie PrestaShop leżą niskowiszące owoce, od czego zacząć testowanie i które hipotezy mają największy potencjał – porozmawiajmy o audycie UX i optymalizacji konwersji. Zaczynamy od danych, nie od opinii.