Testy A / B są często opisywane jako naukowy sposób sprawdzania decyzji projektowych. Czasami określane jako testy dzielone, testowanie A / B jest prostym procesem, który wydaje się obiecywać konkretne wyniki na powierzchni:

Utwórz dwie odmiany elementu projektu, losowo zamień je na swoją stronę i zanotuj reakcje użytkowników, porównaj wyniki, zastosuj najlepszą wersję. To ma sens.

Klasyczny przykład: czerwony przycisk a zielony przycisk, który będzie bardziej kliknięty? Jednak bardziej interesującym pytaniem jest: zielony przycisk kontra ten sam zielony przycisk, który zostanie dotknięty bardziej?

Co się dzieje, gdy my A / B testujemy dwie identyczne odmiany? Test A / A, jeśli chcesz.

Zielony przycisk a zielony przycisk

Aby przetestować ważność każdego testu A / B, potrzebujemy testu, który ma "poprawną" odpowiedź. Potrzebujemy poprawnej odpowiedzi, ponieważ chcemy wiedzieć, że wszystkie rzeczy są równe, jak prawdopodobne jest, że test A / B da wynik, jaki powinien, a do tego musimy wiedzieć, jakiego rezultatu oczekiwać.

Jeśli przetestujemy dwa identyczne przyciski A / B, wynik powinien być martwy

Załóżmy więc, że testujemy zielony przycisk a ten sam zielony przycisk, a przycisk jest tak zachęcający, że stuka w niego 100% użytkowników.

(Procent nie ma znaczenia, może wynosić 14,872%. Ważne jest to, że ponieważ przyciski są identyczne, szybkość wybierania powinna być również identyczna.)

Jeśli przetestujemy dwa identyczne przyciski A / B, wynik powinien być martwy.

Test rzutu monetą

Rzuć monetą. Którą stronę podniosą, głowy lub ogony? Wiemy, że są dwie strony, obie identyczne, więc jest to szansa 50-50.

Jeśli rzucimy monetą dwa razy, wiemy, że są trzy możliwe wyniki: 2 głowy, 2 ogony lub 1 głowa i 1 ogon. I tak dalej…

Powiedzmy, że rzut monetą jest naszym testem A / A; Szanse nadchodzących głów są takie same, jak szanse na pojawienie się ogonów, podobnie jak szanse na dotknięcie jednego z naszych zielonych przycisków są równe.

Napiszmy więc szybki skrypt w przeglądarce (ponieważ większość testów A / B dzieje się w przeglądarce), aby symulować użytkowników dotykających jednego przycisku lub drugiego, w zależności od tego, który z nich jest prezentowany.

Pamiętaj: testujemy dwie identyczne odmiany przycisku, a sposób, w jaki wiemy, że są identyczne, polega na tym, że traktujemy prawdopodobieństwo, że są one używane jako identyczne. Szukamy tylko spójnego (a więc poprawnego) wyniku.

Po pierwsze, potrzebujemy tabeli HTML do zapisania naszych wyników, tabela będzie wyglądać następująco:

#HeadsTailsDifferenceMargin of Error

W pierwszej kolumnie zapisujemy numer testu (wszystkie dobre testy A / B są powtarzane w celu weryfikacji wyników, więc kilkakrotnie powtórzymy test). Następnie rejestrujemy liczbę wyników Heads , a następnie liczbę wyników Tails . Kolejna kolumna będzie różnicą między dwoma wynikami (które powinny wynosić zero). Następnie rejestrujemy margines błędu (który ponownie powinien wynosić 0%). Pod tabelą wydrukujemy podsumowanie, średnią wszystkich wyników i najgorszy wynik.

Oto skrypt:

var bestOf = 12, // the number of times we want to run the testtestRepeat = 12, // the number of times we’d like to repeat the testtestCount = 0, // the number of the current testtestInterval = setInterval(performCoinToss, 100), // call the coin toss functiontotalDifference = 0, // used for calculating the average differenceworstDifference = 0; // the worst casefunction performCoinToss(){testCount++; // increment the current testvar testCounter = bestOf, // the current iteration of the testheadsCounter = 0, // the total number of times the script came up with "heads"tailsCounter = 0; // the total number of times the script came up with "tails"while(testCounter--) // loop 'testCounter' times{Math.round(Math.random()) ? headsCounter++ : tailsCounter++; // finds 0 or 1 randomly, if 1 increments headsCounter, otherwise increments tailsCounter}var difference = Math.abs(headsCounter - tailsCounter), // the difference between the twoerror = (difference / bestOf) * 100; // the error percentagedocument.getElementById("results").innerHTML += "" + testCount + "" + headsCounter + "" + tailsCounter + "" + difference + "" + error + "%"; // add result to tabletotalDifference += difference; // increments the difference counterworstDifference = difference > worstDifference ? difference : worstDifference; // updates worstDifferenceif(--testRepeat == 0){var averageDifference = totalDifference / testCount, // finds average differenceaverageError = (averageDifference / bestOf) * 100; // finds the average error margindocument.getElementById("summary").innerHTML = "

Average difference: " + averageDifference + "

Average margin of error: " + averageError + "%

Worst Case: " + worstDifference + "

"; // write summary to pageclearInterval(testInterval); // if the test has been repeated enough times, clear the interval}}

Kod jest komentowany, więc oto najważniejsze cechy:

Najpierw konfigurujemy kilka zmiennych, w tym liczbę rzutów monetą (bestOf) i liczbę powtórzeń testu (testRepeat).

Uwaga na spoilery: wchodzimy w dość wysokie pętle, więc aby nie niszczyć niczyjej przeglądarki, uruchamiamy test w odstępach co 100 ms.

Wewnątrz funkcji performCoinToss uruchamiamy pętlę wymaganą liczbę razy, przy każdej iteracji pętli używamy losowej funkcji JavaScript, aby wygenerować albo 1, albo 0, co z kolei zwiększa albo headsCounter , albo tailsCounter .

Następnie zapisujemy wynik z tego testu do tabeli.

Na koniec, jeśli test zostanie powtórzony tyle razy, ile chcemy, znajdziemy średnie, aw najgorszym przypadku zapiszemy je w podsumowaniu i wyczyścimy przedział.

Oto wynik . Jak widać średnia różnica jest taka, że ​​będzie inna dla ciebie, ale kiedy to piszę, średnia różnica wynosi 2,8333333333333335, więc średni błąd wynosi 23.611111111111114%.

Ponad 23% błąd nie budzi zaufania, zwłaszcza, że ​​wiemy, że różnica powinna wynosić 0%. Co gorsza, mój najgorszy wynik to 8, to 10-2 na korzyść głów.

Używanie realistycznych liczb

Okay, więc ten test nie był sprawiedliwy. Prawdziwy test A / B nigdy nie będzie twierdził, że znajdzie ostateczny wynik zaledwie 12 użytkowników.

Testowanie A / B wykorzystuje coś, co nazywa się "istotnością statystyczną", co oznacza, że ​​test musi trwać wystarczająco długo, aby uzyskać możliwy do wykonania wynik.

Zatem podwojmy zmienną bestOf i zobaczmy, jak daleko musimy się posunąć, aby osiągnąć margines błędu, mniejszy niż 1% - odpowiednik 99% pewności.

W najlepszym razie z 24 (w chwili pisania) średnia różnica wynosi 3,166666666666665, co stanowi 13,194444444444445%. Krok w dobrym kierunku! Spróbuj sam (twoje wyniki będą się różnić).

Podwajmy to jeszcze raz. Tym razem moja średnia różnica 6,666666666666667, z marginesem błędu 13,88888888888889%. Co gorsza, najgorszy przypadek to 16, to błąd 33.33333333333333%! Możesz spróbuj tego także dla siebie.

W rzeczywistości, nie ma nagród za zgadywanie, że możemy kontynuować: najlepszy z 96 , najlepszy z 192 , najlepszy z 384 , najlepszy z 768 , najlepszy z 1536 , najlepszy z 3072 , najlepszy z 6144 , najlepszy z 12288 , najlepszy z 24576 , najlepiej 49152 , najlepszy z 98304 .

Wreszcie, w najlepszym z 98304 scenariuszy najgorszego przypadku spada poniżej 1%. Innymi słowy możemy być w 99% pewni, że test jest dokładny.

Tak więc w wyniku testu A / A, którego wyniku znaliśmy z góry, potrzebna była próbka o wielkości 98 304, aby osiągnąć akceptowalny margines błędu.

Przycisk 3 000 000 000 $

Ilekroć omawiane jest testowanie A / B, ktoś przypomina przyjaciela znajomego, który A / B przetestował jeden przycisk na swojej stronie i szybko osiągnął nieprawdopodobny zysk (faktyczna wartość dolara przycisku rośnie za każdym razem, gdy słyszę fabuła).

W tych opowieściach przyciski są zwykle testowane pod kątem mikro-kopii "Pobierz mój ebook" w porównaniu do "Pobierz mój bezpłatny ebook". Nie powinno dziwić, że wygrywa ten drugi. To ulepszenie, które zrobiłby każdy dobry copywriter. Bardziej odpowiednim testem A / B będzie "Pobierz mój ebook" kontra "Pobierz ebook" (moje pieniądze są na tym drugim).

Jeśli okażesz się, że wynik jest mocno obciążony jedną z opcji, sugeruje, że coś jest nie tak z jedną z twoich odmian. Częściej dobrym rezultatem będzie poprawa o mniej niż 5%, co stanowi problem, jeśli testujesz z około 1000 użytkowników (margines błędu wynosi około 5%).

Im bardziej przydatny jest test, tym większy margines zwycięstwa dla jednej lub drugiej odmiany. Im bardziej zwarty margines zwycięstwa, tym większa jest wielkość próby, aby uzyskać akceptowalnie mały margines błędu.

Kłamstwa, przeklęte kłamstwa i testowanie A / B

Mark Twain, prawdopodobnie cytując Disraeli, użył kiedyś zwrotu: kłamstwa, przeklęte kłamstwa i statystyki. Przez co miał na myśli to, że coś udowodnione przez statystyki nie musi być prawdą. Statystyki mogą służyć do udowodnienia wszystkiego, co chcesz.

Testy A / B zapewnią ci wynik, ale to wynik, który powie więcej o Tobie i tym, co spodziewałeś się znaleźć, niż o Twoich klientach

Najniebezpieczniejszą rzeczą w testowaniu A / B jest to, że może udowodnić wszystko, czego chcesz; może generować fałszywe alarmy i pozwala nam rozpoznać wzorce, które nie są odpowiednio obsługiwane.

Ponadto test A / B może wskazywać, że zielony przycisk przewyższa czerwony przycisk, ale co z niebieskim przyciskiem? Nawet pomyślne testowanie A / B pozwala nam tylko potwierdzić nasze decyzje projektowe w kontekście samego testu.

Aby test A / B działał zgodnie z założeniami, musimy spełnić dwa przeciwstawne warunki:

  1. powinna istnieć minimalna zmienność pomiędzy opcjami, więc test nie jest ważony według naszych preferencji;
  2. wielkość próby powinna być wystarczająca, aby margines błędu był mniejszy niż siła wyniku.

Niestety, większość witryn nie ma wielkości próby wystarczająco dużej, aby osiągnąć wystarczająco mały margines błędu. A ponieważ nie możemy zwiększyć naszej liczebności próby (gdybyśmy mogli), naszym jedynym wyborem jest zwiększenie różnorodności opcji w celu uzyskania wyraźnego wyniku, skłaniając test przez nasze preferencje.

Testy A / B zapewnią ci wynik, ale to wynik, który powie więcej o Tobie i tym, co spodziewałeś się znaleźć, niż o Twoich klientach. Jeśli chodzi o podejmowanie decyzji projektowych na stronach innych niż te o bardzo dużym natężeniu ruchu, możemy równie dobrze rzucać monetą, jak test A / B.

Przedstawiony obraz, rzut monetą przez Shutterstock.