Metoda testów A/B jest prosta do opisania: dzielimy ruch, porównujemy wyniki i czekamy na istotność statystyczną. Łatwo jednak ją błędnie zastosować, a kilka błędów powtarza się regularnie, nawet w doświadczonych zespołach. W tym artykule omówiono najczęstsze błędy w testach A/B, ich przyczyny i najprostszy sposób na ich uniknięcie.
Błąd nr 1: Testowanie bez jasnej hipotezy
Uruchomienie testu, ponieważ konkurencja wprowadziła podobną zmianę lub ponieważ trend projektowy krąży w sieci, rzadko przynosi realne rezultaty. Bez jasnej hipotezy łączącej obserwację, zmianę i oczekiwaną metrykę, interpretacja wyniku staje się trudna: zwycięski test nie ujawnia niczego na temat „dlaczego”, a przegrany test nie uczy niczego, co można by przenieść na kolejny test.
Korektę można łatwo zastosować: przed każdym testem sformułuj hipotezę w formie „ponieważ [obserwacja], uważamy, że [zmiana] spowoduje [skutek], mierzony za pomocą [wskaźnika]”. Jeśli tego zdania nie da się jasno dokończyć, test prawdopodobnie nie jest jeszcze gotowy do przeprowadzenia.
Błąd nr 2: Przerwanie testu w momencie, gdy wynik wydaje się znaczący
To prawdopodobnie najczęstszy błąd, nawet wśród zespołów znających teorię statystyki. Większość narzędzi wyświetla poziom ufności w czasie rzeczywistym, przeliczany przy każdej nowej wizycie. Codzienne sprawdzanie tej wartości i przerywanie testu, gdy tylko przekroczy ona 95% – czasami już po dwóch lub trzech dniach – zwiększa prawdopodobieństwo napotkania losowej fluktuacji, która w danym momencie przypomina rzeczywisty efekt.
Zjawisko to, opisane w literaturze poświęconej testom kontrolowanym jako „peeking”, może znacząco zwiększyć odsetek wyników fałszywie dodatnich w porównaniu z deklarowanym poziomem ufności. Rozwiązaniem jest ustalenie minimalnej liczebności próby i czasu jej trwania przed uruchomieniem testu (zobacz artykuł na tym blogu poświęcony obliczaniu liczebności próby) i uznanie wyniku za ostateczny dopiero po spełnieniu obu warunków – nigdy wcześniej, nawet jeśli panel kontrolny już teraz wydaje się obiecujący.
Błąd nr 3: Testowanie zbyt wielu zmian naraz
Jednoczesna zmiana tytułu, obrazu, przycisku i układu strony w ramach jednej wariacji może wydawać się efektywna – jeden test zamiast czterech. Problem polega na tym, że pozytywny wynik nie ujawnia, która z czterech zmian przyniosła pożądany efekt, ani czy niektóre z nich faktycznie utrudniły osiągnięcie rezultatu, który bez nich mógłby być jeszcze lepszy.
Wyizolowanie zmiennej w każdym teście pozwala jednoznacznie przypisać wynik do konkretnej zmiany, a tym samym wykorzystać tę wiedzę w kolejnych testach. Nie oznacza to, że należy ograniczać się do mikrokorekt: kompletny projekt strony można z całą pewnością przetestować jako pojedynczy wariant „przeprojektowania” w odniesieniu do kontroli, o ile celem testu jest walidacja projektu jako całości, a nie izolowanie wpływu każdego komponentu.
Błąd nr 4: Ignorowanie wymaganego rozmiaru próbki
Uruchomienie testu bez wcześniejszego oszacowania liczby potrzebnych odwiedzających często prowadzi do jednej z dwóch problematycznych sytuacji: albo test zostaje zatrzymany zbyt wcześnie z powodu braku cierpliwości, co jest podobne do błędu podglądu, albo jest on uruchamiany w nieskończoność bez podjęcia jasnej decyzji, co unieruchamia część ruchu w niezweryfikowanym wariancie na miesiące.
Obliczenie wielkości próby przed uruchomieniem, na podstawie bieżącego współczynnika konwersji i minimalnego efektu, który chcemy wykryć, pozwala nam od samego początku wiedzieć, czy test jest wykonalny w rozsądnych ramach czasowych, i odpowiednio dostosować nasze ambicje, zamiast dokonywać odkryć a posteriori.
Błąd nr 5: Ignorowanie różnic między segmentami
Zagregowany wynik może maskować bardzo różne zachowania w różnych segmentach ruchu. Zmiana może poprawić konwersję na urządzeniach mobilnych, nieznacznie ją pogarszając na komputerach stacjonarnych, lub działać na nowych użytkowników bez wpływu na powracających. Skupienie się wyłącznie na całościowych wynikach grozi generalizacją wyniku, który w rzeczywistości przynosi korzyści tylko części odbiorców – lub nawet wdrożeniem zmiany, której ogólny pozytywny wpływ maskuje spadek w strategicznym segmencie.
Nie ma potrzeby analizowania każdego możliwego segmentu w ramach każdego testu, ale sprawdzenie spójności wyników w odniesieniu do osi najbardziej istotnych dla Twojej firmy (typ urządzenia, nowi i powracający użytkownicy, główne źródła ruchu) przed uogólnieniem wniosków pozostaje prostym sprawdzeniem, które pozwala uniknąć nieprzyjemnych niespodzianek po wdrożeniu.
Błąd nr 6: Mylenie korelacji, związku przyczynowo-skutkowego i efektu nowości
Dobrze przeprowadzony test A/B z losowym rozkładem ruchu zazwyczaj ustala dość wiarygodny związek przyczynowo-skutkowy między testowaną zmianą a mierzonym efektem. Nadal jednak możliwe jest wystąpienie błędu: efektu nowości. Nowy układ może przyciągać większą uwagę po prostu dlatego, że jest inny, a efekt ten zanika, gdy powracający użytkownicy się do niego przyzwyczają. Zjawisko to jest szczególnie ważne w przypadku monitorowania bardzo widocznych zmian testowanych z grupą odbiorców, w której odsetek powracających użytkowników jest wysoki.
Najprostszym podejściem jest wydłużenie czasu trwania testu poza ścisłe minimum statystyczne, gdy podejrzewa się efekt nowości, a następnie porównanie, jeśli pozwala na to objętość, zmian współczynnika konwersji wariantu pomiędzy pierwszym i ostatnim dniem testu: efekt, który wyraźnie zanika z upływem czasu, jest oznaką efektu nowości, a nie trwałej poprawy.
Błąd nr 7: Zaniedbanie dokumentowania wyników
Test, którego wyniki nie są gdzieś rejestrowane w ustrukturyzowany sposób – hipoteza, mierzone wskaźniki, czas trwania, liczebność próby i wynik – traci znaczną część swojej długoterminowej wartości. Bez tego zapisu, ta sama idea jest czasami ponownie testowana rok później z powodu braku pamięci zbiorowej, a indywidualne spostrzeżenia nigdy nie przekładają się na bardziej zniuansowane i skumulowane zrozumienie zachowań odwiedzających.
Utrzymywanie uporządkowanej historii testów, nawet w prostej formie, to jedna z najtańszych i najbardziej opłacalnych inwestycji, jakie zespół może poczynić w swoim programie eksperymentalnym. Pozwala to również z czasem identyfikować powtarzające się motywy (na przykład zmiany, które upraszczają ścieżkę użytkownika, prawie zawsze działają lepiej niż te, które ją wzbogacają) specyficzne dla grupy docelowej.
Błąd nr 8: Generalizowanie wyniku poza jego kontekstem
Test przeprowadzony wyłącznie w nietypowym okresie sprzedaży (wyprzedaż, szczyt sezonu, jednorazowa kampania reklamowa) może dać wynik, który nie powtórzy się przez resztę roku, ponieważ profil odwiedzających w tym okresie różni się od typowego profilu. Podobnie, wynik uzyskany z jednego źródła ruchu (na przykład z konkretnej kampanii reklamowej) niekoniecznie przekłada się na cały ruch w witrynie.
Zwrócenie uwagi na kontekst, w którym przeprowadzono test — okres, dominujące źródła ruchu, zdarzenia nadzwyczajne, które miały miejsce w okresie testowania — pozwala na dokładniejszą ocenę rzeczywistego zakresu wyniku przed jego szerokim wdrożeniem lub podjęciem decyzji o ponownym przetestowaniu go w bardziej reprezentatywnym kontekście, jeśli pojawią się jakiekolwiek wątpliwości.
Błąd nr 9: Pominięcie kontroli technicznej przed uruchomieniem
Test może być metodologicznie poprawny — dobra hipoteza, dobra próbka, przetestowana tylko jedna zmienna — a mimo to dać bezużyteczny wynik, jeśli problem techniczny nie zostanie zauważony podczas uruchomienia: źle skonfigurowany moduł śledzenia konwersji, który nie zlicza pewnych zdarzeń, wariant, który wyświetla się źle w określonej przeglądarce lub na określonym rozmiarze ekranu lub element wariantu, który psuje inny komponent strony, nie będąc od razu tego widocznym.
Systematyczne sprawdzanie przed uruchomieniem testu pozwala uniknąć tych pułapek: wizualizacja wariantu w głównych przeglądarkach i rozmiarach ekranów używanych przez odbiorców, ręczne uruchomienie śledzonego zdarzenia konwersji w celu potwierdzenia jego rejestracji i uruchomienie testu na kilka godzin przy zmniejszonym obciążeniu, zanim przełączy się na obciążenie końcowe, aby wykryć wszelkie oczywiste anomalie, zanim wpłyną one na większą próbkę. Takie sprawdzenie rzadko trwa dłużej niż dziesięć minut i zapobiega odkryciu po kilku dniach zbierania danych, że część wyników jest bezużyteczna.
Krótka lista kontrolna przed rozpoczęciem testu
Podsumowując wszystkie te błędy w formie, którą można bezpośrednio wykorzystać, przedstawiamy kwestie, które należy sprawdzić przed uruchomieniem testu A/B:
- Hipoteza jest sformułowana jasno, z jedną obserwacją, jedną zmianą i jednym wskaźnikiem sukcesu.
- W każdym wariancie modyfikowana jest tylko jedna zmienna, chyba że ma to na celu przetestowanie całościowego, globalnego projektu.
- Wymaganą wielkość próby obliczono na podstawie aktualnego wskaźnika konwersji i minimalnego pożądanego efektu.
- Minimalny czas trwania (przynajmniej jeden do dwóch tygodni) ustalany jest z góry i będzie przestrzegany, nawet jeśli wynik będzie jasny już po kilku dniach.
- Przed ostatecznym uruchomieniem śledzenie konwersji zostało ręcznie przetestowane.
- Wariant został wizualnie zweryfikowany na głównych urządzeniach i przeglądarkach odbiorców.
- Istnieje plan dokumentowania końcowego rezultatu, niezależnie od tego, jaki on będzie.
Przejrzenie tej listy zajmuje zaledwie kilka minut przed każdym uruchomieniem i uwzględnia zdecydowaną większość błędów, które później unieważniają test — czas weryfikacji jest w dużej mierze rekompensowany przez większą niezawodność ostatecznej decyzji.
Najważniejsze wnioski
Żaden z tych błędów nie wymaga zaawansowanych narzędzi, aby ich uniknąć – koryguje się je poprzez metodykę i dyscyplinę: hipotezę formułowaną przed każdym testem, testowanie tylko jednej zmiennej na raz, liczebność próby obliczoną z góry, przestrzeganie ustalonego czasu trwania, zwracanie uwagi na różnice między segmentami oraz systematyczną dokumentację wyników. To właśnie te nawyki, a nie wybór jednego narzędzia, decydują o tym, czy program testów A/B prowadzi do wiarygodnych decyzji w dłuższej perspektywie.
BlastOptimize został zaprojektowany, aby wyeliminować techniczne trudności związane z tym procesem – tworzenie wariantów bez kodu, zintegrowane obliczanie wielkości próby, śledzenie istotności statystycznej w czasie rzeczywistym – dzięki czemu uwaga zespołu pozostaje skupiona na tym, co naprawdę ważne: jakości hipotezy i rygorystyczności metody. Jeśli zauważysz którykolwiek z tych błędów w swoich poprzednich testach, to dobra okazja, aby powrócić do tematu z bardziej zaawansowaną metodą w kolejnym teście.
Komentarze są wyłączone.