Przeprowadzanie testów A/B landing page'y z wykorzystaniem Google Optimize.

Darmowe narzędzie, ale wymaga dyscypliny

Baner wejsciowyParallax

Przeprowadzanie testów A/B landing page'y z wykorzystaniem Google Optimize.

Darmowe narzędzie, ale wymaga dyscypliny

Autor nie posiada zdjęcia
Tomasz Piasecki
30 maja 2022

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.

Do czego Optimize się nadaje, a do czego nie

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.

Co wdrożyć przed pierwszym testem

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.

Jak zaplanować test, żeby dał odpowiedź

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.

Cel eksperymentu i jego związek z konwersją

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ą.

Ile trzymać test i jak odczytać wynik

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.

Najczęstsze błędy w testach stron docelowych

Zbieram je z kont, które przejmuję, i powtarzają się z uporem.

  • Test na zbyt małym ruchu. Podstrona z kilkoma wejściami dziennie nie da odpowiedzi w rozsądnym czasie. Wybieraj strony, na które faktycznie kierujesz kampanie.
  • Zmiana kilku rzeczy naraz. Nowy nagłówek, nowe zdjęcie i krótszy formularz w jednym wariancie dają wynik, z którego nie wyciągniesz wniosku na przyszłość.
  • Test prowadzony w środku innej zmiany. Zmieniony budżet kampanii, nowa grupa reklam albo przebudowa cennika w trakcie testu unieważniają go w całości.
  • Zignorowany widok mobilny. Wariant sprawdzony wyłącznie na komputerze, przy ruchu w większości telefonicznym, testuje coś innego, niż myślisz.
  • Test z przekierowaniem bez zachowania parametrów. Jeśli przy przekierowaniu zgubisz parametry z reklam, stracisz powiązanie z kampanią i wyniki w Google Ads przestaną się zgadzać.
  • Brak notatki po zakończeniu. Po kwartale nikt nie pamięta, co testowaliście i z jakim skutkiem, więc pół roku później ktoś proponuje ten sam pomysł od nowa.

Testy A/B a kampanie w Google Ads

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.

Podziel się tym artykułem z innymi!

Twitter Facebook Linke.din
Autor nie posiada zdjęcia
Tomasz Piasecki
Specjalista Google Ads / SEM
Zajmuję się kampaniami Google Ads i widocznością stron w wyszukiwarce. Na blogu UDI Group piszę o tym, jak ustawienia kampanii i decyzje techniczne przekładają się na realne wyniki. Staram się tłumaczyć mechanizmy, a nie tylko podawać gotowe przepisy.