W tym odcinku podcastu „Date with Data Talks” Mariusz Michalczuk, ekspert firmy Conversion, rozmawia z Kamilem Zawiślakiem – doświadczonym specjalistą analityki internetowej i liderem zespołów CRO. Tematem rozmowy są testy A/B, budowanie kultury optymalizacji współczynnika konwersji, efektywne wdrażanie procesów analitycznych oraz praktyczne wskazówki związane z aktywacją danych online w organizacjach. Poruszono kwestie zarówno techniczne, jak i wyzwania związane z zarządzaniem zespołami oraz wdrażaniem frameworków testowania w polskich firmach.
Czego dowiesz się z tego wywiadu:
Droga Kamila Zawiślaka do analityki i CRO
Pierwsze kroki i inspiracje do pracy z danymi
Budowanie kultury CRO i testów A/B w organizacji
Framework efektywnego procesu optymalizacji konwersji
Najważniejsze praktyczne rady dla wdrożenia CRO
Zaskakujące przypadki testów A/B z praktyki
Podejście data-driven vs. data-informed
Podsumowanie: Najważniejsze wnioski z rozmowy
Mariusz Michalczuk: Witam w kolejnym odcinku Date with Data Talks. Zanim przedstawię mojego gościa, zachęcam Cię do subskrypcji naszego kanału, aby nie ominęły Cię kolejne odcinki z ciekawymi gośćmi, którzy są specjalistami i zarządzają zespołami wykorzystania danych online w firmach w Polsce i za granicą. Moim gościem dzisiaj jest Kamil Zawiślak. Cześć Kamilu, dzięki, że przyjąłeś zaproszenie do naszego podcastu. Przedstaw się, powiedz kilka słów o sobie.
Kamil Zawiślak: Cześć Mariuszu, również dzięki za zaproszenie. Analityką internetową zajmuję się od przeszło siedmiu lat. Od ostatnich kilku lat, jakichś trzech-czterech, bardzo mocno jestem skupiony na temacie CRO i testów AB. Miałem okazję prowadzić zespół, który był na tym skupiony w ostatnim czasie i testy AB to dzisiaj mój główny temat.
Mariusz Michalczuk: Mówisz, że jesteś od tych kilku lat w temacie danych online. Jak ta twoja ścieżka wyglądała? Jak to się stało, że w ogóle zacząłeś w e-commerce, w online? I tu, gdzie teraz jesteś, czy jesteś odpowiedzialny za wykorzystanie tych danych? Bo chyba nie ma dzisiaj lepszej formy od aktywacji danych online niż procesy optymalizacji współczynnika konwersji. Jak to się po kolei działo? Czy to planowałeś? Czy to wyszło jakoś po drodze?
Kamil Zawiślak: Pewnie. Start w branży marketingu internetowego zacząłem jakieś 10 lat temu w agencji interaktywnej. Tam zacząłem być specjalistą od Google Ads i SEO. Pracowałem tam niespełna 5 lat. Pod koniec zauważyłem potencjał drzemiący w Google Analyticsie i w danych, które zbieraliśmy u klientów, ale nie było nikogo, kto by się tymi danymi zaopiekował i zrobił z nich użytek. Mam też krótki background UX-owy. Stwierdziłem, że fajnie byłoby zasilać dział UX-owy w te dane, żeby robić z nich użytek i wykorzystywać je na korzyść klientów i użytkowników serwisu. Mocno skupiłem się wówczas na Analyticsie, na insightowaniu, wyciąganiu wniosków i to był taki pierwszy początek większej przygody z danymi, która trwa do dzisiaj.
Później miałem okazję pracować przez ostatnie pięć lat w wakacje.pl, gdzie zacząłem pracę jako specjalista marketingu, a z czasem zająłem się właśnie analityką i po kilku latach udało się zbudować zespół skupiony tylko wokół analityki internetowej. Czyli, to mamy wtedy te 10 lat.
Mariusz Michalczuk: Szybko minęło. Czyli to taka ścieżka jest od tego, że faktycznie zaczęły się robić rzeczy związane z marketingiem online. Czy pamiętasz z tych czasów jakiś konkretny moment? No bo tak, ADS i SEO, ja to już wspominałem na tym kanale, że analityka, przynajmniej dane, na początku była domeną SEM-owców i SEO-owców. A czy jesteś w stanie przypomnieć sobie taki moment, że rzeczywiście te dane jakoś tak Ci turbo pomogły? Albo coś było dla Ciebie takie wow, bo ten UX rozumiem, że pojawił się później, po ADSach i SEO? Jak to wyglądało?
Kamil Zawiślak: Trochę w międzyczasie. Sama psychologia sprzedaży czy percepcja użytkowników, różne bajasy z tym związane zawsze były mi bliskie. W Google Ads jest dużo analizy danych: kliknięcia, współczynniki, miary, KPI. Moment, w którym najwięcej się zmieniło, to fakt, że same Google Adsy, kliknięcia i konwersje z tych reklam to było trochę za mało. Zacząłem widzieć potencjał w tym, jak wyglądają dane w Analyticsie. Pamiętam współczynnik odrzuceń i mniej trafne strony, mniej relewantne do nagłówków reklam. To był taki początek zagłębiania się w dane w Google Analyticsie.
Mariusz Michalczuk: Czyli te dane były potrzebne, żeby poprawiać kampanie. Jedna strona to to, co poprawiamy off-site, żeby użytkownicy klikali w reklamy i zainteresowali się firmą. Później, jak trafią do serwisu, większą rolę odgrywał UX i stworzenie zespołu od CRO. Przeszedłeś tę drogę od pozyskiwania ruchu do optymalizacji tego ruchu. Co dla Ciebie było takim efektywnym, albo co uważasz za efektywny proces tej optymalizacji współczynnika konwersji? Mam wrażenie, że z tym CRO na rynku jest trochę tak, że wszyscy o tym mówią, a mało kto w praktyce robi, a tutaj nie mógłbym lepszej osoby wymarzyć do kanału – osoby, która rzeczywiście tworzyła te procesy i zespół, który w praktyce się tym zajmował.
Kamil Zawiślak: W perspektywie czasu pamiętam, jak kiedyś nie było na rynku zbyt wielu ogłoszeń na analityka internetowego. To były początki, gdzie analityka się rozwijała i wiele firm nie wiedziało wtedy, że potrzebuje analityka internetowego w zespole. To był taki pierwszy kamień milowy. Później podobnie było z testami A/B. W większości firm, z którymi współpracowałem, niestety do dzisiaj wygląda to często tak, że mamy pomysł i go wdrażamy. Excel często przyjmie wiele, więc post factum da się wyjaśnić sporo tych wdrożeń, ale w samych testach A/B nie chodzi o to, żeby podnosić metryki. To może trochę przewrotne, ale testy A/B są potrzebne, żebyśmy wiedzieli, czy idziemy w dobrym kierunku, czy mamy rację w swoich pomysłach, które chcemy wdrażać na serwisie.
Tworzenie tych procesów było bardzo trudne. Mamy zespół różnych specjalistów, którzy świetnie znają się na swojej robocie. Ale kiedy tworzymy osoby odpowiedzialne za optymalizację współczynnika konwersji czy testy A/B, to jest taka osoba, która na początku mówi „sprawdzam”. Te początki są trudne, bo jesteśmy osobą, która musi powiedzieć tym wszystkim ekspertom i product ownerom, że od dzisiaj będziemy walidować wdrożenia w nieco inny sposób. Na przestrzeni czasu to jest wyzwaniem, żeby tę kulturę zmienić, wprowadzać ją w firmie i starać się, żeby była głównym sposobem wdrażania. Wiele firm nie jest na to gotowych, bo wiąże się to z dużymi nakładami na narzędzia i na ekspertów. Same narzędzia, w zależności od skali ruchu serwisu, potrafią bardzo dużo kosztować licencyjnie, a wytworzenie i utrzymanie takiego narzędzia jest jeszcze większym wyzwaniem. Poza mechanizmem losującym musimy te dane później walidować i wizualizować. Skupienie się na kulturze testów A/B jest najtrudniejsze i taka osoba ma nielada wyzwanie, żeby przekonać innych w firmie, że nie chodzi o sprawdzanie każdego ich ruchu, tylko o odpowiedź na pytanie, czy to, co wymyśliliśmy, pomaga użytkownikom i w efekcie jesteśmy w stanie zarabiać więcej, bo o to chodzi.
Mariusz Michalczuk: To jest bardzo ciekawe, co mówisz i chyba bardzo prawdziwe. Testy A/B rzeczywiście są takim elementem sprawdzenia. Trochę zastanawiam się, z czego to może wynikać. Nie wiem, czy to jest społecznie u nas w Polsce, taka kultura nieomylności? No bo każdy chciałby swoją pracę wykonywać dobrze, a jak nie sprawdzi, czy robi to dobrze, to trochę to jest w jego głowie. Wydaje mu się, że robi to dobrze. Jak ci się wydaje, jak byłeś takim ewangelistą tej kultury testowania, to z czego to wynikało, że ludzie jednak się trochę temu przeciwstawiali?
Kamil Zawiślak: Lata pracy bez frameworku do testów A/B sprawiają, że podejście, wdrożenie, zmiany są trudne. Każdy chce wykonywać swoją pracę dobrze, ale jednocześnie wdrażać swoje pomysły. Fokus na wdrażanie swoich pomysłów nie pomaga w tym podejściu. Statystyki mówią, że średnio 10-15% testów A/B powodzi się, czyli finalnie mamy poprawę danej miary, którą chcieliśmy poprawić. To pokazuje, że bardzo dużo testów nie potwierdza się w danych. Czyli albo nie do końca mieliśmy rację, stawiając daną hipotezę, albo użytkownicy reagują w zupełnie inny sposób, a nasz pomysł nie do końca rozwiązuje ich problem. W samych testach A/B największym wyzwaniem jest wychodzenie od danych, fokus na użytkownika, na problemy.
Świetnym sposobem jest priorytetyzacja zebranych pomysłów czy powodów, z których użytkownicy mają problem. Przy priorytetyzacji idziemy od góry. Specjalista zawsze musi pilnować, żeby hipoteza była dobrze postawiona, by dało się ją zwalidować. Idealna hipoteza wychodzi od danych, mamy na to dowody, które mogą wynikać z ankiet, NPS-a, danych ilościowych, jakościowych czy CRM-owych. Mając dowody, stawiamy hipotezę, która ma banalny wzór: zmienimy na stronie X na Y, by wpłynąć na Z, i powinniśmy założyć, o ile procent wpłyniemy na daną metrykę. Większość testów nie jest po myśli inicjatora, ale z tej większości, która się nie powodzi, płynie nauka i nie ma lepszego sposobu w procesie optymalizacji niż robienie testów A/B na większą skalę. Jeżeli większość testów się nie powodzi, to rocznie musimy ich zrobić przynajmniej kilkadziesiąt, żeby efektywnie, trwale poprawić metrykę konwersji.
Niełatwo jest wielu firmom prowadzić tak wiele testów jednocześnie, czy realizować. Przyjęło się, że testy powinny trwać dwa tygodnie, ale to tylko założenie. Cały cykl powinien być zachowany. Często jakiś super pomysł wcale nie poprawia metryki. Wtedy jest masa pracy, bo KPI to jedno. Warto walidować też inne rzeczy. Kiedyś Airbnb robiło test, którym się chwalili. Airbnb nie miało mapki, która jest teraz nieodzownym elementem listingu. Specjaliści z Airbnb wpadli na to, że zrobią taką mapę, nowy listing, ale konwersja się nie poprawiła, bo na Internet Explorerze konwersja poleciała na łeb na szyję, bo mapa nie była kompatybilna z tą przeglądarką. Na wszystkich innych było in plus. Finalnie mieliśmy poprawę, ale była przykryta danymi z Internet Explorera. Diabeł tkwi w szczegółach i trzeba dane głębiej eksplorować. Hipotezy mogły się nie powieść też z powodu problemów z funkcjonalnością, które wychodzą, a normalnie byśmy tego nie zauważyli.
Mariusz Michalczuk: Chociaż Internet Explorer swego czasu był na tyle popularny. Pamiętam, jak zaczynaliśmy w latach 2010-2015, jak widzieliśmy Internet Explorera, to zwłaszcza w serwisach, gdzie dużo administracji korzystało z rzeczy państwowych. Cieszę się, że wspomniałeś o tym elemencie, że testy A/B są narzędziem do sprawdzania efektywności zmian. Ja podzielę się doświadczeniem: w toku projektów optymalizacji współczynnika konwersji, które teraz nazywamy optymalizacją doświadczeń użytkownika, na początku wdrażaliśmy czy testowaliśmy rzeczy, które były w naszej głowie, w heurystykach, dobrych praktykach. Mieliśmy taką księgę zmian, które zazwyczaj działały, ale do pewnego momentu. W pewnym momencie, tak jak mówiłeś o priorytetyzacji, dodaliśmy jedną kolumnę do scoringu, która oznaczała, czy rekomendacja płynie z dobrych praktyk, czy bezpośrednio z danych. Im bliżej danych ilościowych, tym miała większą wagę, bo dane ilościowe potwierdzały problem w większym stopniu. Wiadomo, badanie użyteczności to max 10 osób, a dane ilościowe to często setki tysięcy potwierdzające, że jakiś element nie działa. W przypadku Internet Explorera, to powinien być element Quality Assurance, ale często jest tak, że „u mnie działa”, a później w danych wynika, że coś przestaje działać.
Kamil Zawiślak: Jak najbardziej. A propos „u mnie działa”, dużo narzędzi do testów A/B ma mechanizm feature flaggingu. To jedna z dobrych praktyk a propos wypuszczania zmian na produkcję. Wiele firm zmiany oczywiście testuje, ale później trafia to na produkcję od razu na 100%. Często, jeżeli coś nie działa, gasimy światło oby tylko na chwilkę, ale czasami to trwa i kilka godzin. Awaria na serwisie spowodowana błahymi rzeczami potrafi trwać bardzo długo. Warto ten sposób na testowanie połączyć z takim podejściem, żeby nie wychodzić ze zmianami na 100%. Spotkałem się z rozwiązaniami, gdzie tak jest, ale jest sporo miejsc, gdzie nadal zmiany są wdrażane na 100%. To jest ciekawe i warte rozważenia.
A propos priorytetyzacji, o której wspomniałeś, jest ona szalenie istotna. Wyobraźmy sobie serwis z milionami użytkowników i konwersją 3-5%. W każdym teście A/B powinniśmy używać kalkulatora, który powie nam, jak duży ruch jest potrzebny, żeby stwierdzić istotność statystyczną. Sytuacje, kiedy mamy kilka zespołów produktowych, każdy z masą pomysłów, a ruch na serwisie nie jest z gumy, więc nie możemy odpalić Bóg wie ile testów. Musimy pamiętać, że część testów nie może działać jednocześnie z innym, np. kilka zmian na prezentacji oferty czy listingu. Przy kilku zespołach produktowych, framework z bazą, repozytorium i sensowną priorytetyzacją, popartą danymi ilościowymi, jakościowymi, a nie heurystykami, jest bardzo ważna. Często spotykałem się z tym, że ktoś miał super pomysł na test A/B i uważał, że zadziała, ale nie było przestrzeni w danym momencie, żeby to przeprowadzić i sprawdzić. Sposobów na priorytetyzację jest kilka. Można opierać się na frameworku ICE (ważność, łatwość wdrożenia), ale są one trudne. Idealnie, jeżeli w zespole mamy kompetencje i jesteśmy w stanie z deweloperem ocenić koszt wdrożenia. Wówczas mówimy o pełnym zakresie priorytetów. Najgorzej jest, jeżeli biznes sam ocenia łatwość wdrożenia, nie wiedząc, ile to potrwa.
Mariusz Michalczuk: Trochę za późno wtedy na priorytetyzację.
Mariusz Michalczuk: Zanotowałem sobie dwie rzeczy z dobrych praktyk: Quality Assurance i priorytetyzacja. Co jeszcze byś dodał do efektywnego procesu CRO? Jakieś wskazówki dla osób, które chciałyby odpalić ten proces, albo które już to robią, ale niekoniecznie im wychodzi.
Kamil Zawiślak: Zdecydowanie wprowadziłbym zasadę: nie patrzymy na konkurencję. To zasada, która ma duże poparcie w tym, co teraz powiem. Nie wiemy, czy konkurencja dany element ma dobrze zoptymalizowany, czy on działa w ogóle. Co gorsza, czy tam nie jest prowadzony jakiś test A/B. Skupimy się, skopiujemy, czyli poniesiemy koszt, a skopiujemy rozwiązanie, bo niestety nadal kopiujemy, często projektując interfejsy, rozwiązanie, które finalnie nie wejdzie w ogóle na produkcję. Patrzenie na konkurencję jest bardzo niebezpieczne z tego względu, że z jakiegoś powodu ci użytkownicy kupują tam, a nie u nas.
Drugi powód: nie powinniśmy pytać użytkowników, co zmieniliby w serwisie. To uwaga do osób projektujących, ale to też są ludzie, bez których proces CRO nie miałby miejsca. Najgorzej, jeżeli projektant pyta w badaniach czy na prototypowaniu „co, drogi użytkowniku, zmieniłbyś w ramach naszego serwisu?”. Taki użytkownik będzie mówił o zmianach przez pryzmat innych stron, z których korzysta. Mogą być konkurencyjne, ale mogą być zupełnie inne, więc będzie mówił o swoich doświadczeniach i będzie to tylko kilka głosów.
Mariusz Michalczuk: Pewnie się nie będzie różniło tym, co my sami, prawda? Tak jak jest podejmowanie decyzji o zmianach na podstawie jakiegoś swojego doświadczenia versus danych, tak jakbyśmy brali pod uwagę jednego użytkownika, to bierzemy jego, a nie nasze doświadczenie, czyli to praktycznie za dużo się nie różni, nie?
Kamil Zawiślak: Dokładnie. I w tej sytuacji skupiamy się na jakimś rozwiązaniu, nie rozumiejąc tak naprawdę problemów w danej części serwisu. Jeżeli w ten sposób będziemy podchodzić do CRO, to będziemy projektować gorsze rzeczy, w mojej ocenie, które później w testach bardzo często nie wychodzą. To co jeszcze mogę dodać to „testujmy” – to jest kontrowersyjne z punktu widzenia osób, które chcą zrobić coś dużego, dużą zmianę. Czasami nie da się inaczej z powodów technicznych czy infrastrukturalnych, kod jest przestarzały i musimy wprowadzić dużą zmianę. Ale to bardzo często wiąże się ze spadkiem konwersji na początku i odbudową, zaczęciem procesu od zera, bo na nowo musimy zrozumieć użytkowników. Na to często nie ma czasu, bo zaraz trzeba wdrażać nowe projekty, a my mamy masę pytań, dlaczego ta metryka poleciała, a my nie wiemy, bo wprowadzono bardzo dużo zmian na serwisie. Klienci mają swoje przyzwyczajenia i często redesign nawet testowany z użytkownikami to duża zmiana i użytkownicy muszą przyzwyczaić się od nowa. Część nawet odejdzie do konkurencji, bo zmiana może być drastyczna. Testujmy jak najmniejsze zmiany w serwisie, nawet subtelne, copywritingowe mogą poprawiać konwersję.
Nie trzeba od razu przewracać do góry nogami designu czy layoutu. Nawet jeżeli mamy za cel duży redesign, w mojej ocenie najlepszym podejściem jest zaprojektowanie layoutu, ale wdrożenie go w taki sposób, abyśmy mogli elementami podmieniać dzisiejszą stronę i w ten sposób testować i nie przywiązywać się do zaprojektowanego layoutu, bo dane powinny pokazywać, w którym kierunku powinniśmy pójść. Są w Polsce serwisy, które zmiany nawet w layoucie testują na 1% ruchu na konkretnej stronie produktu, bo totalnie nie wiedzą, przy skali użytkowników, co zrobi użytkownik. Warto pamiętać, że cały czas jesteśmy tylko ludźmi, którzy mogą się mylić, więc testy A/B są po to, żeby pomagać, a nie walidować. Jest współczynnik success rate testów i warto go optymalizować poprzez rozwój zespołów produktowych, czyli kompetencji do testów A/B. W ramach tej metryki możemy mówić, że dziś mamy 20% testów, które się powodzą, chcemy to poprawiać. Ale to potrafi być zwodnicze, bo można wtedy oczywiste rzeczy testować i iść w tym kierunku, że success rate mamy super, ale konwersja finalnie nie rośnie, bo skupiamy się nie na tych priorytetach. To jest rada w opozycji do potrzeb dużych firm, gdzie projekty muszą się dziać. Tu mówimy o kulturze testów A/B w firmie, żeby framework testowania był integralną częścią procesu wytworzeniowego. Przykład Amazonu, który w Polsce budzi kontrowersje jako serwis, pokazuje, że to najlepsza droga. Sam serwis Amazonu, jest taki timelaps na YouTubie, który pokazuje, jak zmieniał się na przestrzeni dziesięciu, może dwudziestu lat. Widać, że część rzeczy wycofywano, wracano do starego layoutu w niektórych miejscach i ten serwis nigdy nie przeszedł dużego redesignu, ale zawsze testowane są tam małe zmiany. To super podejście. Warto też wspomnieć o case study firmy Marks & Spencer, która w Wielkiej Brytanii przeprowadziła bardzo duży, kosztowny redesign. Po redesignie straty były ogromne i przyznano się, że proces przeprowadzono źle. To przykład tego, jak można stracić.
Mariusz Michalczuk: Ja też mam podobne doświadczenie. Komentarz do redesignu: nawet jakieś dwa czy trzy tygodnie temu pojawił się u nas odcinek o tym, jak wykorzystać dane do redesignu. Czasami to po prostu decyzja z góry, czasami konieczność ograniczona technologią, zmianą strategii. Jeżeli to nie jest konieczność, jestem fanem podejścia, o którym mówisz. Testujmy mniejsze rzeczy, sprawdzajmy, czy faktycznie działają. Redesigny są kosztowne, opóźniają się, przekraczają budżety. Z mojego doświadczenia, byłem przy kilkunastu redesignach, analizowałem dane. Może jeden, może dwa od razu po wdrożeniu nie miały mniejszego współczynnika konwersji niż wersja poprzednia. Najczęściej to był spadek, który potrafił wracać do poziomu zero przez pół roku. To zależało od grupy użytkowników. Pamiętam, testowaliśmy sklep zoologiczny, gdzie to charakter biznesu, który dokładnie wie, kiedy karma się kończy. Jak wyszedł newsletter przypominający „hej, kończy się karma, zamów nową”, ktoś wchodził, widział zmieniony serwis, był przerażony i wtedy nasza wersja od razu dostawała po performance’ie.
Kamil Zawiślak: Dokładnie tak. Tu fajny element: w ramach różnych testów A/B widziałem rozwiązania, które właśnie z konkretnego źródła ruchu miały dużą poprawę współczynnika, a ogólnie performowały słabiej. Myślę, że warto poza posiadaniem eksperta w firmie od A/B testingu czy CRO, który poza umiejętnościami analitycznymi łączy świat biznesowy i rozumie użytkowników, bo to posada związana z danymi tylko na poziomie narzędzi, ale experience użytkownika jest bardzo istotny i aspekt biznesowy, żeby te światy połączyć.
Mariusz Michalczuk: Z testów, pewnie w dziesiątkach, jeśli nie w setkach, które przeprowadziłeś, czy mógłbyś przytoczyć jakieś ciekawostki? Nie zachęcam do tego, żeby ktoś, kto słucha case study, brał w ciemno jakieś rzeczy, bo to zadziałało w jego serwisie, w jego grupie docelowej. Ale czy jakieś masz takie rzeczy, które Cię zaskoczyły z tych danych? Czy coś Ci przychodzi do głowy?
Kamil Zawiślak: Niestety dla hipotez czy ich pomysłodawców, ale często spotykałem się z tym, że na bazie przeprowadzonych testów, w ciemno nie do końca wierzyłem w jakąś zmianę. Dlatego, że często te hipotezy, w ich podwalinach, było troszeczkę kopiowanie konkurencji. A to kopiowanie konkurencji często ma krótkie nogi, bo to tam działa, u nas może w ogóle nie zadziałać. Bardziej zaskoczeni bywali ci, którzy przychodzili z tymi pomysłami, ale to była duża nauka dla nich. Pamiętam jeden test A/B, gdzie w czasach, w których w Bookingu wyświetlały się komunikaty, że „ten hotel kupiło już pięć osób”. Później jak mantra na rynku zaczęły pojawiać się takie rozszerzenia, które pokazywały to samo. Booking dostał sowitą karę, bodajże na Węgrzech, i mam wrażenie, że wtedy te rozszerzenia do e-commerce’ów zniknęły z rynku. Podobne rozwiązanie testowała jedna firma i tam okazało się, że to pushowanie klienta, bo to były drogie produkty, totalnie nie miało sensu, a lekki, dobry komunikat z punktu widzenia użytkownika, gdzie mówiono o zainteresowaniu, że „tym produktem interesuje się bardzo dużo osób”, miało zupełnie inny wydźwięk. Można to porównać do opinii, na których często bazujemy jako użytkownicy. Jeżeli firma mówi nam na bazie danych, że tym produktem interesuje się wiele osób, to mam jasną informację, że produkt jest popularny. Ale w sytuacji, kiedy dostaję twardy komunikat „ten hotel już kupiło pięć osób”, to oczywiście efekt ma być taki, że robimy ten efekt trochę, że zaraz tego nie będzie, dostępność jest bardzo niska, ale można sobie zrobić bardzo dużą krzywdę. I duża firma mogła sobie na rynku krzywdę dodać to rozszerzenie do e-commerce’u.
Mariusz Michalczuk: Tak, ja też widziałem, przypomniałeś mi o tym trendzie. Odnośnie popularności, to nie jest wyznacznik, ale myślę o sobie, jaki filtr najczęściej na Allegro wybieram – ja najczęściej wybieram popularność. Chociaż nie jestem przekonany, czy to rzeczywiście działa wobec liczby zakupów, ale widać wyżej te, które mają większą liczbę opinii, a liczba opinii jest jednak skorelowana z liczbą zakupów.
Kamil Zawiślak: W większości dużych e-commerce’ów już dzisiaj działa dużo algorytmów, które wiedzą, co wyświetlać wyżej użytkownikowi. Dopóki to jest dobre dla użytkownika, bo w danym świecie pewnie jest to zważone liczbą zwrotów. Czyli mamy element customer experience, gdzie nie promujemy produktów, które wracają do nas z oświadczeniem nietrafności. Popularność może często być też pomocna. Ja mam nieco inną technikę. Bardzo często sortuję po cenie, ale po to, żeby zobaczyć, jaki jest najdroższy produkt w danej kategorii. Żeby złapać taki punkt odniesienia, gdzie są widełki i sobie wtedy wypośrodkować. Nie chcę tego najtańszego za 300 złotych, ale i tego najdroższego za 800. Szukam wypośrodkowanego. Często się łapię na tym, że w ten sposób filtruję wyniki, jeżeli jest ich dużo. Ostatnio kupowałem pralkę i totalnie nie wiedziałem, a nie chciałem ufać popularności, jak na to patrzą sklepy. W ten sposób najczęściej działam.
Mariusz Michalczuk: Dziękuję Ci za wiele cennych wskazówek. Chciałbym jeszcze skorzystać z Twojego dziesięcioletniego doświadczenia, zaczynając od reklamy online przez zarządzanie i tworzenie działów analityki internetowej. Powiedz mi, na przestrzeni Twojego doświadczenia, jakie różnice widzisz w podejściu do danych bazując na firmach, w których pracowałeś? Tu bardziej zwracam na element, na metryki, analizy. Wiem, że w pewnym momencie przeszedłeś bardziej w kierunku optymalizacji współczynnika konwersji, ale zakładam, że zawsze inne dane online dotyczące marketingu i biznesu gdzieś tam się pojawiały.
Kamil Zawiślak: Jasne. Przypomina mi się ten moment, kiedy wszystkie firmy mówiły, że jest rok mobile i trzeba się optymalizować pod mobile. Ten rok trwał lata, a do dzisiaj trwa. Ale w pewnym momencie był taki buzzword w postaci data-driven. Wiele firm zaczęło twierdzić, że jest data-driven. Wychodziło to lepiej lub gorzej, ale w ramach testów A/B i tego, jak przez różne pryzmaty na te dane trzeba patrzeć, bo nie można ślepo zaufać, że mamy tę istotność lub nie mamy, bo to bywa różnie. Kiedyś miałem test, gdzie istotność była wysoka, a okazało się, że w wariancie A popsuto wyświetlanie danego elementu, dlatego wygrało. To był kontekst konkretnej rozdzielczości. Sesje wykosiły i to w wariancie A, to było zabawne.
Mariusz Michalczuk: Czyli jakby kodowano wariant alternatywny, ale przy okazji poszło coś nie tak w wariancie oryginalnym.
Kamil Zawiślak: Tak, tak. Jakieś globalne CSS-y zaktualizowano. Więc na te dane trzeba patrzeć bardzo mocno przez różne pryzmaty. To data-driven zamieniłbym bardziej na data-informed. Powinniśmy używać dalej tego, czego potrzebujemy od biznesu, czego potrzebują użytkownicy i korzystać z tych informacji, z danych. Z tym jest różnie. Część firm wykorzystuje dane, płynące z nich wnioski, insajty, które tworzą analitycy, a część ślepo ufa konkretnym metrykom i wdraża rozwiązania. Idziemy przez wdrażanie bez sanity checku poprzez data-driven, a pewnie skończymy za jakiś czas na trendzie, który jest już opisywany jako lepsze rozwiązanie, ale wymagające eksperckości, wiedzy domenowej, bo tak powinniśmy do tego podchodzić.
Mariusz Michalczuk: Czyli tak trochę podsumowując, żeby dawać refleksję osobom odpowiedzialnym za dziedziny, że nie wszystko musi być: wysyłamy mailing, to najpierw zróbmy test A/B, wdrażamy zmianę, zróbmy test A/B, prowadzimy kampanię, przeanalizujmy ją do cna, żeby poprawić wszystkie elementy… Tylko żeby udostępniać i dawać dane, najlepiej jeszcze z jakimiś hipotezami, żeby dać taki punkt zastanowienia użytkownikowi, tak? Dobrze to odczytuję?
Kamil Zawiślak: Tak, dobrze. Decyzja o wdrożeniu danej zmiany jest zawsze po stronie product ownera czy product managera, w zależności od firmy. W sytuacji, kiedy mamy test A/B lub po prostu bez testu mamy jakieś metryki, i one świadczą o tym, że jest lepiej lub gorzej, to jeżeli jest gorzej, to nie wdrażamy, a jak jest lepiej, to lecimy z tym na produkcję – to jest wtedy podejście data-driven. A data-informed, to mamy te dane i my decydujemy, czy wdrażamy, czy nie. Zdarza się, że jeżeli nie ma nawet istotności, ale jest to istotne z punktu widzenia strategii czy zmian, które przyjdą za chwilę, to i tak to wdrażamy. Dalej na bazie danych próbujemy sobie z tym radzić. Uważam, że to gdzieś za jakiś czas będzie kierunek. Dzisiaj większość firm mówi, że jest data-driven, zbieramy bardzo dużo danych. Pamiętam w wakacje.pl w sezonie zbieraliśmy nawet 600 milionów eventów sumarycznie, miesięcznie. To były ogromne wolumeny, które pozwalały na szeroką analizę. Tych danych było bardzo dużo, ale te decyzje nie zawsze jednoznacznie z danych powinny wynikać. Chociażby wracając do Airbnb: gdyby było tylko data-driven, to zerojedynkowo test nie do końca się powiódł, nie wdrażamy. Ale zagłębiając się dalej, mamy inne wnioski i decydujemy, poprawiamy tam, gdzie coś nie działało i finalnie też wychodzimy z tym na produkcję.
Mariusz Michalczuk: Super. Kamilu, zbliżamy się do końca, także chciałbym to podsumować, że, za twoją ostatnią myślą, nieważne, czy dane będą elementem decyzyjnym, ważne, żeby były w ogóle w jakimkolwiek procesie zmian, czy to po stronie akurat twojego doświadczenia więcej po stronie produktu niż marketingu. Może miałbyś jakąś jedną myśl, albo coś Ci takiego świta na podstawie tej rozmowy, biorąc pod uwagę, najwięcej o tym CRO rozmawialiśmy, czy chciałbyś jakąś taką jedną myślą zostawić naszych słuchaczy?
Kamil Zawiślak: Tak, faktycznie rozmawialiśmy najwięcej o samych testach A/B. Ten wątek jest naprawdę szeroki. Jeżeli chcemy zatrudnić kogoś od CRO, to w pojedynkę ta osoba nic nie zrobi w firmie. Potrzebuje zespołów, które muszą się rozwijać. Te kompetencje trzeba pielęgnować wśród pracowników na różnym szczeblu: od deweloperów, po UX-owców, po grafików, po osoby projektujące layouty. Dajmy przestrzeń ludziom od CRO, żeby mieli czas i mogli zasilać zespoły w efekty swoich analiz. I żeby te zespoły mogły się rozwijać z testów A/B, które się nie powodzą. Nie ma tutaj co się martwić i smucić. Powinniśmy z nich wyciągać wnioski po to, żeby nasze rozwiązania były lepsze. Nie wyobrażam sobie sytuacji, że ktoś, kto pracuje nawet w różnych firmach, ale bez tej kultury testowania A/B, będzie powielał rozwiązania, które działają gorzej. Z drugiej strony mamy osobę, która pracowała krócej, ale w tym podejściu i się rozwija i wie, że coś nie działa tak, jak by sobie tego życzyła. Rozwijajmy te kompetencje, nie skupiajmy ich wokół jednej osoby, ale rozwijajmy je w całych teamach produktowych.
Mariusz Michalczuk: Super. Ja jeszcze taką klamrą bym to domknął. Bardzo lubię cytat Nelsona Mandeli, też w kontekście testów A/B, który mówi „Ja nigdy nie przegrywam. Ja albo wygrywam, albo się uczę”. Myślę, że to może być dobre podsumowanie tej rozmowy. Kamilu, dziękuję Ci bardzo za czas i za mega doświadczenie i podzielenie się tym doświadczeniem i wiedzą. Do następnego razu. Myślę, że ten temat jest tak szeroki, że jeszcze chętnie za jakiś czas powtórzymy i go pogłębimy. Dzięki wielkie za rozmowę i za czas.
Kamil Zawiślak: Super. Ja również dziękuję. Mam nadzieję, że ktoś z tego skorzysta, co powiedziałem.
Mariusz Michalczuk: Zdecydowanie. Do zobaczenia. Cześć.
Kamil Zawiślak: Dzięki. Cześć.
Rozmowa z Kamilem Zawiślakiem to praktyczny przewodnik po wdrażaniu testów A/B i kultury optymalizacji konwersji w nowoczesnej organizacji. Kluczowe wnioski:
Tagi:
Historie sukcesów
Ostatnie wpisy na blogu
