Od wyłączenia Google Optimize we wrześniu 2023 roku Google Analytics 4 nie ma własnego narzędzia do testów A/B. GA4 nadal świetnie nadaje się jednak do mierzenia ich wyników, jeśli warianty wyświetla inne narzędzie, a do Analytics trafia informacja, kto zobaczył którą wersję. W tym wpisie pokazuję, jak prowadzę testy A/B w projektach: jakie narzędzie wybieram do podziału ruchu, jak przekazuję dane do GA4, jak liczę potrzebną liczbę użytkowników i czego pilnuję, żeby test nie zaszkodził SEO ani szybkości strony.
Czym podzielić ruch między warianty
GA4 nie pokazuje użytkownikom różnych wersji strony, tylko zbiera dane. Wyświetlaniem wariantów musi zająć się osobne narzędzie lub kod. Wybieram je według wielkości projektu i tego, jak bardzo zależy mi na wydajności:
| Sposób | Przykłady | Kiedy stosuję | Na co uważać |
|---|---|---|---|
| Narzędzie z edytorem wizualnym | VWO, AB Tasty, Optimizely, Convert | zespół marketingu chce testować bez programisty | skrypt w przeglądarce opóźnia wyświetlenie strony i może powodować mignięcie oryginału |
| Flagi funkcji w kodzie | GrowthBook, PostHog, LaunchDarkly | testy funkcji, cen, procesu zakupu, aplikacje | wymaga wdrożenia przez programistę |
| Podział po stronie serwera lub CDN | własny kod, Cloudflare Workers | testy całych szablonów i stron, gdy liczy się szybkość | trzeba samodzielnie zadbać o stałe przypisanie użytkownika do wariantu |
Gdy zależy mi na szybkości, wybieram podział na serwerze lub w CDN. Użytkownik od razu dostaje swój wariant w HTML, bez skryptu, który ukrywa stronę do czasu podmiany treści. To ten sam mechanizm, z którego korzysta Edge SEO, i w praktyce najlżejszy sposób na testy całych szablonów.
Jak przekazuję dane o wariancie do GA4
Większość narzędzi do testów ma gotową integrację z GA4, która wysyła zdarzenie experience_impression z parametrem
exp_variant_string. Przy własnym podziale ruchu wysyłam takie samo zdarzenie przez warstwę danych, w momencie gdy użytkownik
faktycznie zobaczy testowany element:
window.dataLayer = window.dataLayer || [];
window.dataLayer.push({
event: 'experience_impression',
exp_variant_string: 'koszyk-cta-2026-q1-B' // nazwa testu i wariant
});W Google Tag Managerze tworzę tag GA4 Event dla tego zdarzenia z parametrem exp_variant_string, a w GA4 rejestruję ten parametr
jako wymiar niestandardowy o zakresie zdarzenia. Jeśli test trwa dłużej i wariant ma być przypisany do użytkownika we wszystkich sesjach,
dodatkowo zapisuję go jako właściwość użytkownika. Całą komunikację z GTM opieram na warstwie danych, a nie na klikaniu w elementy strony,
zgodnie z zasadami, które stosuję w pracy z Google Tag Managerem.
Analiza wyników w GA4
Wyniki sprawdzam w sekcji Eksploracje. Tworzę segmenty dla każdego wariantu na podstawie wymiaru exp_variant_string i porównuję
w nich główny wskaźnik testu, np. współczynnik konwersji zakupu, a obok wskaźniki pomocnicze, takie jak średnia wartość zamówienia czy liczba
dodań do koszyka. Wskaźniki pomocnicze pilnują, czy zwycięski wariant nie wygrywa kosztem czegoś innego, np. więcej zamówień, ale tańszych.
GA4 nie liczy istotności statystycznej, więc liczby użytkowników i konwersji przenoszę do kalkulatora testów A/B albo, przy większych testach, analizuję dane z eksportu do BigQuery, który nie ma progów danych ani próbkowania obecnych w raportach. Zwycięzcę ogłaszam dopiero wtedy, gdy test osiągnie zaplanowaną liczbę użytkowników, a nie w momencie, gdy wynik zaczyna wyglądać dobrze.
Ilu użytkowników potrzeba
Przed startem testu liczę, ilu użytkowników potrzebuje każdy wariant. Zależy to od obecnego współczynnika konwersji i od tego, jak małą różnicę chcę wykryć. Przykład: przy konwersji 3% i chęci wykrycia poprawy o 20%, czyli do 3,6%, przy standardowych założeniach potrzeba około 14 tysięcy użytkowników na wariant. Przy konwersji 1% ta liczba rośnie kilkukrotnie.
Dlatego przy mniejszych serwisach testuję tylko duże zmiany, takie jak nowy układ strony produktu czy inny proces zamówienia. Zmiana koloru przycisku na stronie z kilkuset konwersjami miesięcznie nie da wiarygodnego wyniku nawet po kilku miesiącach. Test trwa zawsze pełne tygodnie, najczęściej dwa do czterech, żeby objąć dni robocze i weekendy, które w wielu branżach zachowują się zupełnie inaczej.
Testy A/B a SEO i wydajność
- Robot traktowany jak użytkownik. Googlebot może trafić do dowolnego wariantu, ale nie może dostawać specjalnej wersji tylko dlatego, że jest robotem. To byłby cloaking, a granicę między testem a manipulacją dobrze pokazuje dynamic rendering a cloaking.
- Warianty pod osobnymi adresami mają adres kanoniczny wskazujący na stronę oryginalną, a przekierowania do nich są tymczasowe, z kodem 302.
- Test kończy się po zebraniu danych. Zwycięską wersję wdrażam na stałe, a kod testu i warianty usuwam.
- Wydajność. Narzędzia działające w przeglądarce ukrywają stronę do czasu podmiany treści, co potrafi pogorszyć LCP o kilkaset milisekund u wszystkich użytkowników, także tych poza testem. Wpływ skryptu testowego sprawdzam w raporcie Core Web Vitals przed i po jego dodaniu.
Błędy, które unieważniają test
- Zaglądanie do wyników i kończenie testu przy pierwszym dobrym wyniku. Codzienne sprawdzanie i przerwanie testu, gdy wariant „wygrywa”, wielokrotnie zwiększa ryzyko fałszywego zwycięzcy.
- Nierówny podział ruchu. Jeśli przy podziale 50/50 jeden wariant ma wyraźnie więcej użytkowników, coś jest nie tak z wdrożeniem, np. wariant B częściej się nie ładuje. Taki test powtarzam po poprawce.
- Brak zgód na cookies. Użytkownicy, którzy nie zgodzili się na analitykę, nie trafiają do GA4 w pełnej postaci. Jeśli jeden wariant zmienia baner zgód lub jego otoczenie, różnica w danych może wynikać ze zgód, a nie z samego wariantu.
- Zbyt wiele wariantów naraz. Każdy dodatkowy wariant dzieli ruch i wydłuża test. Przy umiarkowanym ruchu testuję jeden wariant przeciwko oryginałowi.
- Brak hipotezy. Przed testem zapisuję, co zmieniam, dlaczego i jakiego efektu oczekuję. Pomysły na testy biorę z danych i badań z użytkownikami, które są częścią tego, jak wygląda proces projektowania UX, a nie z listy „sprawdzonych trików”.