Modelowane listy odbiorców nie zawierają konkretnych osób, tylko prawdopodobieństwa. Wyjaśniam, jak powstają, gdzie ich szukać w panelu i jak czytać ich raporty.
Rozmowa o stronie docelowej kończy się zwykle w tym samym miejscu: klient uważa, że nagłówek jest dobry, ja uważam, że formularz jest za długi, a agencja graficzna uważa, że oba jesteśmy w błędzie. Nikt z nas nie ma danych, więc wygrywa osoba, która mówi pewniej.
Testy A/B są jedynym sposobem, żeby wyjść z tej pętli. I dobra wiadomość jest taka, że nie trzeba do tego płatnego narzędzia — Google Optimize w darmowej wersji obsługuje wszystko, czego potrzebuje typowy landing page kampanii Google Ads.
Zła wiadomość jest taka, że narzędzie jest łatwe, a metodologia nie. Widzę więcej testów zakończonych fałszywym wnioskiem niż testów w ogóle nieprzeprowadzonych. Poniżej opisuję, jak podchodzę do tego u siebie: co wdrożyć, jak zaplanować test, ile go trzymać i jak odczytać wynik, żeby nie oszukać samego siebie.
Optimize działa po stronie przeglądarki. Wgrywasz na stronę fragment kodu, a narzędzie podmienia elementy według reguł, które ustawiłeś w panelu. Z tego wynikają zarówno jego mocne strony, jak i granice.
Nadaje się świetnie do zmian warstwy prezentacji: innego nagłówka, innego tekstu na przycisku, przestawienia kolejności sekcji, ukrycia elementu, innego zdjęcia, innej kolejności pól w formularzu. Wszystko to zrobisz w edytorze wizualnym, bez angażowania programisty.
Nie nadaje się do zmian, które wymagają pracy po stronie serwera — innego mechanizmu koszyka, innej logiki cennika, innego procesu zamówienia. Dla tego typu różnic Optimize ma test z przekierowaniem, w którym po prostu wysyłasz część ruchu na inny adres. To rozwiązanie działa, ale wymaga dwóch osobno przygotowanych stron.
Warto znać limity darmowej wersji, bo dla części projektów są wiążące. Możesz prowadzić jednocześnie pięć eksperymentów, a test wielowymiarowy obsługuje do 16 kombinacji. Kierowanie na odbiorców z Analytics jest zarezerwowane dla wersji płatnej. Przy jednym landing page’u kampanii to nie ma znaczenia, przy dużym sklepie testującym równolegle kilka szablonów już tak.
Tu robi się najwięcej błędów, bo krok jest techniczny i łatwo go odbębnić.
Po pierwsze, powiązanie z Analytics. Optimize korzysta z danych Analytics do liczenia celów i bez tego powiązania nie ruszysz. Narzędzie łączy się zarówno z usługą Universal Analytics, jak i z usługą Google Analytics 4 — a skoro w marcu Google ogłosił termin wyłączenia Universal Analytics, przy nowych wdrożeniach warto od razu myśleć o tym, że pomiar będzie żył w GA4.
Po drugie, kod Optimize na stronie. Można go wdrożyć bezpośrednio albo przez Google Tag Managera. Ważne, żeby ładował się możliwie wcześnie i synchronicznie, bo inaczej użytkownik zobaczy najpierw wersję oryginalną, a chwilę później podmienioną.
Po trzecie właśnie to: fragment przeciw migotaniu. To krótki kod, który na moment ukrywa stronę, dopóki Optimize nie zdecyduje, którą wersję pokazać. Bez niego dostajesz efekt mrugnięcia, który nie tylko wygląda źle, ale realnie zaburza wynik testu — część użytkowników zobaczy obie wersje naraz.
Po czwarte, rozszerzenie do przeglądarki, bez którego edytor wizualny nie działa. Drobiazg, ale zaskakuje przy pierwszym uruchomieniu.
Na koniec sprawdzam wszystko w trybie podglądu, na komputerze i na telefonie. Podmieniony nagłówek, który na telefonie rozjeżdża layout, to nie test hipotezy, to test cierpliwości użytkownika.
Test bez hipotezy nie jest testem, tylko zmianą z pomiarem.
Hipotezę zapisuję w jednym zdaniu, w formie: zmieniam to, ponieważ sądzę, że dzieje się tamto, i oczekuję poprawy tego konkretnego wskaźnika. Przykład z mojej pracy: skracam formularz z siedmiu pól do trzech, ponieważ z nagrań sesji widzę porzucenia przy polu z adresem, i oczekuję wzrostu liczby wysłanych formularzy.
Zapisana hipoteza pilnuje trzech rzeczy naraz. Zmusza do wskazania jednego wskaźnika sukcesu, więc nie będzie potem szukania w danych czegokolwiek, co wyszło korzystnie. Ogranicza liczbę zmian w wariancie, bo przy pięciu zmianach naraz nie dowiesz się, która zadziałała. I wymusza uzasadnienie oparte na czymś — nagraniach, danych z Analytics, raporcie wyszukiwanych haseł, rozmowach z obsługą klienta — a nie na przeczuciu.
Kolejność testów też ma znaczenie. Zaczynam od elementów, które widzi każdy użytkownik i które są najbliżej decyzji: nagłówka, pierwszego ekranu, formularza, wezwania do działania. Kolor przycisku w stopce zostawiam na moment, w którym skończą mi się ważniejsze pomysły.
Optimize mierzy cele pobrane z Analytics — cele z Universal Analytics albo zdarzenia i konwersje z GA4. Wybór celu jest ważniejszy niż sam wariant.
Najczęstszy błąd to cel zbyt oddalony od testowanej zmiany. Jeśli testujesz nagłówek na górze strony, a jako cel ustawiasz zakup, to na wyniku będzie się odkładał cały proces zamówienia, płatność, dostępność i wszystko po drodze. Nagłówek to mały ułamek tej ścieżki i utonie w szumie.
Drugi najczęstszy błąd to odwrotność: cel tak bliski, że nic nie znaczy. Kliknięcie przycisku „kup” nie jest konwersją, jeśli połowa tych kliknięć nie kończy się zamówieniem.
Ja ustawiam jeden cel główny — najbliższą sensowną akcję po testowanej zmianie — i dwa cele dodatkowe, tylko do obserwacji. Cele dodatkowe służą do wychwycenia szkody poza obszarem testu. Skrócony formularz, który podniósł liczbę zgłoszeń i jednocześnie obniżył ich jakość, to nie sukces, tylko przesunięcie problemu do działu handlowego. Optimize tego nie zobaczy — trzeba dopytać ludzi, którzy te zgłoszenia obsługują.
Optimize nie pokazuje klasycznej istotności statystycznej. Podaje prawdopodobieństwo, że dany wariant jest najlepszy, oraz przedział modelowanej poprawy. To podejście wygodne w interpretacji i bardzo łatwe do nadinterpretowania.
Zasada, której się trzymam: test trwa co najmniej dwa pełne tygodnie, niezależnie od tego, co pokazuje panel po trzech dniach. Powód jest prosty: ruch w poniedziałek zachowuje się inaczej niż w sobotę, a przy kampaniach Google Ads dochodzi jeszcze zmienność wynikająca z harmonogramu i budżetu. Dwa tygodnie to minimum, żeby objąć pełny cykl tygodniowy dwa razy. Przy dłuższym procesie decyzyjnym trzeba odpowiednio więcej.
Druga zasada: nie kończę testu w momencie, w którym wynik zaczyna mi się podobać. Zaglądanie codziennie i zamknięcie przy pierwszym korzystnym odczycie to najskuteczniejszy sposób, żeby wyprodukować fałszywy wynik. Datę zakończenia ustalam z góry.
Trzecia: wynik nierozstrzygnięty to też wynik. Jeśli po dwóch tygodniach warianty stoją równo, dowiedziałeś się czegoś ważnego — testowany element nie ma znaczenia dla tej decyzji. Lepiej zapisać to i przejść do następnej hipotezy niż przedłużać test w nadziei, że liczby w końcu ułożą się po naszej stronie.
Zbieram je z kont, które przejmuję, i powtarzają się z uporem.
Na koniec rzecz, o której myślę zawodowo najczęściej: jak nie zepsuć testem kampanii i kampanią testu.
Kampanie Google Ads to dobre źródło ruchu do testów, bo ruch jest przewidywalny i sterowalny. Ale są dwa warunki. Pierwszy: w trakcie testu nie zmieniam ustawień kampanii, która ten ruch dostarcza. Żadnych korekt budżetu, stawek ani nowych grup reklam na tym samym adresie. Drugi: pilnuję, żeby oba warianty otrzymywały ruch z tych samych kampanii, a nie żeby jeden z nich obsługiwał przypadkiem inny segment.
Odwrotna zależność też istnieje. Jeśli w koncie działa strategia stawek nastawiona na konwersje, to zmiana skuteczności strony docelowej zmienia dane, na których uczy się algorytm. Nie jest to argument przeciw testom — jest to argument za tym, żeby nie prowadzić testu strony i nie przestawiać strategii stawek w tym samym tygodniu.
I uwaga porządkowa: Optimize i eksperymenty w Google Ads to dwa różne narzędzia do dwóch różnych pytań. Optimize odpowiada, która wersja strony lepiej domyka ruch. Eksperymenty w kampanii odpowiadają, które ustawienie kampanii lepiej ten ruch sprowadza. Mieszanie ich w jednym teście gwarantuje wynik, którego nie da się przypisać do żadnej przyczyny.
Używamy plików cookies, aby ułatwić Ci nawigację oraz wykonywanie określonych funkcji. Szczegółowe informacje o wszystkich plikach cookies znajdziesz w każdej kategorii zgody poniżej.
Pliki cookies oznaczone jako "Niezbędne" są przechowywane w Twojej przeglądarce, ponieważ są one kluczowe dla zapewnienia podstawowych funkcji strony.
Używamy również plików cookies firm trzecich, które pomagają nam analizować, w jaki sposób korzystasz z tej strony, zapamiętują Twoje preferencje oraz dostarczają treści i reklamy odpowiednie dla Ciebie. Te pliki cookies będą przechowywane w Twojej przeglądarce tylko za Twoją uprzednią zgodą.
Możesz zdecydować, czy chcesz włączyć lub wyłączyć niektóre bądź wszystkie te pliki cookies, jednak wyłączenie niektórych z nich może wpłynąć na Twoje doświadczenia podczas przeglądania strony.
| Cookie | Czas przechowywania | Opis |
|---|---|---|
| __cf_bm | 13 minutes | Cloudflare bot management — distinguishes humans from bots. |
| rc::* | Persistent | Google reCAPTCHA — localStorage holding anti-bot challenge state. |
| Cookie | Czas przechowywania | Opis |
|---|---|---|
| wpEmojiSettingsSupports | Session | WordPress — sessionStorage flag caching whether the browser can render emoji (feature detection). |
| ytidb* | Persistent | YouTube — IndexedDB storing playback/search state for embedded videos. |
| Cookie | Czas przechowywania | Opis |
|---|---|---|
| _ga_* | 400 days | Google Analytics 4 — persists session state per property. |
| _ga | 400 days | Google Analytics — distinguishes unique users via a client id. |
| Cookie | Czas przechowywania | Opis |
|---|---|---|
| NID | 183 days | Google — stores preferences for personalized ads. |
| fr | 90 days | Meta — encrypted Facebook id and browser id for ads. |
| _gcl_au | 90 days | Google AdSense/Ads — experiments with advertising efficiency (conversion linker). |
| Cookie | Czas przechowywania | Opis |
|---|---|---|
| __Secure-YNID | 180 days | |
| YSC | Session | |
| __Secure-ROLLOUT_TOKEN | 180 days | |
| VISITOR_INFO1_LIVE | 180 days | |
| VISITOR_PRIVACY_METADATA | 180 days | |
| datr | 400 days | |
| sb | 400 days | |
| wd | 7 days |