Testy A/B w dużej organizacji. Kilka obserwacji.

1. Zapewnij sobie wsparcie programistów (lub naucz się Javascriptu)

Zaczynając testy byliśmy prawdopodobnie zbyt optymistycznie nastawieni do edytora WYSIWYG. Szybko okazało się, że hipotezy, które chcemy sprawdzać wymagają dużo bardziej zaawansowanych zmian w interfejsie użytkownika niż zmiana koloru przycisku lub podmiana tekstu.  Zakładając, że nadal chcemy żeby przygotowanie wariantów do testów było odpowiedzialnością projektantów potrzebowaliśmy pomocy programistów.

Zorganizowaliśmy warsztaty z podstaw Javascriptu w wyniku których powstał narzędziownik ze skryptami. Od tego czasu możemy szybko tworzyć typowe odmiany testów (np. zmiana elementu doładowującego się dynamicznie).  Nadal jednak tworząc skomplikowane testy pracujemy w parze z developerem.

W naszym przypadku zmiana nastąpiła dosyć organicznie – po prostu część programistów zaangażowała się w testy A/B.

Patrząc z perspektywy czasu dobrze byłoby jednak wiedzieć, że taka współpraca będzie potrzebna i przygotować się do niej wcześniej.

2. Nie rzucaj pomysłami. Twórz hipotezy.

Stosunkowa łatwość tworzenia testów powoduje, że łatwo popaść w pułapkę testowania wszystkiego i… sprawdzania tego co się stanie.

Obecnie staramy się, aby każdy pomysł na testy, niezależnie od źródła z jakiego pochodzi, przybrał formę hipotezy:

Hipoteza to nasze przypuszczenie dotyczące skutków zmiany w interfejsie. Hipoteza powinna jasno wskazywać miejsce zmiany (np. element logowania na formularzu rezerwacji) oraz przewidywany rezultat, sformułowany tak, aby dało się jednoznacznie sprawdzić czy został osiągnięty.

Istotne jest to, żeby predykcja wynikała z analizy, researchu lub obserwacji czyli miała racjonalne uzasadnienie. Nasze hipotezy zwykle mają bazę w obserwacjach sesji użytkowników (korzystamy z aplikacji Hotjar) lub zachowaniach użytkowników jakie obserwujemy dzięki Google Analytics. Niektóre z nich opierają się też na wiedzy biznesowej z danego rynku oraz na badaniach jakościowych: prowadzimy testy użyteczności i wywiady IDI z naszymi użytkownikami.

Przykład hipotezy:

Jeśli wyłączymy element tabeli najtańszych połączeń na ekranie wyników wyszukiwania na rynku hiszpańskim, to przychód z 1000 sesji użytkowników wzrośnie o 0,5%. Predykcja wynika z analizy rynku bliźniaczego (z podobnymi zachowaniami użytkowników) oraz obserwacji tunelu konwersji w Google Analytics.

3. “Celem jest konwersja”. Naprawdę?

Organizując testy A/B w e-commerce należy najpierw opracować szereg najistotniejszych miar, które posłużą do mierzenia efektywności poszczególnych wariantów. Współczynniki te są często bardzo różne i zależą przede wszystkim od rodzaju testowanej funkcjonalności, typu produktu, czy od specyfiki samej branży.

Kilka przykładów:

• Zapis do newslettera, do alertu cenowego czy inny sposób na pozyskanie adresu email. Tutaj celem jest pozyskanie jak największej ilości zapisów.
• Użycie formularza kontaktowego. W tym przypadku miarą również jest liczba osób, które skorzystają z formularza, ale tylko wtedy, gdy jest to jeden z kanałów sprzedaży i przekierujemy na niego jak najwięcej użytkowników chcących dokonać zakupu.

Jeśli jednak z formularza korzystają potencjalni klienci, bo mają wątpliwości dotyczące produktu, sposób na mierzenie efektywności tej sekcji serwisu będzie zupełnie inny. W tym przypadku liczba osób, które w ten sposób kontaktują się z nami to raczej symptom problemów niż miara sukcesu.

Ciekawostka z naszej branży: w firmach z sektora travel, wolumen sprzedaży jest bardzo wysoki, produkt często zaskakująco skomplikowany, a model biznesowy oparty w większości na marży, która z kolei jest wielowymiarowa i zależy od wielu czynników.

W takich warunkach głównym celem biznesowym nie jest de facto konwersja, a raczej uzyskanie jak największego przychodu z 1000 odsłon stron lub sesji użytkownika. “Wykręcanie” na siłę jak największej sprzedaży, a nie koncentracja na samym przychodzie to „wykręcanie” dodatkowego ryzyka podniesienia kosztów reklamacji, obsługi klienta w trakcie i po sprzedaży. Wszystko zależy więc od kontekstu i celów biznesowych.

4. Koniec to dopiero początek.

Koniec eksperymentu to dopiero początek dogłębnej analizy danych.

W naszej branży istotnymi czynnikami wpływającymi na odpowiednią motywację zakupową (a więc współczynnik konwersji) są między innymi:

• wyprzedzenie (czas do planowanego lotu)
• długość podróży
• typ lotu (krajowy, międzynarodowy czy międzykontynentalny)
• typ linii lotniczej (tanie linie lotnicze czy linie regularne)

Ktoś kto szuka lotu na 3 dni do przodu zazwyczaj liczy się z wyższymi kosztami w stosunku do lotu za np. 3 miesiące. Prawdopodobnie musi się gdzieś znaleźć w tym czasie i nie traktuje tej podróży tak samo jako ktoś, kto szuka okazji na tani city break. To powoduje, że konwersja takiego użytkownika jest zazwyczaj większa niż użytkownika szukającego inspiracji do przyszłorocznej podróży wakacyjnej. Taki typ zachowania połączony z innymi zaobserwowanymi cechami stanowi podstawę do wydzielenia persony (grupy powiązanych zachowań użytkowników).

Aby wyniki były miarodajne należy sprawdzić czy w grupach testowych każdego z wariantu eksperymentu A/B rozkład użytkowników o podobnych kryteriach jest w miarę równy lub czy też w którejś próbce jest więcej „konwertujących” kryteriów. To wymaga czasami dodatkowej segmentacji na etapie analizy.

Inny problem to fakt, że każda próbka danych z jaką mamy do czynienia jest w pewnym sensie zanieczyszczona: np. ze względu na to, że na stronę wchodzą użytkownicy, których zachowania są nietypowe lub po prostu niezgodne z wydzielonymi przez nas personami (grupami powiązanych zachowań użytkowników).

Być może łatwiej będzie to zrozumieć na przykładzie:

Do badanej grupy wpada „Pani Joanna” – sekretarka kancelarii prawniczej, która zwykle rezerwuje loty dla pracowników biura.  Korzysta z eSky bo akurat lubi, jest jej wygodnie czy z innego, nieznanego dla nas, powodu. Prawnicy często podróżują, bardzo ceniąc sobie przy tym czas, ale nie zawsze licząc się z kosztami podróży (np. ze względu na to, że koszt podróży ponosi klient).

Z perspektywy trwającego testu nagle dla wariantu A przychód z sesji strzela w górę, bo nasz “nietypowy” użytkownik w przeciągu tygodnia zarezerwował 18 relatywnie drogich lotów, które istotnie wpłynęły na poziom marży. Natomiast wśród grup użytkowników której wyświetlił się wariant B nie pojawił się nikt o podobnych zachowaniach konsumenckich.

Takich sytuacji może być więcej, trzeba je oczywiście usunąć z badanej próbki. W innym przypadku warianty eksperymentu stają niemożliwe do metodologicznie poprawnego porównania.

5. „Czy my w zasadzie robimy jakieś testy?” Dziel się wynikami.

Próbujemy budować kulturę, w której zaangażowanie w produkt nie jest domeną jedynie osób po biznesowej stronie, ale również całego zespołu developerskiego i projektowego. To brzmi banalnie, ale zaangażowanie w pracę wzrasta, jeśli widzisz jakie są jej rezultaty.

Z drugiej strony dla osób spoza technologicznej warstwy organizacji testy mogą wydawać się czymś „technicznym” i niezrozumiałym.

Dlatego staramy się, aby wyniki testów i idące za nimi decyzje były skutecznie komunikowane.

W jaki sposób będziesz dzielić się wynikami zależy już od specyfiki firmy, w której pracujesz. Jednak nieważne, czy zrobisz to za pomocą kanału na Slacku, prezentacji multimedialnej w centralnym miejscu biura, czy w formie comiesięcznego newslettera do współpracowników – ważne, żebyś to robił.

6. Bądź gotowy na nieoczekiwane rezultaty.

Prowadzenie testów A/B na kilkudziesięciu rynkach, często z zupełnie odmiennymi zachowaniami konsumenckimi (różnice dotyczą m.in. sposobów płatności, czasu podejmowanie decyzji, typów wybieranych usług i urządzeń na których odbywa się interakcja z usługą) powodują, że często spotykamy się z nieoczekiwanymi rezultatami. Jak radzić sobie z takimi sytuacjami? Co brać pod uwagę, gdy wyniki testów A/B są niekonkluzywne? Wreszcie, jakie są zagrożenia wynikające z nadmiernego polegania na testach przy decyzjach projektowych?

Na te pytania spróbujemy odpowiedzieć Wam podczas warsztatów na tegorocznym WUD Silesia. Zapraszamy :)