Jak przeprowadzić test A/B za darmo? Case na przykładzie Hubspot CMS i GA4

W momencie kiedy ogłoszono zamknięcie narzędzia Google Optimize z dniem 30 września 2023, dla wielu osób stało się jasne, że „Dobrze już było”.

Dla osób, które nie są wtajemniczone – Google Optimize był świetnym rozwiązaniem pod testy A/B. Jego głównymi zaletami było to, że był darmowy, a jego wdrożenie nie wymagało nie wiadomo jak technicznej wiedzy.

Teraz, tych kilkanaście miesięcy później musimy wybierać z narzędzi (m.in. Optimizely, VWO, AB Tasty, Kameleoon), których cena jest niemała, a implementacja wymaga pewnych zasobów developerskich.

Jednak nie w każdym przypadku jesteśmy skazani na rozwiązania, które wymagają od nas zasobów człowieko-pieniężnych. Jeśli korzystasz z CMSa od Hubspota, masz możliwość przeprowadzenia A/B testu zupełnie za darmo. Pokażę Ci jak!

Testy A/B w Hubspot CMS – wyjaśnienie

Część osób pewnie powie „No spoko, ale Hubspot CMS ma wbudowaną funkcję robienia takich testów, więc to jest nic nowego i w ogóle, o czym tu pisać„.

I mają rację. Tylko, że ten moduł testowania tak naprawdę jest tylko przydatny w momencie kiedy na stronie widnieje formularz.

A ile takich sytuacji mamy? Z pewnością jest to mniejszość wszystkich testów.

Panel z wynikami A/B testu w Hubspot CMS

Z tego powodu jeśli na danej stronie nie mamy formularza, to będziemy mieć w panelu metryki, które zasadniczo nic nam nie mówią, jak: liczba wyświetleń, średni Bounce Rate czy też czas spędzony na stronie, co widać na powyższej grafice.

W tym artykule, chcę pokazać Ci jak ustawić test A/B w Hubspocie, aby jego wyniki analizować w raporcie stworzonym w Google Analytics 4, gdzie mamy (a przynajmniej powinniśmy mieć) najważniejsze dane marketingowo-sprzedażowe.

Wbrew pozorom ustawienie tego nie jest aż tak trudne, jakby się mogło wydawać – zaraz Wam wszystko wyjaśnię 🙂

Pierwszy krok, czyli… dataLayer 😉

Oczywiście tak naprawdę pierwszym krokiem będzie start testu, ale w Hubspocie sprowadza się to dosłownie do paru kliknięć, których nie ma sensu tutaj opisywać.

Natomiast kiedy już to zrobimy, zaczynamy zabawę… w postaci oznaczenia obu wariantów strony odpowiednim kodem dataLayer.

Czym jest dataLayer w skrócie?

Jest to – jak tłumaczenie z angielskiego wskazuje – 'wartwa danych’, czyli miejsce gdzie możemy umieścić różnego rodzaju dane, które będą się wywoływać w określonych sytuacjach, np. podczas wyświetlenia danej strony czy też po wykonaniu konkretnej akcji, np. w momencie kliknięcia w dany element.

Tutaj będę bazował na tym, że za każdym razem jak odświeżę stronę, na której przeprowadzam test A/B i na której mam umieszczony kod dataLayer, będę wywoływał odpowiednie zdarzenie, po którym poznam że właśnie ktoś (w tym konkretnym przykładzie 'ja’) obejrzał konkretny wariant strony.

Wracając do głównego tematu – umieszczamy poniżej stworzony kod dataLayer na naszą stronę:

<script>
window.dataLayer = window.dataLayer || [];
window.dataLayer.push({
'event': 'nazwa_zdarzenia',
   'experiment_name': 'nazwa_twojego_testu',
   'experiment_id': 'nazwa_wariantu'
})
</script>

… gdzie:

• w 'nazwa_zdarzenia’ ustawiamy sobie swoją nazwę zdarzenia, po którym będziemy wywoływać w Google Tag Managerze zdarzenie wysyłane do GA, np. ’ab_test_viewed’
• w 'nazwa_twojego_testu’ ustawiamy sobie taką nazwę testu, żebyśmy w momencie analizy od razu wiedzieli, co testujemy, np. ’pricing_layout_test’
• w 'nazwa_wariantu’ wpisujemy taką nazwę wariantu, aby łatwo było odróżnić wariant A od wariantu B, np. ’new_layout’ i ’old_layout’

Taki kod umieszczamy w miejscu, gdzie możemy zmienić ustawienia stylowania strony lub też dorzucić swój własny skrypt. Ale uwaga – nie może to być ogólny szablon, gdyż wtedy każda strona, która bazuje na tym szablonie będzie oznaczona kodem dataLayer pod test A/B, a w końcu nie na każdej stronie go przeprowadzamy.

W przypadku Hubspot CMS będą to ustawienia tej konkretnej strony:

Kod dataLayer wrzucamy w ustawieniach strony wariantu A i wariantu B, dzięki czemu będziemy wiedzieć, który wariant lepiej performuje

Po wrzuceniu kodu do ustawień pamiętajmy o opublikowaniu zmian 🙂

Zmienne naszym przyjacielem

Po opublikowaniu kodu odstawiamy Hubspota na bok i przechodzimy do etapu, gdzie będziemy zaciągać i przekazywać zadeklarowane dane z dataLayer do GA4. Oczywiście robimy to w Google Tag Managerze.

Najpierw ustawiamy zmienną dataLayer, a w zasadzie 2 zmienne – experiment_name i experiment_id. 

Zmienna dataLayer o nazwie experiment_name, dzięki której będziemy zaciągać informacje o nazwie testu A/B

Z pewnością pamiętasz te nazwy z poprzedniego kroku, gdzie przypisywaliśmy im odpowiednie wartości – to nam pozwoli wiedzieć, którą wersję strony właśnie zobaczyliśmy.

Akcja-reakcja, czyli ustawienie tagu

Następnym krokiem jest stworzenie tagu w Google Tag Managerze, który będzie odpalał się w sytuacji, kiedy nastąpi wywołanie zdarzenia zadeklarowanego w kodzie dataLayer.

Tworzymy więc Regułę z niestandardowym zdarzeniem – u mnie to będzie 'ab_test’, ale u Ciebie powinno być tak jak było w dataLayer, np. ab_test_viewed (według mojej propozycji z pierwszego kroku).

Custom event z dataLayer – każde wystąpienie tego zdarzenia będzie wywoływało przypięty do niego tag

Po stworzeniu Reguły tworzymy sam tag – chcemy analizować dane w Google Analytics, więc będzie to tag GA4.

Wyznaczamy sobie nazwę zdarzenia. Proponuję trzymać się pewnych ram i nazwę zdarzenia w tagu nazwać tak samo jak nazwę niestandardowego zdarzenia w Regule lub przynajmniej podobnie – dzięki temu będziemy mieć jasne nazewnictwo i kiedy tych tagów będziemy mieć kilkanaście lub kilkadziesiąt będzie nam łatwiej odnaleźć się w tym wszystkim.

Tag, który przekaże nam informacje o teście do Google Analytics

Ostatnią rzeczą, którą ustawiamy w tagu jest przypisanie stworzonych wcześniej zmiennych. I tutaj zatrzymajmy się na chwilę.

Zwykle w przypadku tagów GA4, kiedy przekazujemy zmienne, umieszczamy je jako parametry zdarzenia. Tym razem jednak przekażemy je jako parametry użytkownika.

Skąd taka decyzja?

W momencie kiedy ktoś zobaczył wariant A danej strony podczas testu, nie powinniśmy tego rozpatrywać jako coś co będzie się wielokrotnie zmieniało. Prostszymi słowami – niezależnie ile razy ktoś odświeży stronę, zawsze zobaczy ten sam wariant testu, bo prawidłowo wykonany test A/B dzieli ruch (userów, a w zasadzie przeglądarkowe ciasteczka) po równo.

A to oznacza, że raz wyświetlony wariant strony można uznać jako stan użytkownika. Coś jak informacja o tym, że ten użytkownik ma ID o numerze 123456789 i przegląda stronę z Pcimia – te dane traktujemy właśnie jako parametry użytkownika.

Jak przekazujemy parametry użytkownika? Tak samo jak parametry zdarzenia, czyli deklarujemy je w tagu według klucza parametr-wartość:

• parametr jest to nazwa, którą przekazujemy do Google Analytics – nie musi być ona taka sama jak w dataLayer, ale gorąco zachęcam do konsekwentnego trzymania się jednej nomenklatury
• wartość jest to stworzona wcześniej zmienna dataLayer

Czyli jeśli ktoś widział wariant strony ’old_layout’ w teście ’pricing_layout_test’, stworzony przez nas właśnie tag będzie w stanie wyłapać takie dane i przekazać je do Google Analytics, gdzie będziemy analizować wyniki testu.

Kiedy tag testu został przez nas stworzony, publikujemy kontener GTMa i przechodzimy do ostatniego narzędzia, a więc 'Dżi Ej For’.

Fundament to klucz

Zanim usiądziemy sobie do zbudowania raportu z testu, musimy najpierw zadeklarować w Google Analytics jakie parametry chcemy wykorzystać do zbudowania go, czyli tworzymy Niestandardowy wymiar (Custom dimensions w angielskiej wersji). Jest to fundament raportów, które powiedzą nam coś więcej niż to co mamy domyślnie stworzone.

Jak? 3 kroki:

1. Nasz test A/B już się rozpoczął i poprzez tag w GTM wysyłamy informacje o zdarzeniu 'test_ab_viewed’ wraz z parametrami
2. Czekamy 24-48h aż Google Analytics 'przetworzy’, że wysyłane parametry są nowe i należą one do jednej z trzech grup: Event, User, Item
3. Kiedy krok 2 nastąpi, będziemy mogli wybrać grupę wymiaru oraz przesłane parametry (każdy osobno), a następnie podajemy nazwę Wymiaru i zapisujemy

Krok 3, czyli dodawanie Niestandardowego wymiaru pod stworzenie raportu A/B testu

Czy już teraz możemy stworzyć sobie raport testu? Nic z tych rzeczy 😉

Musimy poczekać jeszcze z 24h lub więcej, żeby GA zebrał sensowną próbkę danych, które już są przypisane do stworzonych przed chwilą Niestandardowych wymiarów – inaczej zobaczymy tylko '(not set)’.

Kowalski, raport taktyczny!

Po odczekaniu tych przynajmniej 24h, nadszedł kluczowy moment – stworzenie niestandardowego raportu poprzez Eksploruj (Explore w angielskiej wersji).

I zasadniczo tutaj nie dam Wam dokładnego przepisu na to, jak to zrobić – głównie ze względu na to, że każdy projekt jest inny i czasem będziemy chcieli mierzyć jedno, a czasem drugie.

Ale oczywiście nie zostawię Was na lodzie – opiszę w skrócie, jaki sobie raport zrobiłem i co należy zrobić dalej, aby ustawić śledzenie wyników testu A/B.

Trzymając się jednego przykładu – kod dataLayer, który deklarowaliśmy na początku mówił o teście szablonu jakiegoś Cennika (’experiment_name’: 'pricing_layout_test’), a skoro mamy Cennik, to załóżmy że mamy też typową sprzedaż produktów jak w sklepie internetowym, gdzie są etapy wejścia na kartę produktu, rozpoczęcia zamówienia i zakupu.

Stworzyłem więc raport lejkowy (lub krokowy jak to niektórzy określają) poszczególnych etapów sprzedaży.

Dzięki temu będę widział, na którym etapie najwięcej osób odpada. No dobrze, ale to jest coś oczywistego.

Przejdźmy zatem do tego jak śledzić wyniki testu A/B w raporcie – musimy tutaj na chwilę wrócić do tego, czym były parametry przekazywane z Google Tag Managera do Google Analytics. Były one parametrami użytkowników.

Czyli jeśli chcemy wyodrębnić listę osób, które widziały wariant A Cennika od wszystkich pozostałych osób, musimy stworzyć segment użytkowników, a w zasadzie 2 segmenty:

• osoby, które widziały wariant A
• osoby, które widziały wariant B

Jakby nie patrzeć w teście A/B porównujemy tylko te osoby, które w nim uczestniczą, więc w tym raporcie nie interesują nas te osoby, które przykładowo nigdy nie weszły na Cennik i nie zobaczyły żadnej jego wersji.

Tworzenie segmentu użytkowników, którzy 'mają’ wersję A strony

Jak tworzymy taki segment?

1. Lewa strona raportu, klikamy w 'plusik’, a następnie Create a new segment (Utwórz nowy segment w polskiej wersji)
2. Przechodzimy do ekranu, gdzie wyznaczamy warunki kwalifikacji do segmentu – w naszym przypadku szukamy Niestandardowego wymiaru 'experiment_id’, wybieramy z listy regułę warunku (u nas jest to ’exactly matches’, czyli dopasowanie ścisłe) i wpisujemy warunek ’old_layout’.
3. Zaznaczamy opcję 'Within the same session’ (W ramach tej samej sesji w polskiej wersji) i nadajemy sensowną nazwę segmentu
4. Mamy segment osób, które uczestniczą w teście A/B i widziały wariant A strony

Teraz powielamy kroki 1-3, gdzie w kroku numer 2 zamiast ’old_layout’ wpisujemy ’new_layout’ – tym samym będziemy mieć segment osób, które uczestniczą w teście A/B i widziały wariant B strony.

Po zapisaniu tych segmentów i dodaniu ich do raportu w sekcji 'Segment comparisons’ powinniśmy mieć podział raportu lejkowego na te 2 segmenty. Teraz widzimy, który wariant strony przynosi nam na danym etapie więcej osób – podobnie jak to widać poniżej:

Raport GA4, gdzie widać który wariant testu A/B lepiej performuje

Czy to wszystko co możemy zrobić? Jakby to powiedział Radek Kotarski: „Nic bardziej mylnego” 😉

Załóżmy, że chcemy sprawdzić który wariant testu przynosi lepsze wyniki sprzedażowe.

Tworzymy raport tabelkowy, gdzie mamy widoczne nazwy produktów wraz z liczbą sprzedanych sztuk oraz wolumenem sprzedażowym.

Dodajemy stworzone wcześniej segmenty – wychodzi nam coś na podobieństwo poniższego raportu:

Raport GA4, gdzie widać, który wariant testu A/B przynosi nam lepszą sprzedaż

Niech nasze działania nie będą dziełem przypadku

Wiemy, w jaki sposób mierzyć skuteczność naszego testu A/B. To już coś. Ale żeby powiedzieć sobie, że ten test faktycznie jest wiarygodny, potrzebujemy umieć wyznaczyć sobie poziom istotności statystycznej.

Innymi słowy, musimy wiedzieć czy uzyskany wynik nie jest tylko 'dziełem przypadku’ i faktycznie któraś z wersji testu jest lepsza (albo i nie).

Możemy to zrobić dowolnym kalkulatorem pod A/B testy, np. tym od SurveyMonkey.

Kalkulator do mierzenia istotności statystycznej A/B testu

W rubrykach 'Visitors’ wpisujemy liczbę użytkowników, która widziała wersję A i B strony.

W rubrykach 'Conversions’ wpisujemy liczbę konwersji zrealizowanych przez osoby z wersji A i osoby z wersji B.

W 'Hypothesis’ wybieramy Two-sided – oznacza to, że nasz test może prowadzić również do tego, że wersja B (nowa) jest gorsza niż wersja A (starsza) lub performuje tak samo. Czy to oznacza, że opcja 'One-sided’ jest zła? Nie, ale zrozumienie różnic między nimi wymaga większej wiedzy o statystyce, a w tym artykule staram się pokazać jak najbardziej uniwersalny sposób na mierzenie testów A/B. Dla ciekawskich załączam jednak wpis mówiący o różnicach między podejściem One-sided a Two-sided.

Ostatnią rubryką jest 'Confidence’ – jest to poziom pewności, który przyjmujemy, że nasz wynik nie jest losowy. Im większy poziom pewności sobie wyznaczymy, tym nasze wyniki uznajemy za bardziej miarodajne, ale i też wymagają od nas prowadzenia dłużej jednego testu lub pozyskania większego ruchu dla obu wariantów w krótszym czasie (a wiemy, że nie każdy może sobie na to pozwolić).

Przyjęło się, że w przypadku 'Confidence’ wybór '95%’ jest wystarczający, choć przy bardzo dużym ruchu zaleca się wybranie 99% poziomu pewności.

Po wprowadzeniu danych do takiego kalkulatora mamy już informacje, czy nasze wyniki z raportu w GA4 są już wiarygodne, czy musimy dłużej poczekać albo zastopować test, bo wyniki testu nie dają nam gwarancji uzyskania istotności statystycznej, np. z powodu zbyt małego ruchu na wariant lub zbyt małej różnicy w poziomie konwersji między wariantami.

Podsumowanie

Czy rzeczywiście „Dobrze już było”? Trudno się z tym nie zgodzić – pod wieloma względami obszar analityki stał się trudniejszy i bardziej złożony niż kiedykolwiek.

Ale czy 10 lat temu mogliśmy sobie pozwolić na stworzenie testów A/B całkowicie bezproblemowo? Tego bym nie powiedział, szczególnie że wiedzy o tym jak to robić było o wiele mniej niż obecnie.

Tym bardziej mam nadzieję, że powyższy artykuł pokazał Ci 'inne’ wyjście z sytuacji, a jeśli jesteś osobą nietechniczną, to okazał się on mimo wszystko nader zrozumiały 🙂