Z tego podcastu dowiesz się:

• Czym są testy A/B
• Po co je przeprowadzać
• Kiedy testy A/B mogą uratować twój czas oraz pieniądze firmy
• Kto jest największym beneficjentem A/B testów
• Jak w 10 krokach przeprowadzić testy A/B
• Dlaczego to narzędzie pomaga łagodzić konflikty w zespole
• W jaki sposób A/B testy służą inżynierom
• Co testował Facebook z użyciem A/B testów

Podcast wysłuchasz także na:

Spotify
Google Podcast

Transkrypcja podcastu

Wyobraź sobie sytuację, spotkanie zespołu projektowego. Jesteś ty, inżynierowie i designer. Designer pokazuje nowe makiety jakiejś tam aplikacji e-commerce, którą robicie na zlecenie dużej sieci kwiaciarni.

Załóżmy, że to jest prosta aplikacja dla klientów tej sieci, żeby mogli w łatwy i szybki sposób zamawiać bukiety kwiatów przez internet. W pewnym momencie omawiania makiet, z którymi przyszedł designer, ktoś podnosi rękę i pyta, a dlaczego przycisk dodaj do koszyka jest niebieski, a nie pomarańczowy? Skoro to właśnie pomarańczowy jest takim kolorem waszego brandu, waszej kwiaciarni, waszej sieci kwiaciarni.

A ktoś inny po chwili dodaje, o właśnie, a tak naprawdę dlaczego ten przycisk ma zaokrąglone rogi, a nie proste rogi? I tutaj zaczyna się żwawa dyskusja. Designer motywuje dobór kolorów na przykład jakimiś najnowszymi standardami, ale też wiedzą wyniesioną z innych, z poprzednich projektów.

Programiści się spierają, że przycisk powinien być pomarańczowy, bo inaczej prezes tego nie puści. Rogi tego przycisku nie mogą być zaokrąglone, skoro inne przyciski na stronie też tak nie wyglądają. W pewnym momencie ty jako product manager albo product owner czujesz, że tracisz kontrolę nad spotkaniem i zachodzisz w głowę jak cholera skończyć tę gówno burzę.

Kto ma podjąć decyzję o kolorze przycisku? Czy to w ogóle ma znaczenie? Po czyjej stronie masz się opowiedzieć jako osoba kierująca projektem?

Jeśli kiedykolwiek znajdziesz się w podobnej sytuacji, nie panikuj. Od lat istnieje narzędzie, które spory opierdoły wyprowadzi na prostą. A.B.

Testy. Czym są i kiedy mogą pomóc. To jest Być Jak Manager Podcast epizod 42.

Dzień dobry. Dzisiejszy epizod nagrywam, jak zawsze, jak najczęściej zresztą, w swoim mieszkaniu na wrocławskich Maślicach i być może po raz ostatni nagrywam w tym miejscu. Otóż za kilkanaście godzin wspólnie ze swoją żoną, z całym naszym dobytkiem spakowanym zaledwie do jednego auta osobowego, ruszamy w podróż, o której marzyliśmy od dawna.

Jedziemy do Hiszpanii. A jak długo? Nie wiem.

Czy wrócimy kiedykolwiek do Wrocławia? Tego także nie wiemy. W chwili, gdy to słuchasz, prawdopodobnie nasza podróż już trwa.

Mam nadzieję, że trwa, że nic się nie posypało. Natomiast słowem wstępu mówię o tym, bo niezależnie od tego, gdzie jesteś i o czym marzysz, życzę ci, drogi słuchacze, żeby twoje marzenia były dla ciebie największą siłą i motywacją do działania, bo to jest naprawdę wspaniałe uczucie. No ale dobra, my tu gadu gadu, a jest temat do omówienia.

Powód, dla którego dziś na warsztat biorę AB testy jest bardzo prosty. Jako, że swój podcast kieruje do szeroko pojętej kadry menedżerskiej w branży IT, project managerów, product managerów, scrum masterów, delivery managerów czy analityków biznesowych, to umiejętność sięgania po AB testy wtedy, gdy ich potrzebujemy, może nam naprawdę uratować proces zbierania wymagań i funkcjonalnych i biznesowych. Ja tę audycję podzieliłem na cztery krótkie części.

W pierwszej powiemy sobie, czym są AB testy. W drugiej części opowiem, kto korzysta z AB testów i kto czuje się ich największym beneficjentem. Następnie wyjaśnimy sobie, jakie konkretne problemy pomogą nam rozwiązywać AB testy w przyszłości i które w ogóle pomagają rozwiązywać, aż w końcu przejdziemy sobie krok po kroku przez poszczególne etapy przeprowadzania takich AB testów.

Przypomnę jeszcze stałym, ale też nowym słuchaczom, że poza podcastem jestem również do dyspozycji w ramach moich konsultacji menedżerskich, na które można się zapisać na moim blogu byciakmanager.pl. Mogę też pomóc przeanalizować twoje CV pod kątem skuteczności, jeśli na przykład obnosisz się z myślą zmiany pracy. No i zachęcam też do rozważenia zapisania się na mój newsletter.

Nie wysyłam żadnego spamu, nie przekazuję dalej danych, że tam pozostawiasz maila i imienia. Newsletter służy mi tylko do informowania o nowych podcastach, ale też często, co wiedzą już stali subskrybenci newslettera, dzielę się jakimiś swoimi osobistymi przemyśleniami. Także czasem odlatuje w tym newsletterze.

Czym, mówiąc na razie bardzo ogólnie, są takie AB testy? To się czasem nazywa również split testing. A jeśli miałbym na takim dużym poziomie ogółu pokusić się o definicję AB testów, to to jest tak naprawdę pewna metodyka, popularna zwłaszcza w marketingu i generalnie w branży IT.

Pewna metodyka, metoda, która polega na porównywaniu. Porównywaniu dwóch albo więcej wersji czegoś do siebie. A co to może być coś takiego?

Ano na przykład porównujemy dwie wersje strony internetowej albo dwie różne wersje aplikacji, którą na przykład szykujemy dla użytkowników, aplikacji, z którą chcemy wejść na rynek. Głównie chodzi o to, żeby dzięki takiemu porównywaniu ocenić, która wersja działa po prostu lepiej. Bardziej, która wersja angażuje naszych użytkowników.

Która będzie dla nich przyjemniejsza. Ale do tego sobie jeszcze wrócimy, bo to nie my porównujemy, a nasi użytkownicy, potencjalni odbiorcy. W sensie oni nam pomagają.

Ale do tego też sobie dojdziemy. Natomiast z definicji to jest tak naprawdę wszystko, co warto pamiętać. AB testy jako pewna metoda doskonalenia, metoda odkrywania produktu, która się opiera na pewnej analizie porównawczej.

To teraz, gdy już wiemy, to czym górnolotnie są AB testy, zadajmy sobie pytanie, kto w praktyce sięga po takie testy AB, komu najczęściej służą i dlaczego właśnie te grupy specjalistów mogą czuć się beneficjentami tego narzędzia. To jest chyba oczywiste. Nie zaskoczy nikogo, że zacznę od zespołów produktowych.

Jeśli zespół chce dodać jakąś nową funkcjonalność albo zmienić istniejącą funkcjonalność, to AB testy mogą pomóc zmierzyć, czy taka zmiana wpłynie pozytywnie na naszych użytkowników. Zwłaszcza jak taka zmiana albo nowość, którą chcemy dodać do naszej aplikacji, odbije się na zachowaniu naszych użytkowników względem naszej aplikacji na stronie internetowej. Kolejną grupą, którą sobie wynotowałem, to są marketingowcy.

Zespoły marketingowe często przeprowadzają AB testy właśnie na swoich docelowych stronach, ale też w e-mailach, w jakichś templatkach e-mailowych czy w różnego rodzaju reklamach. A po co? Ano po to, żeby sprawdzić kilka wersji danej reklamy i zmierzyć, która z tych wersji będzie najbardziej skuteczna.

Kolejną grupą specjalistów, beneficjentów AB testów byłyby według mojej oceny zespoły UX, UI. Szeroko pojęci designerzy, projektanci aplikacji, głównie aplikacji, którą projektujemy dla naszych użytkowników. Osoby, które projektują makiety z jakimiś nowymi funkcjami, nowymi funkcjonalnościami.

I ci projektanci często potrzebują wiedzieć, czy ten nowy lub zmieniony interfejs będzie w ogóle zrozumiały dla naszych użytkowników. Czy zaproponowane zmiany będą siadać? Czy będą intuicyjne?

Nie wiem, jak to jeszcze określić. Inną grupą, o której rzadko się mówi, ale gdzieś ona występuje w kontekście AB testów, to są inżynierowie. Chociaż wiadomo, że AB testy są używane przede wszystkim do testowania różnic w interfejsach, w layoutach, w funkcjonalnościach, to jednak część inżynierów śmiało może je wykorzystywać na przykład do testowania zmian w infrastrukturze albo zmian, jakie zachodzą czy zajdą w wydajności naszego systemu.

Aczkolwiek takie zastosowanie AB testów jest już trochę mniej popularne. Wiemy już mniej więcej, czym są AB testy, ale też kto z nich korzysta. Skupmy się teraz na problemach.

No bo czym zresztą jest cała branża IT i cały świat technologii, jeśli nie pewnym wysiłkiem, pewną podróżą człowieka w poszukiwaniu rozwiązań na istniejące problemy. Nawet ładnie to sobie wynotowałem. A jeżeli chodzi o problemy, to wynotowałem sobie 9 takich problemów, z którymi ja się spotkałem w historii swojej krótkiej, skromnej dwunastoletniej kariery zawodowej.

Myślę, że każda osoba, która uświadomi sobie, w jak wielu ważnych aspektach mogą pomóc AB testy, to już nigdy nie spojrzy sceptycznie albo z jakimś dystansem na… metodykę badań. Pierwszym problemem to są problemy z konwersją.

Problem z konwersją, czyli że coś nie jest tak skuteczne, jakbyśmy tego chcieli. Wydaje mi się, że to jest jeden z najczęstszych problemów w sektorze produktów IT. I testy AB mogą nam pomóc zażegnać ten problem, jeśli oczywiście podejdziemy do nich świadomie i z pewnym zapleczem finansowym.

W sensie, żeby robić te testy regularnie, a nie raz na rok, no bo to wtedy jakby nie ma większego sensu. Będę podawał przykłady z życia. Przykład z życia w tym kontekście to jest chociażby ten przycisk dodaj do koszyka, o którym wspomniałem otwierając audycję.

Można testować różne wersje takiego przycisku dodaj do koszyka albo kup teraz. Bardzo popularny przycisk w e-commerce po to, żeby sprawdzić, która wersja tego przycisku spowoduje, że klienci chętniej będą coś u nas kupować. Kolejnym problemem są problemy z zaangażowaniem użytkowników.

Możesz testować różne funkcje albo elementy waszego produktu, żeby zrozumieć, które z nich powodują, że użytkownicy spędzają więcej czasu na stronie. Oczywiście relatywnie więcej czasu na stronie albo w aplikacji. Problem z małym zaangażowaniem użytkowników myślę jest bardzo popularny i jeżeli ktoś skupnął chociaż trochę doświadczenia, to spotkał się z tym problemem.

Przykład z życia. Facebook latami z tego co kojarzę dochodził do tego jak przycisk lubię to, czyli słynne lajki, mogą pomóc zwiększyć zaangażowanie użytkowników. Finalnie wyszło całkiem dobrze.

Nie wiem czy kojarzysz, ale był nawet taki moment, gdzie Facebook testował przycisk nie lubię, czyli dyslajki. Zupełną odwrotność, ale koniec końców z testów wyszło, że lepiej takiego dyslajka nie dodawać, chociaż mogę się mylić, być może oni to wciąż testują i sytuacja może się zmienić w dniu, w którym tego słuchasz. Nie wiem, nie dam sobie ręki uciąć.

Kolejnym problemem jest bardzo często pojawiający się problem z tym jak mamy oceniać nowe funkcje. W czasach, gdy AB testy nie były jeszcze znane, to był poważny problem, bo nie do końca było wiadomo jak ocenić czy nowa funkcja się w ogóle przyjmie, czy się nie przyjmie. Także zanim wprowadzimy nową funkcjonalność dla wszystkich naszych użytkowników, warto przeprowadzić taki AB test na jakiejś mniejszej liczbie userów, chociażby po to, żeby zrozumieć czy my w ogóle dobrze to zaprojektowaliśmy.

Przykład z życia, a tych przykładów można mnożyć, na pewno kojarzysz, że twój znajomy, który ma np. taki sam smartfon jak ty, albo tą samą wersję oprogramowania np. na iPhonie, mówi, że hej widziałeś już nowe ikony w Facebooku, a ty mówisz nie, u mnie jeszcze nie działa, nie działają, nie ma tych ikon.

Być może te ikony, które widzi twój przyjaciel, przyjaciółka, nie weszły jeszcze na produkcję do 100% użytkowników. Właśnie np. Facebook odpala takie AB testy, stąd niektórzy widzą jakieś nowe elementy na tym portalu społecznościowym, a inni użytkownicy tego nie widzą.

To może być jeden z przykładów na to, że AB testy zaczynają być realizowane. Kolejnym problemem jest problem z optymalizacją treści, to jest czwarty problem na liście, które są, którą sobie wypisałem. Częsty problem zwłaszcza na stronach albo w aplikacjach, gdzie mamy dużo treści, dużo kontentu i nie bardzo wiemy jak ten kontent zoptymalizować.

Wtedy takie AB testy możemy wykorzystać, żeby porównać ze sobą kilka wersji naszej aplikacji z różnym kontentem, różne nagłówki, różne opisy produktów, różne zdjęcia. Przeprowadzamy kilka prostych AB testów na użytkownikach i wtedy tak naprawdę teoretycznie powinniśmy już wiedzieć, co się nadaje, co jest zbędne, to zmieniamy, a to wyrzucamy. Wskaźnik odrzuceń przez użytkowników to jest często coś, co spędza sens powiek produktowcom.

Problemem w wielu stron internetowych jest to, że potencjalni klienci wchodzą na stronę np. do sklepu internetowego, a następnie po krótkiej chwili zwyczajnie z tego internetowego sklepu wychodzą. Fachowo mówi się wtedy, że mamy duży współczynnik odrzuceń, czyli że strona lub aplikacja w ogóle nie zainteresowała naszych użytkowników, dlatego oni ją opuścili jeszcze przed tym, zanim w ogóle podjęli jakąś akcję, jakiekolwiek działanie.

Ta metryka z angielskiego nazywa się bounce rate. W takim przypadku, aby testy mogą okazać się zbawienne i powiedzieć nam, dlaczego ludzie szybko odrzucają naszą stronę internetową. Allegro, wszystkie e-komersy jakie znamy, Ceneo, tam bounce rate, ten współczynnik odrzuceń jest bardzo pieczołowicie badany i to są takie przykłady z życia, z którymi podejrzewam, ty również masz kontakt na co dzień, ja z Allegro korzystam dość często, więc uwierz mi, że oni to, jak dużo czasu po odpadniu aplikacji spędzisz w tej aplikacji, bardzo dokładnie mierzą.

Szóstym problemem, który wydaje mi się wart zauważenia w naszej dzisiejszej audycji, to jest problem z optymalizacją kampanii reklamowych. Trochę mniej temat typowo IT, typowo technologiczny, raczej marketingowy. Wspomniałem już o tym przy okazji marketingowców, którzy czasem sięgają po AB testy.

Otóż kampanie reklamowe, które słabo konwertują, to jest trochę taki horror dla specjalistów od marketingu. W kampaniach, gdzie zwłaszcza, gdzie idą potężne budżety, robienie wcześniej AB testów to już jest chyba taki standard. Jeśli miałbym podać przykład z życia, to kojarzę, że nawet na Facebooku było takie narzędzie, gdzie jak ustawiasz kampanię reklamową, to tworzysz dwie jej wersje, a dalej już algorytmy Facebooka decydują, która wersja lepiej siada i właśnie ta wersja będzie świecona użytkownikom.

Ale też nie dam sobie za to ręki uciąć, bo narzędzia społecznościowe to jest dla mnie taka trochę wciąż czarna magia, natomiast kojarzę, że coś takiego było. Siódmym problemem, o którym też dzisiaj już sobie chwilę mówiliśmy, to jest rozwiązywanie sporów wewnętrznych w zespole. Klasyka gatunku.

Odbijam znów do mojego dzisiejszego wstępu. Zespół produktowy, który się kłóci, bo przycisk jest niebieski, a nie pomarańczowy i tak dalej, i tak dalej. Jak zespół nie zgadza się co do kierunku, w którym ma iść nowa funkcjonalność, to ja bym tutaj z biegu zaproponował zrobienie szybkich AB testów.

Wtedy wiadomo, pomarańczowy czy niebieski. Z liczbami ciężko się dyskutuje, bo nie można jakimś nawet mocnym argumentem wyważyć liczb, które wychodzą z matematyki, wychodzą z logiki. Jeżeli dobrze zostały badania przeprowadzone, to my możemy myśleć cokolwiek, mieć swoją intuicję, natomiast tak jak się mówi, liczby nie kłamią.

Ósmy problem to jest ryzyko, a raczej problem z tym, jak to ryzyko minimalizować. Ja byłem świadkiem sytuacji, gdzie wprowadzaliśmy duże zmiany, które spowodowały duże problemy. Duża zmiana, duże ryzyko, duży problem.

Problemy, których pewnie byśmy uniknęli, gdyby prezes albo zarząd firmy dali nam troszkę więcej czasu i troszkę większy budżet na to, żebyśmy mogli przeprowadzić AB testy. Dodam tylko, że AB testy według mojej opinii wcale nie są kosztowną zabawą. Naprawdę nie trzeba wiele dokładać, czasem wystarczy dołożyć kilka dni więcej prac w takiej fazie discovery, żeby przeprowadzić takie AB testy.

Natomiast wprowadzać duże zmiany i od razu liczyć na to, że one się przyjmą, jest to trochę naiwne, lepiej za pośrednictwem testów AB sprawdzić te zmiany najpierw na mniejszej liczbie użytkowników. I uwierz mi, że dodatkowy tydzień AB testów może nas uchronić przed dodatkowym miesiącem wychodzenia z fuck upu, jaki może się przydarzyć. Przykładów z życia również można tutaj mnożyć.

Tylko dodam, że sposób w jaki najczęściej release’uje, czyli wydaje się nowe funkcjonalności na mobilki, na systemy mobilne, polega na tym, że nie wydaje się funkcjonalności od razu do 100% użytkowników. Wydaje się często najpierw na 5, 10, 15% użytkowników i tak dalej. To jeszcze nie jest typowy AB test, natomiast rzeczywiście bardzo często, żeby zminimalizować to ryzyko, testuje się kilka wersji, wspomniałem dzisiaj na Facebooku kilka wersji różnych makiet, żeby sprawdzić czy coś przypadkiem nie spowoduje fuck upu.

O to głównie chodzi. Dziewiąty, ostatni problem na mojej krótkiej liście problemów, z którymi borykamy się w IT to jest problem ze zrozumieniem, z właściwym zrozumieniem preferencji użytkowników. Ja wyjaśnię jednym zdaniem, żeby nie wchodzić już za bardzo w szczegóły.

Testy AB dadzą tobie legitny dowód na to, co się klika, a co się nie klika, co użytkownicy lubią, a czego nie lubią. I jeśli nie potrafisz jasno opisać preferencji swoich użytkowników, oni lubią to, to, to, dlatego, dlatego i tak dalej, to znaczy, że tak naprawdę ich nie znasz. Nie wiesz, czego oczekują od produktu i jak przyjmą nowe zmiany.

Kończę wątek problemów, które potencjalnie możemy rozwiązać dzięki AB testom, natomiast pamiętajmy, że te AB testy, chociaż są super skuteczne w wielu przypadkach, ja osobiście bardzo je lubię, nie rozwiążą wszystkich naszych problemów. Jeśli po przeprowadzeniu AB testów wciąż pozostają jakieś pytania bez odpowiedzi, to prawdopodobnie znaczy, że powinniśmy rozejrzeć się za jeszcze jakąś inną dodatkową metodą badawczą. Dobra, wiemy już czym są AB testy, kto z nich korzysta i jakie problemy pomagają rozwiązać.

Jeśli słuchasz tej audycji wciąż, to po pierwsze jestem pod wrażeniem, po drugie super, dzięki, a po trzecie to zachęcam do śledzenia mnie w mediach społecznościowych, gdzie często wrzucam na LinkedIn głównie, ale też na Instagrama byciakmanager.pl krótkie posty, ale też infografiki z jakimiś praktycznymi poradami, jak zarządzać lepiej. Serdecznie zachęcam. Na koniec, jako taką wisienkę na torcie, w 10 super krótkich krokach przejdziemy sobie przez to, jak w praktyce wygląda przeprowadzanie takich testów AB.

Myślę, że ta wiedza może okazać się super przydatna, mam nadzieję. Mały dysklejmer. Proces, który przedstawię musiałem nieco spłycić i on jest tylko przykładowy, bo wiele zależy tutaj od samego kontekstu i od produktu, który chcielibyśmy testować, który rozwijamy.

Co firma, co zespół to inny obyczaj i inne wyzwania. Pierwszym krokiem w tym całym procesie robienia testów AB to jest moment, w którym określamy cel. Siadamy przy stole, zastanawiamy się, co chcemy poprawić, co nie działa na przykład potencjalnie i chcielibyśmy to zmierzyć.

Może to być na przykład wskaźnik konwersji albo poprawienie zaangażowania naszych użytkowników. A może chcemy sprawdzić, co mamy zrobić, żeby coś tam się lepiej klikało. To zależy od potrzeb, bo każdy cel zawsze wychodzi od potrzeb.

Kiedy mamy ten cel już określony, to krok numer dwa, wybieramy tak zwaną zmienną do testowania. I to może być coś prostego, coś małego. Na przykład przywoływany już kilkakrotnie dzisiaj ten kolor przycisku.

Chyba, że zaprojektowaliśmy zupełnie nowy layout, to można również testować, ta zmienna może być większa, czyli możemy testować bardziej skomplikowane rzeczy, takie jak układ całej strony, którą zaprojektowaliśmy. Jeśli sukcesywnie wybraliśmy i zgodziliśmy się na zmienną do testowania, to krok numer trzy, projektujemy różne wersje tej samej rzeczy. Tworzymy najczęściej dwie albo więcej, jeśli tego wymaga funkcjonalność wersji tego samego elementu, tego samego komponentu, który chcemy przetestować.

Na przykład jeśli testujemy nasz przycisk, to możemy go przygotować w dwóch wersjach. Niebieska oraz pomarańczowa. I kiedy zaprojektowaliśmy różne wersje tego samego elementu, makiety są gotowe, to wskakujemy do czwartego kroku, ustalamy kryteria sukcesu.

Musimy określić przede wszystkim, jakie dane, jakie liczby powinniśmy osiągnąć, powinny do nas wrócić z takich badań, i co powinno się wydarzyć, żebyśmy uznali, że nasz nowy projekt, nowy komponent, funkcjonalność, funkcjonalność będzie sukcesem. Przykładowo, jeśli któraś wersja przycisku będzie się klikać, załóżmy o 15% lepiej niż nasz obecny przycisk na stronie, to wtedy implementujemy tę nową wersję przycisku. A jeśli już ustalimy te kryteria sukcesu, wiemy co mniej więcej chcielibyśmy osiągnąć, jakie rezultaty, to krok numer 5.

Wybieramy narzędzia do testowania. Istnieje wiele narzędzi do testów AB. Ja nie będę sugerował żadnego z nich.

Rzadko kiedy sugeruję i polecam jakieś narzędzia na swoim podcastie, ponieważ jeśli słuchasz tego podcastu na przykład za rok od dnia publikacji, to na rynku mogą być już inne, lepsze narzędzia niż dzisiaj. Także wybierz narzędzie do testowania, zrób krótki research, myślę, że na pewno nie będzie to jakoś super challengujące. Jak już wybraliśmy jako zespół narzędzie do testowania, to krok numer 6.

Musimy podzielić ruch. I teraz uwaga, skupmy się na chwilę. Chodzi o to, żeby każdą wersję naszego nowego przycisku, idźmy tym przykładem, zobaczyła taka sama liczba użytkowników.

Czyli na przykład decydujemy, że nowy przycisk w wersji niebieskiej zobaczy tylko 1000 użytkowników i podobnie pomarańczowy przycisk pojawi się również tylko dla 1000 użytkowników. I kiedy to już ustalimy, czyli na jakiej skali, na jakiej grupie badawczej, na jakich grupach badawczych będziemy pracować, to zwinnie przechodzimy do siódmego już kroku przeprowadzania aby testów. Odpalamy test i zaczynamy zbierać dane.

Po uruchomieniu testu ważne, żebyśmy na bieżąco monitorowali to, co się dzieje, monitorowali pewne wyniki i dane, które zaczynają być agregowane, zbierane, wyświetlane. Najlepiej w czasie rzeczywistym. Zbierajmy te dane i obserwujmy, czy przypadkiem coś się nie zaczyna sypać.

Testy odpalone, dane zebrane. Co dalej? Trzy kroki do końca.

Widzisz, jak łatwo idzie? W teorii to zawsze łatwo brzmi, ale załóżmy, że rzeczywistość będzie nam pomagać, będzie nas lepiej motywować do tego, żeby te testy wychodziły, więc nigdy nie bądźmy pesymistami. Krok numer 8 to przeanalizujmy te wyniki, które zbierzemy.

To samo z siebie wynika, że po zakończeniu testu lub po osiągnięciu odpowiedniej próby analizujemy to, co zebraliśmy. Sprawdzamy, która wersja działała lepiej, niebieski czy pomarańczowy przycisk. Kiedy już przeanalizujemy te dane, no to przed ostatnim krokiem będzie natomiast wyciągnięcie odpowiednich wniosków oraz implementacja tego rozwiązania, na które się zdecydujemy.

Na podstawie wyników łatwiej nam już podjąć tę decyzję, która wersja powinna, mówiąc fachowo, pójść na produkcję. Chyba, że wyniki nie są jednoznaczne, bo tak też się może zdarzyć, to warto je albo powtórzyć, albo powtórzyć i lekko zmodyfikować obie wersje przycisku. Bo jak się okaże, że tylko 3% ja rzucamy od czapy te liczby, bo to jest kwestia taka, że sami musicie zdefiniować te liczby, jaki jest margines błędu, ale załóżmy, że tylko 3% więcej użytkowników kliknęło w pomarańczowy przycisk, to możemy tutaj mówić o pewnym marginesie błędu.

Skoro tylko 3%, to zbadajmy to jeszcze, zanim ten pomarańczowy przycisk pójdzie, bo może weszliśmy w margines błędu i trzeba zmienić kryteria. W takim wypadku powtórzyłbym testy, być może zmienił kryteria, albo zmienił te przyciski i zobaczył, co wtedy zbierzemy. Ten krok teoretycznie moglibyśmy uznać za ostatni, ale jest jeszcze jeden, dziesiąty etap, który z premedytacją dodaję i o którym polecam pamiętać.

Testy AB powinny być powtarzane i przeprowadzane regularnie. To jest naprawdę ciągły proces. Po zakończeniu jednego testu od razu warto myśleć nad kolejnymi elementami, kolejnymi komponentami naszego produktu, naszej strony, które warto optymalizować w kolejnych testach.

W ten sposób naprawdę my się będziemy doskonalić, jak te testy przeprowadzać, lepiej jeszcze poznamy preferencje naszych użytkowników, a jak wejdzie nam to w krew, to będziemy to już robić niemal automatycznie. Jak to stanie częścią naszego stałego procesu developmentu, czy tam discovery, odkrywania produktu, takie AB testy, to myślę, że jesteśmy naprawdę na bardzo dobrej drodze do fajnego, komfortowego podejmowania decyzji o przyszłości naszego produktu. I na tym zakończymy dzisiejszy epizod.

Mam nadzieję, że pomogłem. W razie czego zachęcam do skorzystania z moich konsultacji menedżerskich i zapisania się na newsletter. Czuję się, jakbym niemal przebiegł, przefrunął przez dzisiejszy wątek AB testów.

Nie zaprzeczam, nie potwierdzam, ale rzeczywiście muszę zacząć pakować się do wyprowadzki z Wrocławia. Czas goni. Dzięki za dziś.

Dbaj o siebie i innych. Cześć.