W kolejnym odcinku podcastu „Date with Data Talks” Mariusz Michalczuk, ekspert Conversion, rozmawia z Michałem Węglewiczem, Digital Marketing & CRM Managerem w Travelist. Rozmowa dotyczy łączenia światów marketingu i analityki, przejścia z modelu Last Click na modelowanie ekonometryczne (MMM), a także wykorzystania sztucznej inteligencji i synergii między działaniami CRM a płatnym ruchem w dużej organizacji e-commerce.

Czego dowiesz się z tego wywiadu:

Od analityka do marketera: Ścieżka Michała Węglewicza

Nadmiar danych czy klęska urodzaju?

Ekonometria w praktyce: Przejście z Last Click na MMM

Case study: Jak dane uratowały influencer marketing

Synergia Digitalu i CRM: Oszczędność budżetu

Sztuczna inteligencja w Travelist

Rady dla marketerów: Single Source of Truth i LTV

Podsumowanie: Główne wnioski z rozmowy

Od analityka do marketera: Ścieżka Michała Węglewicza

Początki z danymi i odkrywanie „mierzalnego” marketingu

Mariusz Michalczuk: Cześć, witam Cię w kolejnym odcinku z serii Date with Data Talks, czyli podcastu od praktyków danych do praktyków wykorzystania danych i vice versa. Dzisiaj moim i Twoim gościem jest Michał. Michale, dziękuję Ci za przyjęcie zaproszenia. Mógłbyś na początku kilka słów o sobie powiedzieć?

Michał Węglewicz: Cześć Mariusz, wielkie dzięki również za zaproszenie do dzisiejszego odcinka. Nazywam się Michał Węglewicz i zajmuję się digital marketingiem i CRM-em. Obecnie zarządzam tymi obszarami w Traveliście. Wcześniej miałem też okazję pracować w branży finansowej, telekomunikacyjnej. Od kilku lat łączę ten digital i marketing w jeden spójny silnik wzrostu, gdzie to, co jest dziś dla nas najbardziej istotne, czyli analityka i praca z danymi, są bardzo ważnym punktem i obszarem, który towarzyszy mi codziennie.

Mariusz Michalczuk: Super. Jakbyś mógł trochę opowiedzieć, jak to wykorzystanie danych w Twojej codziennej pracy wygląda? Jeżeli masz w swoich kompetencjach zarządzanie CRM-em, to tam danych o klientach jest bardzo dużo. Jak te dane wykorzystujecie, jak to się przekłada później na kreowanie marketingu, kampanii? Jakbyś mógł wrzucić nam trochę takich ciekawostek „behind the scenes”.

Michał Węglewicz: Jasne. Uśmiechnąłem się na to nasze dzisiejsze spotkanie i ten mocny core rozmowy, jakim są dane. W moim podejściu, w całej mojej pracy, taką pierwszą inicjacją, którą miałem w karierze, była praca, gdzie po części realizowałem zadania web analityka. Wtedy, kiedy zaczynałem, miałem tę sposobność, że mogłem poznać obszar web analityki, a potem miałem okazję przejść też przez SEO, przez CRM i tworzenie różnych narzędzi. Dotarłem oczywiście do tego obszaru online marketingu, więc tak naprawdę już od tych wczesnych lat szukałem sposobności, żeby te dwa obszary między sobą integrować, wykorzystywać i szukać wzajemnych synergii.

Nawiązując do początków, ten aspekt bazodanowy bardzo mocno pokazał mi, że podejście do dzisiejszego digitalu jest skrajnie inne, niż sobie wyobrażałem. Wcześniej myślałem, że marketing to kreatywne rozwiązania, hasła, kreacje i bardzo kreatywni ludzie, do których na pewno jest mi daleko. Natomiast dość szybko zrozumiałem, że online mocno różni się tym, że wszystko jest śledzone, mierzone, a zasób danych jest naprawdę ogromny. Zauważyłem, że stało się to wyróżnikiem po pewnym czasie. Następowała zmiana podejścia do marketingu i online zaczynał być coraz bardziej widoczny, a aspekt danych bardzo narastał.

W tych pierwszych doświadczeniach bardzo satysfakcjonujące było to, gdy udawało mi się znaleźć schematy działań czy zaimplementować rozwiązania, które działały nam w CRM-ie – różnego rodzaju targetowania bądź wykluczenia, które kolejno wdrażaliśmy na kampanie digitalowe i performance’owe. To była wtedy bardzo prosta implementacja i optymalizacja, ale co ciekawe, bardzo intratna. Nie tyle same ROI potrafiły nam mocno rosnąć, ale też udawało nam się optymalizować koszty. Mogliśmy ingerować w media mix i mniej inwestować w działania, które wiedzieliśmy, że i tak nie będą miały dużego wpływu na kontrybucję do wyników. To były pierwsze sukcesy, które budowały pomost między dwoma światami, traktowanymi wówczas jako osobne. Dziś udaje nam się to realizować jeszcze bardziej efektywnie, w bardziej zaawansowany sposób, wykorzystując nowe technologie.

Nadmiar danych czy klęska urodzaju?

Jak radzić sobie z ilością informacji

Mariusz Michalczuk: To prawda. Technologia się rozwija, danych nam coraz więcej przybywa. Z mojej perspektywy, oprócz tego, że jest to pozytywny element, ten nadmiar danych często po prostu przytłacza firmy. Jak masz czegoś za dużo – jest takie pojęcie w psychologii jak „klęska urodzaju” – człowiek często pozostaje bez decyzji. Akurat rozmawiałem z Marcinem od Was i wiem, że u Was nie ma tego wyzwania. Natomiast z Twojej perspektywy, tej ścieżki zawodowej – zaczynałeś jako analityk internetowy, więc pewnie Tobie jest łatwiej oceniać, które źródła są właściwe. Jak oceniasz ten nadmiar danych z perspektywy czasu?

Michał Węglewicz: Myślę, że jeśli chodzi o nadmiar danych, to kiedyś mówiliśmy o zjawisku Big Data, teraz to ewoluowało w stronę AI i modeli probabilistycznych. Wydaje mi się, że im więcej danych, tym lepiej. Do tej pory nie miałem chyba sytuacji, żeby danych było za dużo – raczej w drugą stronę, chciałoby się mieć ich jeszcze więcej. Kreatywność w podejściu pozwala wymyślać coraz to nowe rozwiązania. Zgadzam się jednak, że istnieje ryzyko „klęski urodzaju”, szczególnie gdy mnogość danych rzutuje na bardzo dużą liczbę metryk, którymi będziemy starali się zarządzać biznesem i podejmować decyzje.

To jest krytyczne powiązanie. Nie tyle skala danych może być bolączką, co umiejętność ich interpretacji i sposób zarządzania wiedzą. Z każdego punktu możemy wyciągnąć jakiś insight, więc kluczowe jest zbudowanie sieci metryk w taki sposób, aby finalnie móc sfokusować się na tych najważniejszych. Zbyt duża dywersyfikacja nie będzie efektywna i rodzi ryzyko, że nie skupimy się na tym, co realizuje przysłowiowe 80% impaktu. Często spotykamy się z sytuacjami, gdzie rozpoczynamy projekt, obudowujemy go KPI-ami i sami musimy siebie ograniczać: „Hej, stop, może to już za dużo. Skupmy się na tym, żeby projekt mógł iść do przodu”. Warto wyznaczyć sobie granicę.

Ekonometria w praktyce: Przejście z Last Click na MMM

Dlaczego model atrybucji Last Click przestał wystarczać?

Mariusz Michalczuk: Wspomniałeś o decydowaniu o miksie marketingowym. Czytałem opisany w sieci case waszego modelowania MMM (Marketing Mix Modeling). Czy mógłbyś odsłonić kuluary? Co do zasady, każdy model poza Last Click jest z reguły lepszy, ale jak to wyglądało u Was? To duży projekt, trzeba było przekonać właścicieli budżetu. Jakie były efekty?

Michał Węglewicz: Zgadzam się, że kwestia decydentów i zmiany mindsetu bywa krytyczną barierą. W Traveliście od zawsze mieliśmy do czynienia z mocnym podejściem last clickowym i wciąż na to patrzymy. Jednak stosowanie tylko jednego modelu rodzi ryzyko braku efektywności i braku należytej oceny poszczególnych kanałów. Co do Media Mix Modelingu, czy też ekonometrii, historycznie wykorzystywaliśmy to głównie do oceny dużych kanałów, takich jak telewizja, oraz do oceny naszego baseline’u – czyli tego, co działoby się z marką po wyłączeniu działań reklamowych. Widzieliśmy mocny wpływ optymalizacji kampanii telewizyjnych na wyniki.

W ramach migracji narzędzi analitycznych pojawiła się potrzeba większej stabilności w ocenie działań digitalowych. Poza wsparciem incydentalnym, na co dzień bazowaliśmy na danych last clickowych czy first clickowych. Potrzebowaliśmy rozwiązania in-house, które byłoby stabilne i dawało taki sam obraz niezależnie od czynników zewnętrznych (np. cookie restrictions). Dodatkowo, jako spółka chcąca rosnąć, szukaliśmy „sweet spotu” pomiędzy inwestycjami w działania top-funnelowe (zasięgowe) a utrzymaniem wysokiej efektywności. W Travelist nigdy nie patrzymy na jeden KPI – weryfikujemy ROI, kontrybucję do GP (Gross Profit) oraz bardzo ważną dla nas metrykę Lifetime Value (LTV).

Postanowiliśmy zrobić pilotażowy projekt, wykorzystując metodykę używaną do telewizji, aby ją zdigitalizować. Chcieliśmy sprawdzić potencjalne efekty. Zyskaliśmy dzięki temu nową perspektywę. Zaczęliśmy małymi krokami wchodzić głębiej, w poszukiwaniu bardziej obiektywnego obrazu niż Last Click. Proces wiązał się z wieloma wyzwaniami, głównie w zakresie standaryzacji danych z różnych źródeł: adserwery, platformy reklamowe (Meta, YouTube, Google), dane transakcyjne, a także aspekt contentowy (Magazyn Travelista). Proces ten trwał wiele miesięcy, ale doszliśmy do iteracji, które odbywają się nawet trzy razy w miesiącu. To duża skala. Oczywiście, decyzje dzienne wykonujemy nadal w oparciu o bieżące dane, ale MMM jest dla nas „boosterem decyzyjnym”, pozwalającym szybciej reagować i przewidywać zjawiska rynkowe, co w branży tak sezonowej jak travel jest kluczowe.

Mariusz Michalczuk: Rozumiem, że na początku wykorzystano model zrobiony na „starych mediach”. Czy ten model był rozszerzony o dane online’owe, czy zrobiliście zupełnie oddzielny dla online’u?

Michał Węglewicz: Jeśli chodzi o zakres danych, dochodziła tutaj bardzo duża granularność. Wcześniej rozróżnialiśmy cały digital na kilka głównych worków (SEM, Meta, etc.). Chcieliśmy wejść głębiej i rozdzielać kanały na poszczególne kampanie. Dziś na samej Mecie nie optymalizujemy dwóch czy trzech kampanii, ale dziesiątki, a w sezonie nawet setki. Istotne było wprowadzenie odpowiedniej granulacji, ale też zadbanie o skalę danych – jeśli kampania była zbyt mała, model nie wyłapywał jej wpływu.

Korzystamy ze wsparcia dedykowanych osób przy przeliczaniu modelu. Co ciekawe, to nie jest jeden stały model. To zbiór funkcji bazujących na szeregach czasowych. Za każdym razem model jest trochę inny – weryfikujemy setki, a nawet tysiące różnych funkcji i zbiorów, a wyniki jakości określają, który z modeli w danej iteracji sprawdził się najlepiej. Każdorazowo modyfikujemy to w poszukiwaniu najbardziej precyzyjnych odpowiedzi.

Case study: Jak dane uratowały influencer marketing

Wykorzystanie MMM do oceny zwrotu z inwestycji

Mariusz Michalczuk: Ekonometria nie jest prosta. Jak w marketingu faktycznie wykorzystujecie ten model? Do sprawdzania scenariuszy, czy do oceny faktycznego zwrotu z inwestycji?

Michał Węglewicz: Weryfikujemy to głównie w oparciu o efektywność: ROI per kampania/kanał oraz kontrybucję do marży. Decyzje to miks danych z raportu ekonometrii, raportu lastclickowego oraz raportu Cohort (analiza LTV i zachowań bazy). Mniejsze optymalizacje bazują na doświadczeniach wypracowanych w MMM – jesteśmy w stanie przewidzieć, jak kanały zachowają się po zmianach budżetowych. W dziennym ujęciu weryfikujemy Last Click, ale staramy się nie podejmować w nim pochopnych decyzji dla kanałów top-funnelowych.

Przywołam ciekawy case. Dzięki MMM zobaczyliśmy, że display i inne kanały zasięgowe zyskały na atrybucji. Nie oznaczało to jednak bezmyślnego skalowania, ale wejście głębiej i optymalizację. Najbardziej zaskoczył nas influencer marketing. Mamy tam mocny fanbase. Wzmocniliśmy ten obszar na Instagramie, angażując większe budżety, bo ekonometria pokazała tam potencjał. Po kilku miesiącach doszliśmy do momentu, gdzie nawigowaliśmy w oparciu o wyniki z ekonometrii, ale jednocześnie słuchaliśmy influencerów. Oddaliśmy im inicjatywę, np. dogrywając oferty hotelowe pod ich rekomendacje. Wyniki przerosły oczekiwania. Nie tylko zmaksymalizowaliśmy wyniki w ekonometrii, ale osiągnęliśmy rentowność w Last Clicku, co wcześniej się nie zdarzało. To był case, gdzie zawróciliśmy koło: od słabej efektywności Last Click, przez inwestycję na bazie MMM, po optymalizację dającą wynik w Last Clicku.

Mariusz Michalczuk: To mega ciekawe. Dane ekonometryczne pozwoliły Wam docenić influencer marketing, który co do zasady działa jak branding i nie wpływa bezpośrednio na sprzedaż w modelu ostatniego kliknięcia. Dzięki wskazówce z MMM zainwestowaliście więcej, co przełożyło się finalnie na twarde wyniki.

Michał Węglewicz: Dokładnie. Mieliśmy argumenty, żeby inwestować więcej w kanały, które potencjalnie wpadały w pułapkę lastclickową. Teraz pracujemy nad tym, żeby to skalować.

Synergia Digitalu i CRM: Oszczędność budżetu

Personalizacja i wykluczanie w oparciu o dane

Mariusz Michalczuk: Przesuńmy się na użytkownika w CRM. Jak wykorzystujecie dane do personalizacji w serwisie i czy przekłada się to na marketing?

Michał Węglewicz: W Traveliście traktujemy digital i CRM jako jeden spójny ekosystem. W idealnym świecie digital pozyskuje ruch, a CRM go monetyzuje. Realia nie są tak czarno-białe, ale część wspólna jest wyraźna. Priorytetem integracji było priorytetyzowanie działań in-house’owych (CRM), czyli „niedopalanie” dodatkowego kosztu marketingowego do użytkowników, którzy są już „wygrzani” i skonwertują bez reklamy. Dzięki temu zredukowaliśmy koszty marketingu o 15% przy tym samym efekcie końcowym.

Pracowaliśmy nad wykluczeniami i priorytetyzacją CRM oraz nad lookalike’ami. Analiza ścieżek pokazała, że duży procent użytkowników pokrywa się w działaniach remarketingowych i CRM, ale jest też grupa, która potrzebuje dodatkowego bodźca (display, mailing zewnętrzny). Wdrożyliśmy scoring określający prawdopodobieństwo konwersji użytkownika. Dzięki temu selektywnie podchodzimy do komunikacji.

W ramach grupy Secret Escapes stworzyliśmy modele probabilistyczne: jeden silnik do zwiększania engagementu (inspiracja), drugi do domykania konwersji (low funnel). Bazując na danych z całej grupy, wskazujemy szereg zachowań świadczących o gotowości do zakupu. Testy w CRM wykazały, że dobór ofert przez model versus nasz ręczny wybór „topowych ofert” zawsze wygrywał. W fazie testów mieliśmy nawet 40% poprawy konwersji. To był duży game changer.

Perspektywa międzynarodowa: Różnice między rynkami

Mariusz Michalczuk: Czy jest różnica w podejściu do danych międzynarodowo? Czy są różnice w narzędziach lub zachowaniach użytkowników?

Michał Węglewicz: Dzięki byciu częścią grupy Secret Escapes mamy dostęp do tych samych, zaawansowanych narzędzi (Snowflake, Salesforce, płatna wersja Analytics). Dane są wystandaryzowane. Różnice wynikają głównie z rynków. Restrykcje prawne (Brexit vs UE) są odczuwalne, ale wdrożenia typu Consent Mode były podobne wszędzie. Zauważyliśmy jednak inną charakterystykę klienta – u nas brak akceptacji cookies to ok. 10-15%, na niektórych rynkach zachodnich sięga to 30-40%.

Istotną różnicą jest wrażliwość na cenę. Travelist to rynek polski, mocno rodzinny, wrażliwy cenowo (price sensitivity). Secret Escapes (Niemcy, UK) stawia na luksusowe doświadczenia („co zyskam za tę cenę”). Rynek reklamowy w UK jest też znacznie droższy – stawki potrafią być 3-4 razy wyższe. Dzielimy się insightami w ramach hubów analitycznych. Ciekawym przykładem był TikTok – koledzy z innego rynku zainspirowali nas do zniesienia barier contentowych i wejścia w ten kanał, co przyniosło świetne rezultaty, mimo że początkowo wydawało się trudne.

Sztuczna inteligencja w Travelist

Praktyczne zastosowanie modeli AI w e-commerce

Mariusz Michalczuk: Nie mogę nie zapytać o AI. W jakim zakresie wykorzystujecie sztuczną inteligencję?

Michał Węglewicz: Nasze modele probabilistyczne powstały na silnikach zbliżonych do GPT jeszcze zanim stało się to tak popularne. Obecnie, poza standardowym wykorzystaniem AI (analiza danych, kreacje), pracujemy nad sposobem dobierania najbardziej atrakcyjnego zdjęcia produktu (hotelu) dla użytkownika. Każdy obiekt ma mnóstwo zdjęć. Okazuje się kluczowe, które zdjęcie będzie tym „pierwszym”, które skupi uwagę. Wykorzystujemy dane behawioralne, by wprowadzić taką selekcję. Wcześniej robiliśmy to ręcznie (np. zmiana zdjęć na zimowe). Teraz AI pomaga nam zarządzać grafikami dla 800-1000 obiektów, co wpisuje się w domenę „Work Smarter”. AI pomaga też w inteligentnym sortowaniu ofert, co ma duży wpływ na konwersję.

Rady dla marketerów: Single Source of Truth i LTV

Mariusz Michalczuk: Zmierzając do końca, jakie masz rady dla osób z marketingu i e-commerce, aby popychać organizację do wykorzystania danych?

Michał Węglewicz: Podejście oparte o dane ma wiele plusów. Kluczowe jest doprowadzenie do sytuacji, w której mamy w organizacji jedno źródło prawdy (Single Source of Truth). Gdy wszyscy patrzą na te same, jakościowe dane, dyskusja staje się wartościowa, a argumenty oparte na liczbach są niepodważalne. Druga sprawa to zdefiniowanie kluczowych metryk. Nie można wpaść w pułapkę analizowania wszystkiego. Należy skupić się na kilku najważniejszych.

Poza Revenue, ROI czy EBIT, bardzo ważną, a często niedocenianą metryką jest Lifetime Value (LTV). Branża travel wygrywa wtedy, gdy użytkownik wraca. Inwestycja musi się zwrócić w czasie. Rekomenduję wdrożenie perspektywy LTV do codziennego raportowania. I na koniec – sztuka szukania synergii. Połączenie performance’u z CRM to ukryta wartość, gdzie można znaleźć dźwignie do skalowania i optymalizacji kosztowej.

Podsumowanie: Główne wnioski z rozmowy

Kluczowe lekcje dla analityków i marketerów

Rozmowa z Michałem Węglewiczem pokazuje ewolucję roli danych w nowoczesnym e-commerce. Przejście od prostych analiz do zaawansowanych modeli ekonometrycznych (MMM) pozwala firmom takim jak Travelist na podejmowanie trafniejszych decyzji inwestycyjnych, wykraczających poza ograniczenia atrybucji Last Click. Przykład influencer marketingu udowadnia, że działania budujące świadomość mogą być rentowne, jeśli są odpowiednio mierzone i optymalizowane.

Istotnym wątkiem jest synergia między działaniami płatnymi a CRM. Dzięki wykorzystaniu scoringu i modeli probabilistycznych, firma może oszczędzać budżet, nie wyświetlając reklam użytkownikom, którzy i tak by dokonali zakupu, oraz precyzyjniej targetować komunikaty. Wykorzystanie AI do automatyzacji doboru treści wizualnych to kolejny krok w stronę efektywności „Work Smarter”.

Główna rada dla organizacji to dążenie do posiadania jednego, wiarygodnego źródła danych oraz skupienie się na metrykach długoterminowych, takich jak Lifetime Value, zamiast wyłącznie na bieżącym zwrocie z inwestycji.

The post Dane w marketingu Travelist.pl – Michał Węglewicz – Date with Data Talks first appeared on Conversion.

W tym artykule omówiono, czym są testy A/B, dlaczego mają znaczenie oraz jak je przeprowadzać. Przedstawione zostaną również narzędzia wspierające testowanie i analiza wyników. Na zakończenie znajdziesz odpowiedzi na najczęściej zadawane pytania dotyczące optymalizacji współczynnika konwersji. W analizie danych online kluczowe jest nie tylko ich zbieranie, ale także właściwa interpretacja i skuteczne wykorzystanie w biznesie. W tym artykule przedstawiona zostanie struktura procesu analizy oraz porównanie narzędzi do testów A/B.

Osoby zainteresowane konkretnymi zagadnieniami, takimi jak porównanie narzędzi do testów A/B, mogą skorzystać z nawigacji lub spisu treści. W artykule pojawią się również odniesienia do innych materiałów, których pełna lista wraz z linkami znajduje się na końcu wpisu. Wprowadzanie małych zmian w serwisach e-commerce może przynieść znaczące korzyści. Przykładem jest historia dużego e-commerce z branży fashion, który zbudował silną markę i bazę lojalnych klientów.

Wprowadzenie
Testy A/B – Podstawa analizy konwersji
Małe zmiany vs redesign
Sezonowość i analiza wyników
Jak AI napędzana autoadaptacją zmienia przyszłość testów A/B?
Rodzaje testów
Jakie narzędzia wykorzystać do testów A/B?
Testy AA i AB – jak działają i jakie korzyści przynoszą?
Korzyści z testów A/B w serwisie internetowym
Podsumowanie

Wprowadzenie

Analiza współczynnika konwersji w serwisach e-commerce często prowadzi do błędnych wniosków. Zmiany w danych mogą wynikać z wielu czynników, które niekoniecznie są związane z samą stroną internetową. Jak zatem sprawdzić, czy wprowadzone modyfikacje rzeczywiście wpływają na współczynnik konwersji? Kluczową metodą są testy A/B.

W tym artykule omówiono, czym są testy A/B, dlaczego mają znaczenie oraz jak je przeprowadzać. Przedstawione zostaną również narzędzia wspierające testowanie i analiza wyników. Na zakończenie znajdziesz odpowiedzi na najczęściej zadawane pytania dotyczące optymalizacji współczynnika konwersji. W analizie danych online kluczowe jest nie tylko ich zbieranie, ale także właściwa interpretacja i skuteczne wykorzystanie w biznesie. W tym artykule przedstawiona zostanie struktura procesu analizy oraz porównanie narzędzi do testów A/B.

Osoby zainteresowane konkretnymi zagadnieniami, takimi jak porównanie narzędzi do testów A/B, mogą skorzystać z nawigacji lub spisu treści. W artykule pojawią się również odniesienia do innych materiałów, których pełna lista wraz z linkami znajduje się na końcu wpisu. Wprowadzanie małych zmian w serwisach e-commerce może przynieść znaczące korzyści. Przykładem jest historia dużego e-commerce z branży fashion, który zbudował silną markę i bazę lojalnych klientów.

Testy A/B – Podstawa analizy konwersji

Testy A/B są wykorzystywane do sprawdzania skuteczności zmian wprowadzanych na stronie internetowej. Użytkownicy odwiedzający serwis są losowo dzieleni na dwie grupy: kontrolną (wersja A), w której nic się nie zmienia, oraz testową (wersja B), w której wprowadzane są modyfikacje podlegające analizie. Każdy użytkownik, który trafi do jednej z tych grup, zostaje przypisany do konkretnej wersji za pomocą plików cookie. Dzięki temu, jeśli wróci na stronę w trakcie trwania testu, zobaczy tę samą wersję, co wcześniej.

Dla obu grup rejestrowane są kluczowe metryki, w szczególności współczynnik konwersji, który jest głównym wskaźnikiem skuteczności zmian. Analiza wyników testu A/B pozwala określić, która wersja lepiej wpływa na użytkowników. Ponieważ zarówno wersja A, jak i wersja B funkcjonują w tych samych warunkach, podejście to opiera się na zasadzie ceteris paribus – przy założeniu, że wszystkie inne czynniki pozostają bez zmian. Wszystkie pozostałe elementy, takie jak kampanie marketingowe, pozostają identyczne we wszystkich wersjach. Jedyną różnicą jest testowana zmiana.

Małe zmiany vs redesign

Właściciele firmy przez lata rozwijali biznes, opierając go na stałych klientach. Podczas jednej z konferencji jeden z właścicieli usłyszał o nowych trendach w projektowaniu stron internetowych. Po wydarzeniu uznał, że konieczny jest redesign serwisu.

Firma i tak planowała migrację na Magento, dlatego zdecydowano, że przy tej okazji zostanie przeprowadzony pełny redesign sklepu. Założeniem było zwiększenie współczynnika konwersji o 15%. Założono, że projekt potrwa 8 miesięcy, a jego budżet wyniesie 850 tys. zł. W praktyce przebiegł inaczej. Na początku współczynnik konwersji spadł z 2,3% do 1,2% i utrzymywał się na tym poziomie przez kilka dni. Z czasem zaczął rosnąć, ale dopiero po kilku miesiącach wrócił do wartości wyjściowej.

Projekt zakończył się po 14 miesiącach zamiast planowanych 8, a budżet został znacznie przekroczony, osiągając 1 150 000 zł. Czy można uznać to za sukces? Zdecydowanie nie. Redesign rzadko kończy się sukcesem, ponieważ to rewolucyjna zmiana, a użytkownicy zazwyczaj nie lubią radykalnych modyfikacji. Lepszym podejściem do rozwoju serwisu jest wdrażanie małych zmian. Taką strategię stosował przez lata Amazon, uznawany w branży za pioniera prawidłowego podejścia do rozwoju serwisów internetowych.

Charakterystyczną cechą tego podejścia jest wprowadzanie i testowanie wielu drobnych zmian. Zanim jakakolwiek modyfikacja zostanie wdrożona, przechodzi przez testy. Można je określić jako podejście ewolucyjne, w przeciwieństwie do rewolucyjnego.

Takie działanie ma wiele zalet. Przede wszystkim pozwala na pełną kontrolę nad wprowadzanymi zmianami i precyzyjne ulepszanie konkretnych elementów serwisu. Małe zmiany ułatwiają identyfikację, które rozwiązania działają na użytkowników, a które nie. Dodatkowo umożliwiają kontrolowanie i izolowanie wpływu innych zmiennych, które mogą jednocześnie oddziaływać na skuteczność testowanego elementu. Drugim powodem jest szybkość wdrożenia i analizy. Małe zmiany można wprowadzać znacznie szybciej, podczas gdy duże projekty trwają miesiącami, często przekraczając terminy i budżety. Krótszy czas trwania testu pozwala na szybsze gromadzenie danych i wyciąganie wniosków, co zwiększa elastyczność i umożliwia sprawniejsze wprowadzanie poprawek.

Po trzecie, wdrażanie małych zmian minimalizuje ryzyko. Jeśli rekomendacja okaże się nietrafiona, można ją przetestować na ograniczonej grupie użytkowników, a następnie poprawić lub całkowicie wycofać. Dzięki temu nie ponosi się wysokich kosztów alternatywnych, które mogłyby wystąpić przy wdrażaniu dużych zmian.

Mniejsze zmiany ułatwiają również zarządzanie zasobami. Krótszy czas wdrożenia oznacza mniejsze zaangażowanie zespołu i niższe nakłady pracy. Wiele z tych modyfikacji można przeprowadzić za pomocą edytorów typu WYSIWYG (What You See Is What You Get), które są dostępne w większości narzędzi do testów A/B. Dzięki nim można samodzielnie testować różne elementy strony bez konieczności angażowania zespołu deweloperskiego.

Ostatecznie, podejście to wspiera proces ciągłego doskonalenia. Regularne wprowadzanie drobnych zmian pozwala na większą elastyczność i szybsze reagowanie na potrzeby użytkowników.

Sezonowość i analiza wyników

Sklepy internetowe często doświadczają znaczących wahań sprzedaży w zależności od pory roku. Pierwszy ciepły weekend nie zawsze oznacza wzrost przychodów, a zmiany wprowadzone poza sezonem mogą prowadzić do błędnych wniosków dotyczących ich skuteczności.

Przykładowo, jeśli sklep rowerowy wdraża zmiany zimą i porównuje wyniki sprzedaży po nadejściu wiosny, wzrost współczynnika konwersji może wynikać nie tyle z wprowadzonych usprawnień, co z naturalnego sezonowego wzrostu zainteresowania rowerami.

Poniżej przedstawione są dwa wykresy z Universal Analytics. Pierwszy z nich porównuje listopad z grudniem, kiedy w serwisie nie wprowadzono żadnych zmian. Wzrost współczynnika konwersji wyniósł 69%, co wynikało z sezonowego zwiększenia aktywności zakupowej przed świętami. Drugi wykres pokazuje ten sam okres rok do roku, gdzie wzrost wyniósł 26%, mimo że w serwisie nie dokonano żadnych modyfikacji.

Aby eliminować wpływ czynników zewnętrznych na ocenę skuteczności zmian w serwisie, stosuje się testy A/B. Pozwalają one na rzetelną analizę wpływu nowych rozwiązań na wyniki sprzedaży.

Jak AI napędzana autoadaptacją zmienia przyszłość testów A/B?

Nowe narzędzia eksperymentalne z 2025 roku pokazują, że wartość testów A/B rośnie, gdy dodamy do nich AI. Algorytmy potrafią dziś generować warianty, automatycznie dobierać grupy użytkowników oraz dynamicznie alokować ruch – co przyspiesza testy i zwiększa ich skuteczność.

Autoadaptacyjne testy i uczenie się z wielu eksperymentów jednocześnie

Nowe ramy badawcze – jak zaproponowany w 2025 AgentA/B – pozwalają symulować zachowania użytkowników za pomocą modeli LLM, co umożliwia testy nawet bez realnego ruchu. Dzięki temu małe serwisy czy aplikacje o niskim ruchu mogą testować więcej wariantów szybciej i taniej – adaptując interfejs w locie.

Rodzaje testów

Podstawową metodą są testy A/B, w których jedna wersja serwisu pozostaje niezmieniona (wersja kontrolna), a druga zawiera testowaną modyfikację. Można również rozszerzyć testy o kolejne warianty, oznaczając je literami C, D itd.

Innym podejściem są testy multiwariacyjne, w których analizowane są różne sekcje serwisu. Każda sekcja może mieć kilka wariantów, a ich kombinacja pozwala na dokładniejsze określenie, które zmiany mają największy wpływ na konwersję.

Dzięki testowaniu możliwe jest podejmowanie lepiej uzasadnionych decyzji opartych na danych, zamiast na sezonowych wahaniach sprzedaży. Testy multiwariacyjne są rzadziej stosowane, częściej pojawiają się na landing page’ach z dużym ruchem kampanijnym. Wymagają one znacznej liczby użytkowników, ponieważ im więcej wersji alternatywnych, tym większa próba jest potrzebna do uzyskania wiarygodnych wyników.

Istnieją również testy ścieżki, w których analizowana jest cała sekwencja działań użytkownika. Na przykład, jeśli testowany jest cały proces checkout, losowanie wersji odbywa się na poziomie wejścia do koszyka. Wówczas jedna ścieżka obejmuje oryginalny zestaw adresów URL, a druga – wersję testową.

Wyróżnia się testy client-side i server-side. W testach client-side informacja o wersji, którą użytkownik otrzymał, jest zapisywana w ciasteczku. Może jednak zobaczyć inną wersję, jeśli wyczyści pliki cookie lub zmieni urządzenie. To potencjalna wada tego podejścia, choć jej wpływ jest ograniczony, ponieważ testy powinny trwać przez określony czas, a liczba użytkowników zmieniających urządzenie lub czyszczących ciasteczka w trakcie testu jest niewielka.

Testy server-side pozwalają na zapisanie wersji testu w bazie danych, co jest szczególnie przydatne w serwisach wymagających logowania. Dzięki temu użytkownik, który musi się zalogować, zawsze widzi tę samą wersję, którą otrzymał na początku testu.

Losowy przydział wersji eliminuje wpływ wszystkich czynników poza tym, który jest testowany, co zapewnia rzetelność wyników. Aby skutecznie ocenić, czy wprowadzane zmiany działają, warto testować pojedyncze modyfikacje. Przy niewielkim ruchu w serwisie jedna zmiana może jednak nie przynieść wystarczającej różnicy, by określić jej statystyczną istotność.

Jakie narzędzia wykorzystać do testów A/B?

Dawniej Google oferowało kilka narzędzi do testów A/B. Początkowo był to Google Website Optimizer, później eksperymenty Content Experiment w Google Analytics. Przez pewien czas brakowało dedykowanego rozwiązania, aż pojawił się Google Optimize. Jednak około 2,5 roku temu został on całkowicie wycofany, co oznacza, że obecnie Google nie oferuje darmowego narzędzia do testów A/B.

Obecnie na rynku dostępnych jest ponad 100 narzędzi do testów A/B. Najpopularniejsze, z których korzystają nasi klienci, to Visual Website Optimizer, Optimizely, AB Tasty i Convert.

Przygotowaliśmy porównanie tych narzędzi. Link do zestawienia znajduje się w opisie – aby uzyskać dostęp, wystarczy podać adres e-mail. W zestawieniu omówiono funkcje poszczególnych narzędzi, co ułatwia wybór najlepszego rozwiązania. Aby oszacować koszt narzędzia w zależności od ruchu na stronie, można skorzystać z kalkulatora. Zmiana średniej liczby użytkowników potrzebnych do jednego testu pozwala określić miesięczne obciążenie finansowe związane z danym narzędziem. Dodatkowo w zakładkach znajdują się wyjaśnienia poszczególnych elementów porównania, co ułatwia podjęcie decyzji o wyborze odpowiedniego rozwiązania.

Warto jednak zaznaczyć, że wybór narzędzia to drugorzędna kwestia w procesie optymalizacji współczynnika konwersji. Kluczowe są analiza danych i wdrażanie zmian, które wynikają z tych analiz.

Wielu klientów, zwłaszcza ci, którzy obawiają się wysokich kosztów, decyduje się na budowę własnych rozwiązań. Własne systemy są tańsze w utrzymaniu, ponieważ eliminują koszty związane z obsługą zewnętrznych narzędzi. Implementacja takich narzędzi jest bardziej wymagająca, ponieważ wymaga wsparcia zespołu IT. Po pierwsze, konieczne jest stworzenie systemu losowania, a następnie zakodowanie szablonów lub innych elementów do testowania. Z tego względu rozwiązania te są częściej wybierane przez firmy o wyższym poziomie dojrzałości analitycznej, które regularnie przeprowadzają testy A/B.

Czym jest dojrzałość analityczna? To poziom zaawansowania organizacji w zakresie analizy danych, w tym umiejętność skutecznego wykorzystywania testów A/B.

Tworząc własne narzędzie do testowania, kluczowe jest uwzględnienie dwóch czynników: odpowiedniej wielkości próby oraz losowości doboru użytkowników. Aby upewnić się, że system działa poprawnie, warto regularnie przeprowadzać testy AA, które pozwalają zweryfikować, czy losowanie grup testowych przebiega prawidłowo.

Testy AA i AB – jak działają i jakie korzyści przynoszą?

Test AA polega na losowym przypisaniu użytkowników do dwóch identycznych wersji serwisu – wersji A oraz… wersji A. Obie grupy widzą dokładnie ten sam wariant strony, a różnice w metrykach między nimi nie powinny występować.

Dzięki temu można zweryfikować, czy mechanizm losowego przydzielania użytkowników do grup działa poprawnie. Jeśli test nie wykazuje istotnych statystycznie różnic między grupami, oznacza to, że system losowania działa prawidłowo i nie wpływa na wyniki późniejszych testów A/B.

Korzyści z testów A/B w serwisie internetowym

Często pojawia się pytanie, czy testy A/B prowadzą do wzrostu współczynnika konwersji. W rzeczywistości sam test A/B nie powoduje tej zmiany – wzrost konwersji jest wynikiem wprowadzenia skutecznej modyfikacji na stronie.

Proces optymalizacji rozpoczyna się od analizy danych, na podstawie których formułowane są rekomendacje. Testy A/B pozwalają następnie zweryfikować, czy zaproponowane zmiany rzeczywiście poprawiają wyniki. Ich kluczową rolą jest więc potwierdzenie skuteczności rekomendacji i eliminacja ryzyka wprowadzania zmian, które mogłyby negatywnie wpłynąć na konwersję. Można spojrzeć na to z innej perspektywy – czy nadal osiągamy korzyści, jeśli test zakończy się niepowodzeniem? Nelson Mandela mawiał: „Nigdy nie przegrywam. Albo wygrywam, albo się uczę.” To podejście dobrze oddaje istotę analizy danych i testów A/B.

Jeśli wprowadzamy zmianę na stronie i przeprowadzamy test A/B, a nowa wersja okazuje się mniej skuteczna od oryginalnej, nie jest to porażka, lecz cenna lekcja. Otrzymujemy jasny sygnał, że dana modyfikacja nie powinna zostać wdrożona w obecnej formie i wymaga dalszej pracy.

Trudno czasem wyjaśnić tę ideę osobom na wyższych szczeblach organizacji. Można jednak zwrócić uwagę na alternatywny scenariusz – gdyby zmiana została wdrożona bez testowania, mogłaby negatywnie wpłynąć na współczynnik konwersji, generując znaczące koszty. Testowanie pozwala uniknąć takich błędów i podejmować decyzje oparte na danych, a nie przypuszczenia. Idealny test A/B powinien trwać od 10 do 14 dni, jednak nie dłużej niż 4 tygodnie. Wiarygodność testu A/B oznacza, że uzyskana różnica jest statystycznie istotna.

Aby sprawdzić statystyczną istotność wyników, można skorzystać z dostępnych kalkulatorów, które umożliwiają wprowadzenie odpowiednich parametrów testu i ocenę wyników.

Czy test A/B może negatywnie wpłynąć na działanie sklepu? W przypadku gotowych narzędzi do testowania nie ma powodów do obaw. Jeśli jednak testy są prowadzone za pomocą własnego systemu losowania i podmiany wersji, szczególnie na różnych URL-ach, należy zadbać o odpowiednią konfigurację indeksowania. Warto wówczas zastosować parametry noindex i nofollow, aby zapobiec niepożądanym efektom w wynikach wyszukiwania. Szczegóły warto konsultować ze specjalistami od SEO.

Które elementy sklepu internetowego najlepiej testować? Nie ma jednej uniwersalnej odpowiedzi. Analizę warto rozpocząć od danych ilościowych.

Podczas targów handlowych przedstawiałem prezentację na temat wykorzystania GA4 do optymalizacji konwersji. Link do niej znajduje się poniżej. Opisałem w niej trzy raporty, które pozwalają szybko zidentyfikować obszary do optymalizacji współczynnika konwersji (tzw. low-hanging fruits). Dane ilościowe stanowią punkt wyjścia, a kolejne etapy analizy pozwalają na dalsze usprawnienia. Analiza ilościowa wskazuje, gdzie występuje problem, natomiast dane jakościowe pozwalają zrozumieć jego naturę i sformułować konkretne rekomendacje.

Podsumowanie

Testy A/B to jedno z najskuteczniejszych narzędzi do weryfikacji, czy planowane zmiany w serwisie wpływają pozytywnie na użytkowników i poprawiają jego efektywność. Warto korzystać z tego podejścia, aby podejmować decyzje oparte na danych. Każda większa modyfikacja, zanim zostanie wdrożona, powinna zostać zweryfikowana, aby uniknąć negatywnego wpływu na konwersję i kosztów alternatywnych wynikających z gorszego wyniku nowej wersji.

Analiza danych i odpowiednio przeprowadzone testy A/B pozwalają lepiej zrozumieć zachowania użytkowników oraz skutecznie optymalizować proces sprzedaży. Pamiętajmy, że nawet negatywny wynik testu dostarcza cennych informacji, które przyczyniają się do dalszego rozwoju serwisu. Dzięki temu możliwe jest ciągłe doskonalenie strategii marketingowych i zwiększanie efektywności działań w internecie.

Dziękuję za uwagę. Jeśli uważasz ten materiał za wartościowy, podziel się nim z innymi, których może zainteresować.

The post Testy A/B w e-commerce – kompletny przewodnik + porównanie narzędzi do testów A/B first appeared on Conversion.

Dlaczego Redesign jest ryzykowny?
Jak przygotować się do redesignu serwisu z perspektywy analityki?
Jak podejść do analizy przed redesignem?
Jak uniknąć negatywnych reakcji użytkowników po wdrożeniu redesignu?
Podsumowanie

Dlaczego Redesign jest ryzykowny?

Analizując dane z kilkunastu redesignów, można zauważyć, że współczynnik konwersji po wprowadzeniu dużych zmian zazwyczaj początkowo spada. Współczynnik konwersji różni się w zależności od tego, czy użytkownik jest nowy, czy powracający. Każdy użytkownik przechodzi przez proces zakupowy, który często obejmuje kilka wizyt w serwisie przed podjęciem decyzji o finalnym zakupie.

Czas od pierwszej wizyty do transakcji zależy od stopnia skomplikowania produktu. Im bardziej złożony produkt i większa potrzeba zdobycia informacji, tym dłuższy proces decyzyjny. W przypadku prostszych produktów decyzja zakupowa zapada szybciej.

Lejek zakupowy i proces zakupowy były omawiane w kontekście optymalizacji budżetu marketingowego. W jednym z wcześniejszych materiałów przedstawiono, jak wykorzystać dane do efektywnego zarządzania budżetem marketingowym. W zależności od etapu procesu zakupowego, na którym znajduje się użytkownik, należy uwzględniać różne metryki. Analiza współczynnika konwersji dla nowych i powracających użytkowników pokazuje, że w większości przypadków powracający użytkownicy mają wyższy współczynnik konwersji. Wynika to z faktu, że są oni na bardziej zaawansowanym etapie procesu zakupowego, co zwiększa prawdopodobieństwo dokonania transakcji.

Podczas redesignu serwisu zmiany obejmują wszystkich użytkowników. Technicznie możliwe jest wdrożenie nowej wersji tylko dla części z nich, jednak standardowo redesign dotyczy całego ruchu. Warto pamiętać, że powracający użytkownicy mogą być zaskoczeni zmianami, co może wpłynąć na ich zachowanie.

W kolejnych częściach artykułu przedstawione zostaną sposoby minimalizowania spadku współczynnika konwersji po wdrożeniu nowej wersji serwisu. Podczas optymalizacji serwisu zoologicznego sprzedającego karmę i akcesoria dla zwierząt pojawiła się interesująca zależność. Sklep dokładnie wiedział, kiedy dany klient powinien ponownie zakupić karmę, co umożliwiało wysyłanie przypomnień w formie newslettera.

Podczas testu A/B nowa wersja serwisu osiągała dobre wyniki, dopóki użytkownicy nie otrzymywali wiadomości e-mail przypominającej o konieczności zakupu. Po wejściu na stronę i zobaczeniu nowego interfejsu testowana wersja przegrywała z oryginalną. Ten przykład pokazuje, jak istotne jest uwzględnienie cyklicznych nawyków zakupowych klientów przy optymalizacji serwisu i analizie wyników testów A/B.

Jak przygotować się do redesignu serwisu z perspektywy analityki?

Redesign wiąże się z dużymi zmianami w serwisie – jednocześnie modyfikowanych jest wiele elementów, co utrudnia ocenę wpływu poszczególnych zmian na wyniki. Gdy metryki ulegają zmianie, trudno jednoznacznie stwierdzić, które działania przyniosły pozytywny efekt, a które nie.

Dodatkowym wyzwaniem jest czas realizacji projektu. Duże zmiany technologiczne często się przedłużają, co może prowadzić do opóźnień i zwiększonych kosztów. Warto więc podejść do redesignu z odpowiednią strategią i uwzględnić testy A/B, aby precyzyjnie mierzyć wpływ poszczególnych zmian na użytkowników i konwersję. Jeśli brałeś udział w takim projekcie, dobrze wiesz, jak przebiega jego realizacja. Projekty związane z redesignem często niosą ze sobą duże ryzyko w obszarze SEO. Lepszym rozwiązaniem jest podejście krokowe, które nazywamy CXO (Conversion Experience Optimization).

W artykule dostępnym pod linkiem można znaleźć szczegółowy opis naszego podejścia do optymalizacji konwersji, które określamy jako CRO 2.0. Proces ten obejmuje między innymi fazy Discovery i Development. W tej fazie kluczowe jest zrozumienie czynników wpływających na doświadczenie użytkownika. W etapie Discovery identyfikowane są problemy i wprowadzane poprawki, które sprawiają, że serwis staje się bardziej funkcjonalny i użyteczny.

Podejście CXO zakłada, że fazy Discovery i Development powinny stanowić powtarzalny proces. Optymalizacja doświadczeń użytkownika powinna być działaniem ciągłym, a nie sporadycznym. Redesign serwisu jest zasadny dopiero wtedy, gdy dalsza optymalizacja nie przynosi już znaczących efektów.

Można to porównać do pojęcia maksimum lokalnego i maksimum globalnego w matematyce. Proces Discovery i Development pozwala na osiąganie kolejnych maksimów lokalnych, czyli stopniowej poprawy doświadczenia użytkownika. Jeśli jednak pojawi się bariera uniemożliwiająca dalszy rozwój, konieczne może być przeniesienie się na inny poziom – wprowadzając redesign, można dążyć do osiągnięcia nowego maksimum globalnego. Redesign serwisu nie zawsze jest konieczny. Często wynika z pojawienia się nowej technologii, która staje się standardem, lub z potrzeby wdrożenia nowej funkcjonalności, takiej jak program lojalnościowy czy rozwój strategii omnichannel w e-commerce.

Jak podejść do analizy przed redesignem?

Sztuczna inteligencja coraz częściej wpływa na sposób wyszukiwania informacji w serwisach internetowych. Silniki wyszukiwarek nie opierają się już wyłącznie na wpisywaniu tekstu – rośnie znaczenie wyszukiwania głosowego (voice search). W kontekście redesignu strony warto uwzględnić te zmiany, ale równie istotne jest odpowiednie przygotowanie pod kątem analityki, aby uniknąć spadków ruchu i konwersji po wdrożeniu nowej wersji serwisu.

Jeśli decyzja o redesignie już zapadła, kluczowe jest przeprowadzenie rzetelnej analizy. Idealnym rozwiązaniem są testy A/B, które pozwalają sprawdzić, jakie zmiany przynoszą pozytywne efekty. Jeśli jednak testy A/B nie były prowadzone, warto przeprowadzić przynajmniej fazę Discovery – etap, który pozwala zebrać dane i zrozumieć, jakie elementy obecnego serwisu wymagają poprawy.

W ramach Discovery warto skupić się na dwóch głównych obszarach:

1. Analiza ilościowa – Google Analytics dostarcza cennych danych na temat zachowań użytkowników, takich jak ścieżki nawigacyjne, współczynnik odrzuceń czy konwersje.

2. Analiza jakościowa – badania użyteczności, testy z użytkownikami oraz inne metody pozwalające zidentyfikować problemy obecnej wersji serwisu i zrozumieć oczekiwania użytkowników.

Po zebraniu danych można przejść do projektowania makiet i opracowania graficznego nowej wersji serwisu.

Jak uniknąć negatywnych reakcji użytkowników po wdrożeniu redesignu?

Dzień wdrożenia nowej wersji serwisu to kluczowy moment. Powracający użytkownicy mogą być zaskoczeni zmianami, co może wpłynąć na ich doświadczenie i decyzje zakupowe. Aby zminimalizować ryzyko negatywnych reakcji:

– Warto wcześniej zaangażować użytkowników w proces redesignu. Dobrym rozwiązaniem jest wysyłanie projektów graficznych do bazy mailingowej i proszenie o feedback. W zamian można zaoferować zniżkę na przyszłe zakupy lub inne korzyści.

– Testowanie nowych rozwiązań na ograniczonej grupie użytkowników pozwala zebrać opinie i wprowadzić ewentualne korekty przed pełnym wdrożeniem.

– Komunikacja zmian na stronie (np. w formie komunikatu dla powracających użytkowników) pomaga uniknąć dezorientacji i poprawia doświadczenie użytkownika.

Dobrze przeprowadzony redesign, oparty na analizie danych i zaangażowaniu użytkowników, zwiększa szanse na pozytywne przyjęcie nowej wersji serwisu i minimalizuje ryzyko spadków w wynikach biznesowych. Redesign serwisu to nie tylko zmiana wizualna, ale także okazja do poprawy doświadczenia użytkowników oraz wdrożenia skutecznej analityki. Istnieje kilka sposobów, które mogą pomóc w przeprowadzeniu tego procesu efektywnie.

Jednym z nich jest zbieranie opinii użytkowników na temat nowej wersji serwisu. Pozwala to nie tylko na poprawę projektów graficznych, ale także na oswojenie użytkowników z nowym wyglądem i funkcjonalnościami.

Kolejną metodą jest umieszczenie przypiętej informacji na górze strony o wprowadzeniu nowej wersji serwisu. Po wejściu na stronę użytkownik otrzymuje jasny komunikat, że korzysta z nowej wersji, a dodatkowo ma możliwość powrotu do poprzedniej wersji.

Ważnym krokiem jest również stopniowe wdrażanie redesignu. Nawet przy dokładnych testach zawsze pojawiają się błędy. Warto udostępnić nową wersję początkowo dla niewielkiej grupy użytkowników, np. 10%, i obserwować ich zachowanie. Kluczowe będzie zbieranie zarówno danych ilościowych, jak i jakościowych, co pozwoli na wykrycie problemów i ich poprawę przed pełnym wdrożeniem.

Testy przeprowadzane na serwerze deweloperskim czy w ramach quality assurance są istotne, ale to realni użytkownicy najlepiej wskażą ewentualne błędy. Dlatego warto zadbać o system zbierania danych, który umożliwi szybkie wykrywanie i rozwiązywanie problemów.

Nowa wersja serwisu to także doskonała okazja do przeglądu i aktualizacji analityki. Często wdrożenie analityki jest pozostawiane na koniec, jednak warto już na etapie redesignu zweryfikować istniejące rozwiązania, przeprowadzić audyt i zoptymalizować system zbierania danych. Nie musi to oznaczać rewolucji, ale przemyślane podejście do analityki pozwoli lepiej monitorować skuteczność nowego serwisu i szybciej reagować na potrzeby użytkowników. Przy planowaniu harmonogramu redesignu warto uwzględnić analitykę internetową nie na samym końcu, lecz przynajmniej w połowie procesu. Po wdrożeniu nowej wersji serwisu kluczowe stają się dane ilościowe dotyczące zachowań użytkowników. Jednak w momencie uruchomienia nowego serwisu priorytetem zwykle jest jego działanie, a kwestie analityczne mogą zostać pominięte.

Lepiej zadbać o dane od samego początku, aby móc szybko reagować i wprowadzać niezbędne poprawki. Szczególnie ważne jest monitorowanie błędów, takich jak strony 404, które mogą stanowić istotny problem dla użytkowników. Śledzenie takich zdarzeń to absolutne minimum w analityce.

Redesign zawsze wiąże się z ryzykiem. Choć jest to ekscytujący projekt, który prowadzi do dużych zmian, warto podejść do niego strategicznie i uwzględnić analitykę na odpowiednim etapie. Redesign serwisu zazwyczaj przynosi dobre rezultaty w dłuższej perspektywie, jednak często w pierwszych dwóch–trzech miesiącach oczekiwania odbiegają od rzeczywistości. To duża zmiana dla użytkowników, a jeśli serwis nie sprzedaje wyjątkowo prostych produktów i proces zakupowy nie jest krótki, początkowy okres po redesignie może być wyzwaniem.

Każda duża zmiana wymaga czasu na adaptację. Podobnie jak przeprowadzka do innego kraju – początkowo może sprawiać trudności, ale w dłuższej perspektywie zazwyczaj przynosi korzyści. Warto pamiętać o odpowiednim podejściu do analityki i wykorzystaniu dostępnych wskazówek, aby proces przebiegł możliwie najłagodniej.

Jeśli masz dodatkowe pytania, zapraszamy do kontaktu lub pozostawienia komentarza.

Podsumowanie

Każda zmiana w serwisie niesie ze sobą ryzyko, ale także szansę na rozwój. Amazon pokazuje, że stopniowe udoskonalanie platformy pozwala unikać gwałtownych spadków konwersji i daje czas na adaptację użytkowników. Przemyślane wdrażanie zmian, oparte na dogłębnej analizie danych, umożliwia osiągnięcie lepszych wyników biznesowych.

Zrozumienie cyklu życia użytkownika oraz specyfiki produktów pozwala zoptymalizować proces zakupowy i minimalizować ryzyko związane z redesignem serwisu. Wdrożenie stopniowych zmian, a nie rewolucyjnych zmian, pozwala na lepsze monitorowanie i szybką reakcję na ewentualne problemy.

Podsumowując, wdrożenie redesignu serwisu wymaga kompleksowego podejścia – od analizy danych, przez testy A/B, aż po ciągły monitoring wyników. Właściwe przygotowanie oraz stopniowe wdrażanie zmian są kluczowe dla osiągnięcia sukcesu i uniknięcia negatywnych konsekwencji.

The post Redesign sklepu internetowego – co mówi analiza danych? first appeared on Conversion.

Widzisz go praktycznie codziennie, gdy tylko postanowisz odwiedzić jakąkolwiek stronę w sieci. Do niedawna zawierał krótką informację o tym, że dany serwis ich używa (ciasteczek) – opatrzoną 1 lub czasami kilka przycisków, które jednak w żaden sposób nie działały. Obecnie, coraz częściej spotykasz się z jego bardziej rozbudowaną wersją – przekazującą nie tylko więcej informacji, ale również dającą Ci realny wybór.

O czym mówię? Oczywiście o cookie banner, który pozwala Ci decydować, jakie informacje oraz w jakiej skali będą przekazywane “dalej” – do narzędzi analitycznych, a następnie – samych właścicieli witryn internetowych. 

Czytaj dalej, aby dowiedzieć się więcej na temat banerów cookies, tego, jak je poprawnie wdrożyć, a przede wszystkim sprawdzić, dlaczego nie tylko „warto”, ale po prostu “trzeba” to zrobić .

Czym jest i do czego służy tzw. cookie banner?
Jak informacje o cookies był traktowane “kiedyś”, a jak podchodzi się do nich “obecnie”?
Cookie Banner a RODO. Co zrobić, jeśli użytkownicy nie wyrażają zgód na pozostałe ciasteczka?
Jak poprawnie wdrożyć Cookie Banner?
Co będzie lepsze? Gotowe narzędzie do cookies czy stworzenie własnego oprogramowania?
Jakie są najpopularniejsze rozwiązania Consent Management Platform (CMP)? Porównanie narzędzi.
Cookie banner a konsekwencje. Co może grozić za niepoprawne lub brak wdrożenia?
Potrzebujesz pomocy przy poprawnym wdrożeniu banerów cookies?

Czym jest i do czego służy tzw. cookie banner?

Wspomniane ciasteczka to specjalne pliki, które służą m.in. do utrzymywania sesji i zapamiętywania danych, ale również sprawdzają się w działaniach promocyjnych (zwłaszcza do remarketingu). 

Cookie banner (tzw. informacja o cookies) to komunikat, który musi znaleźć się na każdej stronie internetowej, która w jakikolwiek sposób agreguje oraz przetwarza dane odwiedzających ją użytkowników (np. za pośrednictwem serwera, narzędzi do analityki internetowej czy systemów reklamowych). Obowiązek jego stosowania wynika wprost z przepisów prawa, które mają za zadanie chronić prywatność użytkowników poszczególnych stron internetowych.

Jak informacje o cookies był traktowane “kiedyś”, a jak podchodzi się do nich “obecnie”?

Tego rodzaju banery są znane nie od dziś. Do tej pory problem polegał jednak na tym, że pełniły one funkcje bardziej informacyjną. Nieważne, czy użytkownik kliknął “Zgadzam się”, wybrał “X” lub “Zamknij”, czy też zwyczajnie nie podejmował żadnej akcji – ciasteczka i tak były zbierane i przetwarzane.

Obecnie, za sprawą przepisów i grożących kar, wiele firm zaczęło przykładać większą wagę do ich funkcjonowania. Dzięki temu, za pośrednictwem prawidłowo wdrożonego baneru cookies, użytkownicy mogą wyrazić faktyczną (taką, która naprawdę ma wpływ na przetwarzanie informacji!) zgodę na przetwarzanie wybranych plików.

W tej materii możemy je podzielić na 2 typy:

Cookies obowiązkowe, czyli takie, które są niezbędne do prawidłowego funkcjonowania strony. Zgoda na nie musi być wyrażona. Zaliczamy do nich:

• User Centric Security Cookies, czyli odpowiedzialne za bezpieczeństwo
• Multimedia Player Session Cookies, czyli te stosowane przy odtwarzaniu materiałów multimedialnych
• Authentication Cookies, czyli ciasteczka służące do uwierzytelniania
• Funkcjonalne, czyli odpowiadające za konkretne funkcje strony internetowej.

Pozostałe cookies, czyli takie, które służą innym celom. W tym przypadku wyrażenie zgody na ich zbieranie i przetwarzanie są dobrowolne. Są to: analityczne, marketingowe oraz odpowiadające za preferencje użytkownika.

Jak pewnie się domyślasz – z Twojej perspektywy (jako marketera lub analityka), to właśnie na tej drugiej grupie ciasteczek powinno zależeć Ci najbardziej. W końcu to one mogą stanowić podstawę do analiz, wyciągania wniosków i podejmowania konkretnych akcji, a także – realizowania zwyczajnych działań remarketingowych.

Cookie Banner a RODO. Co zrobić, jeśli użytkownicy nie wyrażają zgód na pozostałe ciasteczka?

Jeśli uważasz, że brak takiej zgody automatycznie oznacza utracenie jakichkolwiek danych, a co za tym idzie – istotne “uszczuplenie” Twojej wiedzy o użytkownikach serwisu www – mam dobrą wiadomość.

Otóż, w tym miejscu z pomocą przychodzi Ci funkcjonalność o nazwie Consent Mode. Już jakiś czas temu na blogu Conversion poświęciliśmy jej całkiem spory artykuł. Dlatego, gdy tylko skończysz czytać ten – zapraszam Cię do lektury poprzedniej publikacji. Wszystkie najważniejsze informacje znajdziesz pod powyższym linkiem, dlatego pozwól, że tutaj jedynie wspomnę o jego najważniejszej zasadzie. 

Mianowicie, Consent Mode stanowi niejaką odpowiedź na rosnący odsetek userów, które nie wyrażają zgody na przetwarzanie dodatkowych i nieobowiązkowych cookiesów. Omawiana funkcjonalność wykorzystuje tzw. behavioral modeling, który (przy wykorzystaniu sztucznej inteligencji i uczenia maszynowego) potrafi skutecznie uzupełniać luki w danych.

Skoro teorię mamy już za sobą, pora na nieco praktyki…

Jak poprawnie wdrożyć cookie banner

Na początku musisz zdać sobie sprawę, że konfiguracja i wdrożenie baneru z informacjami o cookies, to nie zakupy w sklepie. Czytaj: w większości przypadków nie da się tak zwyczajnie kupić i zainstalować gotowego programu.

Zanim dojdzie do wdrożenia – musisz bardzo wnikliwie przeanalizować sytuację oraz potrzeby Twojej organizacji, w czym niezbędna może być nie tylko wewnętrzna pomoc “biznesu”, ale przede wszystkim – konsultacje z prawnikami.

Doświadczeni eksperci od prawa z pewnością pozwolą znaleźć Ci balans pomiędzy regulacjami prawnymi, które po prostu musisz spełnić, a funkcjonalnościami, które są Ci niezbędne do prowadzenia skutecznych działań – zarówno w obszarze reklamy, jak i analityki internetowej.

Gdy już dowiesz się “co” i w jakim zakresie chcesz wykorzystywać – pora na wybór rozwiązania, które da Ci takie możliwości. W tym aspekcie masz do dyspozycji dwie opcje:

• A, czyli zakup i konfiguracja gotowych narzędzi (o tym, którym warto się przyjrzeć przeczytasz niżej).
• B, czyli wykonanie customowego rozwiązania, które zostanie dostosowane do Twojego serwisu “od A do Z”.

Co będzie lepsze? Gotowe narzędzie do cookies czy stworzenie własnego oprogramowania?

Aby podjąć właściwą decyzję, najpierw musisz dokładnie przeanalizować potrzeby swojej firmy. Jeśli posiadasz klasyczną stronę internetową, która zbiera równie podstawowe informacje cookies, a w dodatku nie prowadzisz bardzo szerokiej i zaawansowanej analizy – być może wystarczy Ci zakup gotowego softu.

Jeżeli Twoje działania są bardziej zaawansowane (lub planujesz prowadzisz takie w przyszłości) – może istnieć spora obawa, że gotowe oprogramowanie po prostu nie sprosta Twoim oczekiwaniom. Wówczas warto rozważyć zbudowanie własnej platformy od podstaw.

Gotowe narzędzia mają spore ograniczenia, jednak są dostępne praktycznie “od ręki”, a ich ceny zaczynają się już od kilkudziesięciu złotych za miesiąc. Cena zależy od liczby obsługiwanych domen oraz istniejących w ich ramach podstron, czy liczby unikalnych wizyt w miesiącu.

Dedykowane narzędzia to spory wydatek zarówno czasowy, jak i finansowy (jednorazowo od kilkunastu do kilkudziesięciu tysięcy złotych). Jednak z drugiej strony oferują nieporównywalne możliwości, które z powodzeniem możesz dostosować do specyfiki i potrzeb swojej organizacji.

Jeśli jednak uznasz, że tworzenie oprogramowania od podstaw nie jest Ci potrzebne i wystarczą Ci narzędzia dostępne na rynku – koniecznie rzuć okiem na poniższe zestawienie. 

Jakie są najpopularniejsze rozwiązania Consent Management Platform (CMP)?

Na rynku funkcjonuje co najmniej kilka platform, które są warte Twojej uwagi. Ze swojej strony zachęcam do zapoznania się z takimi, jak: CookieBot, OneTrust oraz Cookie Information.

• CookieBot i Cookie Information to narzędzia stworzone właśnie z myślą o sprawnej obsłudze plików i bannerów cookies. Obie oferuję darmowe wersje demo / trial oraz płatne – uzależnione m.in. od wielkości strony (liczba podstron) oraz ruchu (liczba użytkowników).
• OneTrust to zdecydowanie większa i bardziej rozbudowana platforma, w której zarządzanie ciasteczkami stanowi tylko jedną z wielu funkcjonalności.

Moduły narzędzi dostępnych na rynku do zarządzania ciasteczkami, poza drobnymi aspektami niewiele się od siebie różnią. W każdym przypadku spełniają one kluczowe wymagania dotyczące danych użytkowników.

Cookie banner a konsekwencje. Co może grozić za niepoprawne lub brak wdrożenia?

Ewentualnie konsekwencje związane z brakiem lub nieprawidłowym wdrożeniem banerów cookies możemy rozpatrywać w dwóch perspektywach.

Pierwsza to czysto biznesowa, czyli związana z działaniami analitycznymi i marketingowymi. Niewłaściwe uruchomienie tego rodzaju funkcjonalności może ograniczyć dostęp do wartościowych danych o użytkownikach, które możesz wykorzystać zarówno do analiz, jak i prowadzenia działań promocyjnych w sieci (remarketing).

Druga to konsekwencja natury prawnej. Brak odpowiedniej egzekucji przepisów może narazić Twoją firmę na poważne spory w sądzie, a co za tym idzie – skutkować naliczeniem bardzo dotkliwych kar finansowych.

Potrzebujesz pomocy przy poprawnym wdrożeniu banerów cookies?

Jak widzisz – właściwie zaplanowanie i wdrożenie banneru cookies stanowi nieodzowną część biznesów online, które chcą działać w zgodzie z przepisami prawa. 

Czy sprawa jest poważna? Za najlepszy przykład mogą posłużyć działania jednej z organizacji non-profit (NOYB – European Center for Digital Rights). Tylko od maja 2021 roku wystosowała ona blisko tysiąc pism, które trafiły do podmiotów, które na swoich stronach internetowych stosowały nieprawidłowe komunikaty związane właśnie z funkcjonowaniem plików cookies. Inne organizacje oraz kancelarie już “zacierają ręce”, aby sprawdzić także Twoją stronę internetową.

Jeżeli chcesz mieć pewność, że jest zgodna z najnowszymi wymaganiami – skontaktuj się z nami. Specjaliści Conversion chętnie ją przeanalizują, a następnie zaproponują odpowiednie kroki. Kliknij w to miejsce, aby umówić się na niezobowiązujące konsultacje.

The post Cookie banner – czym jest i jak wdrożyć go poprawnie? first appeared on Conversion.

Wiele osób, które dotychczas korzystały ze „starej” wersji Google Analytics (czytaj: trójki), narzekało na istotne ograniczenia związane z wykorzystywaniem dużych zbiorów danych na znacznie większą, a czasami wręcz masową skalę. Oczywiście, do ich dyspozycji pozostawało BigQuery (BQ). Jednak pod warunkiem, że zdecydują się zapłacić i przejść na wersję GA360.

Na szczęście gigant z USA, w swojej najnowszej odsłonie narzędzia do analityki (Google Analytics 4) postanowił to zmienić. Od teraz korzystanie z BG nie wymaga już “przesiadki” i ponoszenia dodatkowych wydatków.

Zastanawiasz się, w jaki sposób eksport danych z Google Analytics 4 do BigQuery może przysłużyć się Twojej organizacji? W takim razie nie pozostaje Ci nic innego, jak zapoznać się z tym artykułem.

Co znajdziesz w tym artykule?
Po co całe to zamieszanie z BigQuery? Czy zwykły poczciwy Analytics to już za mało?
Dlaczego warto? Co da Ci eksportowanie danych do BigQuery?
1. Znacząco wydłużysz limity oraz czas przechowywania danych
2. Łatwo zintegrujesz dane pochodzące z różnych źródeł
3. Będziesz w stanie eksplorować dane – praktycznie bez żadnych ograniczeń
4. BigQuery umożliwi Ci sprawną walidację danych
5. Dzięki BigQuery połączysz się z innymi usługami oraz zautomatyzujesz procesy
Czy korzystanie z możliwości BigQuery to tylko same zalety?
Jak wykorzystać potencjał eksportu danych do BigQuery? Podsumowanie.

Po co całe to zamieszanie z BigQuery? Czy zwykły poczciwy Analytics to już za mało?

Jeśli po przeczytaniu wstępu w Twojej głowie pojawiło się właśnie takie (lub podobne) pytanie – już śpieszę z odpowiedzią. Na pewnym etapie, gdy Twój biznes się rozwija i zaczynasz gromadzić coraz więcej danych, z którymi zwykły Excel nie będzie w stanie sobie poradzić – po prostu “zderzysz się ze ścianą” w formie ograniczeń Analyticsa.

Mówiąc wprost – jakiekolwiek operacje przeprowadzane na bazach kilku czy kilkunastu tysięcy użytkowników staną się dla Ciebie prawdziwym utrapieniem i swoistą drogą przez mękę. Prowadzenie obliczeń, filtrowanie, a nawet sortowanie danych – będą trwały “wieki”, a wielu przypadkach po prostu staną się niewykonalne.

Wówczas, całe na biało wkroczy… BigQuery! Czyli rozwiązanie, dzięki któremu możesz walidować prawie “co chcesz” oraz prawie “jak chcesz”.

Dlaczego warto? Co da Ci eksportowanie danych do BigQuery?

BigQuery to rozwiązanie, które pozwoli Ci na sprawne “wyciąganie” danych spoza ekosystemu Google Analyticsa. W ten sposób otworzy przed Tobą wiele dodatkowych możliwości związanych, chociażby z:

• Agregowaniem i bezpiecznym przechowywaniem danych historycznych.
• Stosowaniem licznych podziałów, z którymi zwykłe GA sobie nie poradzi.
• Przeprowadzaniem szeregu analiz i wyciąganiu na ich podstawie cennych wniosków.
• Generowaniem czytelnych i wartościowych raportów.

Jeżeli te możliwości to dla Ciebie nadal za mało – mam dobrą wiadomość. Poniżej znajdziesz 5 kluczowych czynników, dzięki którym z pewnością polubisz się z tą funkcjonalnością. Ale zanim o nich – jeszcze kilka słów o wymaganiach.

Otóż, wykorzystanie BQ wymaga rozpoczęcia przygody z Google Cloud Platform (BigQuery jest jednym z elementów tej platformy), a w wielu przypadkach – także nabycia nowych kompetencji. Aby Twój zespół mógł efektywnie korzystać z jego możliwości przyda się nie tylko znajomość SQL, ale również znajomość i swobodne posługiwanie się takimi narzędziami, jak chociażby Looker Studio czy PowerBI.

1. Znacząco wydłużysz limity oraz czas przechowywania danych

Jeśli Twoja firma regularnie od dłuższego czasu korzysta z Google Analytics, to z całą pewnością mierzyliście się już z ograniczeniami związanymi z czasem przechowywania danych. Dla przypomnienia:

• W przypadku standardowego Google Analytics 4 – jest to 14 miesięcy.
• W przypadku nowej wersji 360 – jest to maksymalnie 50 miesięcy.

Brak eksportu do BigQuery spowoduje, że po przekroczeniu wspomnianych okresów przechowywania danych szczegółowych zostaną ograniczone wyłącznie do raportów standardowych bazujących na preagregowanych danych. Natomiast dane szczegółowe – przestaną być dostępne w eksploracjach.

Wspomniane limity powodują, że wykonywanie bardziej pogłębionych analiz (szczególnie w dłuższym horyzoncie czasowym), jest po prostu niemożliwe.

Na szczęście z BigQuery takie ograniczenia nie są już Twoim zmartwieniem. Bowiem po wdrożeniu tego rozwiązania Twoje dane będą przechowywane bezterminowo. Musisz jednak pamiętać, aby wdrożyć to jak najszybciej. Potrzebne Ci informacje będą agregowane dopiero od momentu uruchomienia BigQuery.

Ale to nie wszystko! Eksportowanie danych do BigQuery umożliwi Ci także „ominięcie” limitów nakładanych przez Looker Studio. Dzięki temu tworzenie nawet najbardziej rozbudowanych dashboardów nie powinno stanowić dla Ciebie większego wyzwania .

2. Łatwo zintegrujesz dane pochodzące z różnych źródeł

BQ pozwoli Ci na sprawne zbieranie danych z całego ekosystemu Google’a (m.in. Analyticsa, Google Ads, a nawet Google Search Console).

Jednak na tym Twoje możliwości integracyjne wcale się nie skończą! Mianowicie, BigQuery z powodzeniem da Ci także dostęp do informacji, które przechowujesz w innych narzędzia wykorzystywanych przez swoją organizację (może to być: system do e-mail marketingu lub całego marketingu automation, firmowy CRM, jak i szereg innych narzędzi bądź platform).

Takie integracje pozwolą Ci jeszcze łatwiej pozyskiwać wartościowe dane. A co najważniejsze – wykorzystywać je do budowy zaawansowanych raportów.

3. Będziesz w stanie eksplorować dane – praktycznie bez żadnych ograniczeń

Próbkowanie, kardynalność oraz inne (obowiązujące w Google Analytics) limity sprawiały, że do tej pory Twoja organizacja nie mogła w pełni “rozwinąć skrzydeł”?

W takim razie z pewnością ucieszy Cię fakt, że eksport danych do BigQuery otworzy przed Tobą zupełnie nowe i prawie niczym nieograniczone perspektywy. Z ich pomocą będziesz w stanie budować ścieżki użytkowników Twoich serwisów i aplikacji, przeprowadzać nawet bardzo niestandardowe analizy, a także znacznie sprawniej operować z innymi narzędziami BI.

Jednak, aby nie było zbyt “kolorowo” – to rozwiązanie ma również pewne ograniczenia, do których możemy zaliczyć m.in.: brak modelowania oraz brak atrybucji opartej o dane i danych Google Signals.

4. BigQuery umożliwi Ci sprawną walidację danych

Dostęp do tego rozwiązania sprawi, że wyposażysz się wygodną opcję weryfikacji tego, czy Twoje dane są poprawne. Co ważne – znacznie przyspieszysz i ułatwisz “wyłapywanie” ewentualnych błędów, a co za tym idzie – zyskasz możliwość ich naprawy – i to przed przekazaniem do narzędzi BI.

Ponadto, docenisz również inne możliwości, dzięki którym:

• Łatwo sprawdzisz poprawność implementacji swoich kodów Google Analytics.
• Przeprowadzisz proces debugowania skryptu GA.
• Wykonasz walidację działania Analyticsa na urządzeniach mobilnych.

Przykłady? Jeśli w Twoich danych wkradły się błędy (np. w nazwach) lub pojawiły się niespodziewane wartości – BigQuery pozwoli Ci na zdecydowanie łatwiejsze ich “oczyszczenie” – i to zanim trafią do narzędzi BI.

Natomiast prawdziwą “wisienką na torcie” będzie opcja sprawnego wykluczania z raportów i analiz tzw. śmieciowego ruchu (generowanego przez własne wizyty lub niechciane boty).

5. Dzięki BigQuery połączysz się z innymi usługami oraz zautomatyzujesz procesy

Jesteś fanem automatyzacji, a mówiąc wprost – szeroko pojętego ułatwiania i optymalizowania pracy (swojej, jak i zespołu)? W takim razie z pewnością ucieszy Cię to, że BigQuery umożliwi Ci budowanie własnych agregatów, a nawet całego środowiska raportowego, które może wychodzić bardzo daleko poza klasyczne ramy Google Analyticsa.

Takie opcje pozwolą Ci uwzględniać dane z innych platform (np. reklamowych) i pobierać szczegółowe dane o kampaniach z innych źródeł niż Google Ads (co nie jest oczywiste dla samego GA4). W ten sposób dadzą Ci opcję przygotowania spójnego spojrzenia na wyniki analiz.

Co ważne – raz przygotowane zapytania można wykorzystywać wielokrotnie, w ten sposób automatyzując cały proces i znacząco ułatwiając swoje codzienne obowiązki .

Czy korzystanie z możliwości BigQuery to tylko same zalety?

Jak z pewnością udało Ci się wywnioskować po przeczytaniu powyższych akapitów – BigQuery stanowi świetną podstawę do stworzenia własnego, funkcjonalnego oraz bardzo wydajnego środowiska służącego do analityki, oraz raportowania.

Jest jednak jedno – i to wcale nie takie małe – “ale”. Jasne – BigQuery stawia przed Twoją firmą zupełnie inne (lepsze) perspektywy – związane, chociażby z agregacją, przetwarzaniem oraz interpretowaniem nagromadzonych informacji. Jeśli planujesz korzystanie z jego możliwości – musisz przygotować do tego swoją firmę. Nieodzownym krokiem będzie przeszkolenie zespołu, a być może – rozważenie zatrudnienia nowych specjalistów.

Aczkolwiek, z drugiej strony musisz pamiętać o tym, że jest też całkiem wymagające. Jego duże możliwości oznaczają również duże nakłady zarówno pracy, jak i środków.

Jak wykorzystać potencjał eksportu danych do BigQuery? Podsumowanie.

Mam nadzieję, że powyższy artykuł dokładnie wyjaśnił Tobie dlaczego warto wykorzystać funkcję eksportu danych z Google Analytics 4 do Google BigQuery. Zdaję sobie sprawę, że nadal możesz zastanawiać się jak w pełni wykorzystać potencjał tej integracji. Odpowiedź na to pytanie na pewno znajdziesz w artykule Mariusza Michalczuka BigQuery i Google Analytics 4 – jak wykorzystać ich potencjał?

Jeżeli chcesz poznać koszt Google BigQuery oraz dowiedzieć się, jak wykorzystać to narzędzie do rozwoju biznesu, zapraszamy do artykułu – Google BigQuery – czym jest, ile kosztuje, jak wykorzystać?

Jeśli chcesz, aby takie rozwiązanie zaczęło działać na rzecz Twojej organizacji, jednak nie masz zasobów, aby wdrożyć je we własnym zakresie – umów bezpłatną konsultację i pogadajmy!

The post Eksport danych do BigQuery. Dlaczego warto wykorzystać potencjał tej funkcji w Google Analytics 4? first appeared on Conversion.

Jeśli obszar analityki internetowej jest Ci znany “nie od dziś”, to z pewnością zdajesz sobie sprawę, że jedno z najpopularniejszych narzędzi (dla przypomnienia: Google Analytics) – nakłada na swoich użytkowników pewne ograniczenia. Do kluczowych możemy zaliczyć między innymi: próbkowanie, kardynalność i progowanie danych, a także limity trafień, konfiguracji czy zbierania danych o zdarzeniach.

Jeżeli chcesz się dowiedzieć, czym są, sprawdź, co takiego mogą oznaczać dla Twojego biznesu – najbliższa okazja na poszerzenie swojej wiedzy jest właśnie przed Tobą! Sprawdź poniższy artykuł, aby poznać ich definicje oraz sposób działania. Zapraszam!

Co znajdziesz w tym artykule?
Próbkowanie danych w Google Analytics
Po czym poznać, że Twój raport jest spróbkowany lub nie?
Różnice w próbkowaniu w Google Analytics 4 vs Universal Analytics
Eksploracje niespróbkowane – czym są i czy warto?
Kardynalność danych w Google Analytics
Dlaczego liczność danych w Google Analytics 4 może stanowić źródło problemów?
Jak pozbyć się “other” w raportach GA4?
Progowanie danych w Google Analytics
Kiedy stosowane są progi danych?
Czy możesz usunąć próg danych?
Limity w Google Analytics
Limity trafień w Google Analytics 4
Limity zbierania danych o zdarzeniach
Limity konfiguracji w GA4
Limity, kardynalność i próbkowanie w raporty Google Analytics 4 – podsumowanie

Próbkowanie danych w Google Analytics

W raportach Google Analytics próbkowanie danych nie jest żadną nowością. Wiąże się ono z nałożonymi limitami – po to, aby ograniczyć liczbę danych wykorzystywanych do raportowania.

Opiera się ono na liczbie zdarzeń i może pojawić się w raportach eksploracji. Limit dla GA4 wynosi 10 milionów zdarzeń, a im większa próbka, tym również większa dokładność samych wyników. Aby uzyskać dokładniejsze wyniki – spróbuj zmniejszyć zakres dat. Jeśli jesteś klientem GA4 360, możesz zażądać niespróbkowanych wyników (beta) w raporcie eksploracji z próbkowaniem.

W najnowszej wersji, czyli Google Analytics 4, raporty dzielą się na dwie grupy: standardowe oraz zaawansowane. Pierwsze z nich nie są próbkowane na bazie 100% danych pochodzących z wybranego zakresu dat. Natomiast raporty zaawansowane mogą być czasami próbkowane – w zależności od wybranych warunków.

Jeśli korzystasz z GA4 i jednocześnie nie chcesz, aby Twoje dane podlegały próbkowaniu – wystarczy, że do tego celu dodasz wymiar lub segment.

Po czym poznać, że Twój raport jest spróbkowany lub nie?

Na szczęście jest to bardzo proste. Mianowicie, w raporcie niespróbkowanym w Google Analytics 4 – na górze ekranu zobaczysz charakterystyczną zieloną ikonę ze znacznikiem wyboru. Jeśli zamiast niej dostrzeżesz żółtą ikonę z symbolem % – będzie to znak, że raport jest próbkowany (znajdziesz pod nią również informację o procentowym udziale danych).

Różnice w próbkowaniu w Google Analytics 4 vs Universal Analytics

Standardowe raporty w Google Universal Analytics nie są próbkowane. Jeśli jednak dodasz do nich dodatkowe wymiary bądź segmenty – zaczną już podlegać następującym ogólnym limitom próbkowania:

• Standardowa analiza: 500 tys. sesji dla używanego okresu danych
• Analytics 360: 100 mln sesji dla widoku używanego okresu danych

W przypadku Google Analytics 4 domyślne raporty zawsze są niepróbkowane. Możesz stosować porównania i niestandardowe parametry, a wszystkie raporty nadal będą niepróbkowane. W zaawansowanej zakładce Analiza, raporty mogą być próbkowane, gdy liczba wykorzystywanych danych przekracza 10 milionów i tworzony raport nie jest kopią standardowego raportu.

Eksploracje niespróbkowane – czym są i czy warto?

W Google Analytics istnieje jeszcze coś takiego, jak eksploracje niespróbkowane, które pozwalają na generowanie raportów opierających się na podstawie nawet 50 miliardów zdarzeń. Jest jednak jeden małych “haczyk” – mogą z nich korzystać tylko osoby posiadające Google Analytics 360.

Jak to zrobić? Wystarczy, że poprosisz o niespróbkowane dane! Taki krok zapewni Ci bardzo dokładne raporty i pozwoli na uzyskanie danych, które nie są dostępne w ich standardowych wersjach.

Kardynalność danych w Google Analytics

Skoro omówienie zagadnienia próbkowana mamy już za sobą – najwyższa pora przejść do kolejnego “ograniczenia”. Otóż, kardynalność to ilość unikalnych wartości w wymiarze. Jeśli to pojęcie nadal niewiele Ci wyjaśnia – spokojnie, już tłumaczę !

Musisz zdawać sobie sprawę, że niektóre wymiary mają określoną liczbę wartości. W tym obszarze możemy mówić np. o typach urządzeń, wymieniając: komputer, tablet, telefon – co da nam liczność na poziomie 3.

Inne, jak chociażby ścieżka, lokalizacja, identyfikator, a nawet nazwa elementu – mogą mieć zdecydowanie więcej. Ile? W przypadku 50 elementów na stronie liczność identyfikatora wynosi 50. Natomiast wymiar posiadający więcej niż 500 wartości – jest już uważany za wysoko kardynalny.

Raporty standardowe bez wymiaru dodatkowego lub porównania mają limit 50 000 wierszy w tabeli. Przy czym – zawierają tylko niezbędne dane. Raporty Eksploruj lub standardowe z dodatkowym wymiarem lub porównaniem oferują aż 2 miliony limitu wierszy w tabeli. Trzeba wspomnieć, że te raporty zawierają wszystkie wymiary w usłudze – i to niezależnie od tego, czy są potrzebne i czy wpływają na limit wierszy. Z kolei duża liczba wymiarów może spowodować pojawienie się wiersza “other”.

Dlaczego liczność danych w Google Analytics 4 może stanowić źródło problemów?

Pojawienie się kardynalności powoduje wzrost liczby wierszy w raporcie GA4. Każdy raport ma inną tabelę i po osiągnięciu limitu wierszy GA4 dodaje „inne” (a w zasadzie “other”) do wymiaru. W „other” znajdują się więc wszystkie dane przekraczające limit. Raporty standardowe i eksploracyjne mają różne limity, więc rezultaty również mogą być zgoła odmienne.

Uwaga: nieznane dane, które trafią do raportu, również wpływają na limit wierszy.

Jak pozbyć się “other” w raportach GA4?

Jeżeli “odkładanie” danych do “innych” nie jest Ci po drodze – możesz skorzystać z poniższej instrukcji.

• Używaj standardowych raportów, gdy to możliwe. Posiadają specjalne tabele, które umożliwiają zmniejszenie ryzyka zgrupowania danych w „other”.
• Użyj Eksploracji, jeśli widzisz „other” w swoich raportach. Eksploracje korzystają bowiem z innego limitu tabeli.
• Unikaj tworzenia niestandardowych wymiarów, a gdy to możliwe – korzystaj z tych predefiniowanych.
• Używaj wymiarów o dużej liczności tylko wtedy, gdy jest to niezbędne. Limit wierszy może dotyczyć wszystkich danych w usłudze dla określonego zakresu dat – gdy zastosujesz dodatkowy wymiar lub porównanie do raportu standardowego albo gdy użyjesz raportu niestandardowego.
• Unikaj tworzenia niestandardowego wymiaru w celu identyfikacji poszczególnych użytkowników. Zamiast tego użyj funkcji User-ID w GA4.
• Wyeksportuj swoje dane do BigQuery.

Oczywiście, można sobie z tym poradzić również w inny sposób – wykupując Google Analytics 4 w wersji 360 .
Tego rodzaju usługa pozwala bowiem na automatyczne uruchamianie rozszerzonych zbiorów danych – i to dla obu typów raportów – standardowych i eksploracyjnych. Wówczas limit wynosi 2 miliony wierszy w tabeli. I co najważniejsze – taki rozszerzony zbiór danych obejmuje tylko wymiary potrzebne do raportu, a nie wszystkie zebrane dla usługi.

Ponadto, przejście na Analytics 360 pozwoli Ci korzystać z automatycznie rozwijanych zbiorów danych, jeśli w standardowej usłudze widoczny jest wiersz „other”. Analytics 360 samoczynnie uruchomi wówczas rozwijane zbiory danych, aby unikać tego wiersza – gdy tylko osiągniesz limit powodujący jego pojawienie się.

Progowanie danych w Google Analytics

Jeśli operuje na sporych bazach danych – prędzej czy później spotkasz się z sytuacją, w której zauważysz ich częściowe braki. Będą one wynikać ze stosowania tzw. progów, które zostały zaprojektowane po to, aby chronić prywatność użytkowników witryny, a co za tym idzie – uniemożliwić osobom przeglądającym raport określenie ich tożsamości (przynajmniej na podstawie informacji o danych demograficznych czy zainteresowaniach).

Kiedy stosowane są progi danych?

Mówiąc wprost – jeżeli Twój raport zawiera dane o wieku, płci lub zainteresowaniach (zawarte w wymiarze podstawowym, dodatkowy, porównaniu danych lub segmencie) – wówczas może zostać zastosowany próg danych, a co za tym idzie – wybrane informacje zostaną ukryte.

Czy możesz usunąć próg danych?

Uprzedzając ewentualne pytania: tego rodzaju progi są ustalane przez Google i nie da się ich zmieniać. Google Analytics stosuje je po to, aby chronić prywatność użytkowników. Jest jednak jedno, małe “ale”…

Z powodzeniem można zmienić sposób raportowania, który pozwoli uniknąć progowania danych. Aby to zrobić – wystarczy, że wybierzesz opcję raportowania tylko na urządzeniu. W takiej sytuacji Analytics użyje identyfikatora klienta (lub identyfikatora instancji aplikacji), które nie podlegają już takim progom.

Musisz jednak pamiętać, że takie zmiany, dane demograficzne w raportach z niską liczbą użytkowników mogą nadal być wstrzymane.

Limity w Google Analytics

Kolejnym rodzajem ograniczeń, jakie narzuca na nas jedno z najpopularniejszych narzędzi do analityki internetowej, są limity. Zaliczamy do nich limity związane z trafieniami, zbierania danych o zdarzeniach oraz konfiguracji.

Poniżej znajdziesz kluczowe informacje na temat każdego z nich, a przy dwóch ostatnich – dodatkowe tabele z wyszczególnionymi progami.

Limity trafień w Google Analytics 4

Pierwsze “na warsztat” weźmiemy tzw. trafienia, czyli działania podejmowane przez konkretnych użytkowników Twojej witryny internetowej.

W przypadku standardowej wersji Analyticsa limit trafień wynosił 10 milion miesięcznie. W przypadku Google Analytics 4 dobra wiadomość jest taka, że został on całkowicie zniesiony !

Limity zbierania danych o zdarzeniach

Analytics posiada także limity dla rejestrowania zdarzeń, parametrów zdarzeń oraz właściwości użytkownika. A ich przekroczenie może oznaczać, że dane nie zostaną zarejestrowane.

Przykłady? GA przestanie rejestrować aktywności użytkownika z 26 lub więcej wartościami, a także nazw zdarzeń o długości większej niż 40 znaków.

Więcej informacji na temat limitów zbierania danych znajdziesz w poniższej tabeli:

Limity konfiguracji w GA4

Ostatnim, aczkolwiek wcale nie najmniej istotnym ograniczeniem, są tzw. limity konfiguracji. Mogą dotyczyć takich aspektów, jak: odbiorcy, konwersje, eksploracje i wiele innych.

Przykład? Google Analytics nie pozwoli Ci skonfigurować kolejnej listy odbiorców, jeśli w danym momencie posiadasz już 100 takich list.

A jeśli usługa zbiera więcej danych niż wynika z limitu próbkowania – narzędzie będzie korzystać z dostępnej próbki danych w swoich eksploracjach.

Więcej informacji na temat tego rodzaju limitów odczytasz z tej tabeli:

Limity, kardynalność i próbkowanie w raporty Google Analytics 4 – podsumowanie

Jak widzisz korzystanie z Google Analytics jest bardzo pomocne – o weźmiesz pod uwagę ograniczenia oraz limity tego narzędzia. Mam nadzieję, że tym artykułem przynajmniej przybliżyłem Ci tę tematykę i udzieliłem odpowiedzi na najbardziej nurtujące pytania.

A jeśli zastanawiasz jak wykorzystać te narzędzia w Twojej firmie – pogadajmy!

The post Raporty Google Analytics 4: kardynalność i próbkowanie danych oraz inne limity first appeared on Conversion.

Do napisania tego artykułu zainspirował mnie whitepaper Visual Website Optimizer (części z Was na pewno również wpadł w rękę). Swoją drogą bardzo szybko zareagowali – przyznam, że korzystałem z różnych narzędzi do testów A/B, ale tylko od nich coś takie dostałem.

Co powinno być poprawione w eksperymentach Google Analytics

Chciałbym, aby ten artykuł nie był nacechowany negatywnie. Osobiście uważam, że eksperymenty Google Analytics są bardzo dobrym rozwiązaniem do przeprowadzania testów A/B – w końcu najczęściej to ten system wykorzystujemy obecnie do testów u naszych Klientów. Jednak nie oznacza to, że są idealne – ciągle jest sporo do poprawy. Oto moje propozycje (w kolejności od najbardziej istotnych dla mnie).

1. Sposób mierzenia konwersji

Wspominaliśmy o tym w naszym artykule pt. Eksperymenty Google Analytics (content experiments). Problem polega na tym, że konwersji dla testowanej odmiany liczona jest nie na unikalnego użytkownika, ale na unikalną odsłonę. Przypomnę, że unikalność odsłony rozpatrujemy w kategoriach sesji. W związku z tym, jeżeli użytkownik, który dostał wersję oryginalną skonwertuje w czasie trwania testu klika razy (w czasie kilku wizyt), to konwersje te zostaną zapisane na korzyść tej wersji (chociaż w rzeczywistości niekoniecznie świadczą o jej wyższości). Oczywiście można powiedzieć, że mamy 50% szans w testach A/B, że zarówno wersja oryginalna jak i odmiana alternatywna trafią na takiego użytkownika. Sprawa się jednak trochę komplikuje, jeżeli serwis charakteryzuje się bardzo dużą bazą powracających użytkowników, którzy wracają do niego niemalże codziennie.

W przypadku witryn z dużą bazą (często) powracających użytkowników eksperymenty Google Analytics mogą być trudne do przetestowania zmian w ramach serwisu. Musimy wtedy uważać nie tylko na przyzwyczajenia użytkowników, ale również mieć na uwadze późniejsze analizy i sprawdzić, czy na którąś z wersji procentowo nie trafiło więcej powracających użytkowników, którzy skonwertowali więcej niż raz w czasie testu. Taka analiza opiera się oczywiście o metrykę unikalnego użytkownika.

2. Przekierowanie ruchu na wygrywającą odmianę

Eksperymenty Google Analytics działają w ten sposób, że jeżeli któraś wersja wygrywa, to automatycznie dostaje ona większą liczbę odwiedzin…. i bardzo dobrze! Już od początku testu warto czerpać korzyści z poprawionej wersji strony (lub minimalizować straty, jeżeli zaproponowaliśmy mniej efektywną odmianę). Google nazwało ten sposób prowadzenia eksperymentu Multi-armed bandit experiments. Działa on w ten sposób, że raz dziennie algorytm bierze pod uwagę skuteczność wersji eksperymentu i na tej podstawie ustala przydział odwiedzin na poszczególne z nich. Oparty jest na teorii sekwencji podejmowania decyzji Bayesa. Przy takim dziennym przyjrzeniu się danym obliczane jest prawdopodobieństwo wygrania danej odmiany nad pozostałymi. Jeżeli wynosi ono np. 80% wówczas taką część ruchu dostaje ta odmiana w następnym dniu. Google twierdzi, że jest to lepszy sposób na rozstrzygnięcie eksperymentu – zgadzam się. Moim zdaniem jednak jest warunek dla tego – musimy mieć duży ruch i dużo konwersji…

Wszystko byłoby fajnie, ale – przede wszystkim nie mamy możliwości wyboru mechanizmu testowania. Problem pojawia się, kiedy mamy mniejszy ruch i mniej konwersji, a tutaj nie dosyć, że jedna z wersji jest słabsza sama w sobie, to dostaje mniej ruchu, a więc ma mniej konwersji. Google motywuje wprowadzenie tego algorytmu m.in. faktem, że dzięki temu eksperymenty rozstrzygają się szybciej – no dobrze, to po co wtedy wymagać 14 dni trwania testu?:) (patrz punkt następny)

Jeżeli któraś z wersji w teście przegrywa, to w eksperymencie automatycznie otrzymuje mniejszą liczbę odwiedzin. W dłuższym okresie trwania testu może to doprowadzić do dużych dysproporcji.

3. Konieczność oczekiwania 2 tygodnie na wynik

Wynik eksperymentu Google Analytics (ten oficjalny) pojawia się dopiero po 14 dniach trwania eksperymentu. Jeżeli zdecydujemy się wcześniej przerwać test, to będziemu mieli informację:

Eksperyment zatrzymano przed wyłonieniem zwycięzcy

lub w trakcie jego trwania

Eksperyment w toku – jeszcze nie wyłoniono zwycięzcy

Taka informacja pojawia się nawet w momencie, kiedy szansa na pobicie oryginału (poziom ufności) wynosi ponad 95%.

Informacja o braku zwycięzcy pojawia się nawet w przypadku, kiedy sznsa na pobicie oryginału (poziom ufności) przekracza 95%.

Moim zdaniem nie ma sensu czekać 14 dni, jeżeli nasza wersja ewidentnie wygrywa/przegrywa. Do tej pory, w testach które prowadziliśmy kierowaliśmy się regułą 10-14 dni. Jeżeli chcielibyśmy wprowadzać tutaj jakieś minima, to absolutnym minimum jest moim zdaniem tydzień.

4. Testy wielowymiarowe

Co tu dużo mówić – w eksperymentach Google Analytics po prostu ich brakuje. Jest to bardzo wygodny i szybki sposób przeprowadzania testów online. Obecnie możemy skonfigurować jedynie podstawowe testy A/B.

5. Możliwość testowania zmiennych e-commerce

Skoro w eksperymentach Google Analytics umożliwiono nam testowanie celów możliwych do skonfigurowania w narzędziu (np. średni czas na stronie), to życzyłbym sobie (i chyba nie tylko ja), aby była możliwość testowania zmiennych e-commerce np. średniej wartości zamówienia (przydatne zwłaszcza w przypadku testowania cross i up sellingu).

6. Prezentacja wyników testu

W porównaniu do Google Website Optimizer jest ona bardzo zubożona. Przykład wyniku testu z eksperymentów Google Analytics (Content Experiments) mogliście zobaczyć wyżej. W stosunku do Google Website Optimizera brakuje jej przede wszystkim słupków konwersji – z punktu odczytu wyniku nie jest to aż na tyle istotne, ale dla mnie (ilościowca) jest to bardzo ciekawa informacja. Po drugie brakuje zakładki „Sekcje strony”, ale wynika to faktu, że w eksperymentach GA nie ma testów wielowymiarowych.

Porównując panel eksperymentu w Google Website Optimizer i Google Analytics można znaleźć kilka różnic (niestety na niekorzyść eksperymentów GA).

Na wykresie konwersji eksperymentów Google Analytics chciałbym również (jak to było w Google Website Optimizer) widzieć średnią kroczącą współczynnika konwersji, a nie tylko dzienny rozkład konwersji. Tak naprawdę to nic nie stoi na przeszkodzie, aby Google dało możliwość przełączania się pomiędzy widokami wykresu, co od dawna robi wspomniany na początku artykułu Visual Website Optimizer.

Podsumwanie

Jednak trochę się tego nazbierało. Ale ja wierzę w Google i tak jak zmienili Google Analytics w ciągu ostatniego półtora roku, tak jestem przekonany, że przynajmniej część z powyższych błędów zostanie naprawiona.

Teraz Wasza kolej – co zmienilibyście w eksperymentach Google Analytics? Co Wam się nie podoba i/lub utrudnia pracę przy przeprowadzaniu testów A/B?

The post 6 rzeczy do zmiany w eksperymentach Google Analytics first appeared on Conversion.

Trzeba przyznać, że integracja GWO z GA była bardzo długo oczekiwanym krokiem i w postaci Eksperymentów na pewno bardzo uprościła tworzenie testów A/B (co mi się osobiście bardzo podoba). Jeszcze większy entuzjazm wywołuje we mnie Google Data studio, które te nasze skrzętnie nagromadzone dane zintegruje i przedstawi w formie wizualnego raportu – w sam raz na strategiczne spotkanie!

W tym artykule chciałbym jednak zwrócić Waszą uwagę na kilka ważnych kwestii i „smaczków” związanych z Eksperymentami Google Analytics, które powinien znać każdy kto zamierza poświęcić im trochę więcej czasu

Jeżeli szukacie podstawowej instrukcji stworzenia testu w CE to niestety jej tutaj nie znajdziecie. Zachęcam do przeczytania instrukcji na stronach Google Analytics, która świetnie tłumaczy podstawowe aspekty. Dodawać nic do niej w tym kontekście nie trzeba. Jeżeli poszukujesz podstawowych informacji na temat testowania to zachęcam do lektury naszych poprzednich wpisów: czym różnią się testy A/B od wielowymiarowych, co zrobić nim rozpoczniemy testy, jak uniknąć 4 najczęściej popełnianych błędów przy testach A/B i wielowymiarowych, statystyka w testach A/B.

Co się zmieniło w Eksperymentach Google Analytics w porównaniu z Google Website Optimizer?

Zacznijmy od tego czym różnią się tak naprawdę Eksperymenty Google Analytics od Google Website Optimizera (i jakie daje nam to korzyści):

1. 1. sposób przekierowania użytkowników i śledzenia

Pierwsza rzecz, która odróżnia CE od GWO to sposób przekierowywania użytkowników. W GWO wyglądało to tak, że gdy skrypt losujący umieszczony na stronie oryginalnej wylosował użytkownikowi tą wersję, to strona się po prostu wczytywała dalej. Natomiast, gdy użytkownikowi została wylosowana wersja zmieniona, to był on przekierowywany na URL wersji zmienionej.

Tak wyglądał schemat działania Google Website Optimizera — gdy skrypt losujący umieszczony na stronie oryginalnej wylosował użytkownikowi tą wersję, to strona wczytuje się dalej; jeśli użytkownikowi została wylosowana wersja zmieniona, to był on przekierowywany na URL wersji zmienionej

W Eksperymentach Google Analytics jest inaczej. Po pierwsze użytkownik jest przekierowywany zawsze. Dzieje się to tak przy wylosowaniu oryginału, jak i wersji zmienionej. Dodatkowo w trakcie przekierowania do URLa strony doklejany jest numer eksperymentu.

Czyli, jeżeli w eksperymencie stroną oryginalną jest strona /1o.html, a eksperyment ma numer 32666069-4, to po wylosowaniu oryginału znajdziemy się na stronie /1o.html?utm_expid=32666069-4. Z drugiej strony, jeżeli wersją zmienioną byłaby /1v1.html to zostalibyśmy przekierowani na /1v1.html?utm_expid=32666069-4 (żywy egzemplarz tego testu możecie podglądnąć tutaj).

Tak wygląda schemat działania Eksperymentów Google Analytics — bez względu na to, która wersja została użytkownikowi wylosowany jest on przekierowywany, a do linku doklejony zostaje dodatkowy parametr

Dlaczego tak się dzieje? Powód jest bardzo prosty — w GWO za śledzenie użytkownika odpowiadała wirtualna odsłona, która rejestrowała, że użytkownik wziął udział w eksperymencie. Dla przypomnienia dodatkowy kod, który musieliśmy umieścić na naszej stronie, dzięki któremu GWO zliczało oglądnięcia wersji wyglądał następująco:

Obecnie tego kodu nie ma. Jak więc CE mają rejestrować, czy użytkownik widział daną wersję? Najłatwiej było dodać jakiś element do URLi, który dawałby GA znać, że dany użytkownik ogląda stronę, która bierze udział w eksperymencie. Z tego wyszły nam takie właśnie URLe z „doklejkami”: /1v1.html?utm_expid=32666069-4. Oczywiście tych dodatkowych „śmieci” w postaci ?utm_expid=32666069-4 w raportach treści Google Analytics nie zauważymy — zostaną one automatycznie usunięte (wyjątek stanowią raporty czasu rzeczywistego, które pozostaną „zaśmiecone”).

Co ciekawe URLe do których dodana jest ta „doklejka” nie muszą być zbieżne z tym co ustawiliśmy w Google Anlaytics. CE dopasowują informację o tym, którą wersję widział użytkownik po wartości ciasteczka __utmx, które jest przesyłane razem z tym requestem. Oznacza to, że tak naprawdę nie musimy modyfikować URLa, który widzi użytkownik, tylko zmodyfikowany URL przesłać wirtualną odsłoną. Fakt, że w takim wypadku nie jest przesyłany dodatkowy parametr utmxkey, ale GA zdaje się nie zwracać na to uwagi

Request wysyłany, gdy mamy zmieniony URL w pasku przeglądarki:

Gdy request wysyłany jest ze strony, w której w URLu w pasku przeglądarki mamy „doklejkę”, wtedy znajdziemy w nim dodatkowo utmxkey

Request, który wysyłamy jako wirtualną odsłonę (bez zmiany URLa w pasku przeglądarki):

Gdy request wysyłany jest jako wirtualna odsłona, która ma „doklejkę” (ale w pasku adresu jej brakuje), wtedy znajdziemy w nim dodatkowo utmxkey — nie wpływa to jednak negatywnie na zbieranie danych przez Google Analytics

Jak widać w jednym requeście utmxkey jest, a w drugim go nie ma. Nie powstrzymuje to jednak GA przed zliczaniem odwiedzin z obu sposobów w Eksperymentach.

Co jest plusem nowych przekierowań? Niewątpliwym plusem nowych przekierowań jest to, że nie gubią one źródła odesłania. Pewnie wielu z Was zacznie zastanawiać się o co chodzi, a chyba najlepiej opisze to jeden z komentarzy na naszym blogu, który niegdyś otrzymaliśmy (kliknij na obrazek, by go powiększyć):

Google Website Optimizer zmieniał źródło odesłania dla wersji zmienionej — wszyscy użytkownicy byli rejestrowani jako pochodzący ze wejść bezpośrednich. Na szczęście tego problemu już w Eksperymentach Google Analytics nie ma.

W nowej wersji Eksperymentów Google Analytics nie będziemy mieli z tym problemów, ponieważ jeśli użytkownik wszedł na stronę oryginalną z jakiegoś źródła to dodatkowo do linku zostanie doklejony parametr utm_referrer (w której jest przekazywany document.referrer ze strony przed jej przeładowaniem), dzięki któremu stworzone zostanie poprawne ciasteczko utmz.

Co więcej, można nawet bardzo łatwo ustawić, aby w zwykłych raportach treści URLe wersji zmienionej nam się nie pokazywał (i te odwiedziny i konwersje były w normalnych raportach pokazywane jako odwiedziny i konwersje oryginału):

W Eksperymentach Google Analytics bardzo łatwo ustawimy, aby URLe wersji alternatywnych zostały zamienione na oryginalne w raportach treści.

Prawdziwą nirvaną jest już na pewno to, że teraz nasi programiści będą musieli umieścić jedynie jeden skrypt na stronie oryginalnej (skrypt losujący), abyśmy mogli wystartować z testem. Jest to ogromne ułatwienie w porównaniu z Google Website Optimizerem.

1. 1. sposób mierzenia konwersji

Drugim elementem, którym różnią się Eksperymenty Google Analytics od Google Website Optimizera jest sposób mierzenia konwersji. W samym technicznym ujęciu zbierania nie zmieniło się wiele — w GWO mieliśmy wirtualną odsłonę (skrypt praktycznie identyczny jak ten do mierzenia odwiedzin, z tą jednak różnicą, że w wirtualnej odsłonie zmieniało nam się /test na /goal):

W Eksperymentach Google Analytics ustalamy natomiast, który z celów skonfigurowany w naszym profilu ma być mierzony jako konwersja w eksperymencie.

Zastanawiacie się po czym GWO i CE rozpoznają z której wersji jest konwersja? Za każdym razem, gdy kod śledzący GA umieszczony na naszej stronie się wywołuje, to oprócz normalnych informacji takich jak tytuł strony, to wysyła również wartość ciasteczka __utmx w którym zdefiniowany jest numer eksperymentu w którym bierzemy udział oraz wersja strony, którą oglądaliśmy.

Co jest plusem nowego śledzenia konwersji? Przede wszystkim to, że nie musimy dodawać kolejnych kodów, tylko możemy wykorzystać bieżący kod śledzący Google Analytics. Co więcej, bardzo szybko możemy zmienić liczoną w teście konwersję — wystarczy zmienić mierzony cel (albo stworzyć kompletnie nowy).

1. 1. Sposób liczenia współczynnika konwersji

Jeśli mam być szczery to ta zmiana jest dla mnie największym zaskoczeniem. W Google Website Optimizer współczynnik konwersji był liczony według następującego wzoru:

współczynnik konwersji = unikalne realizacje celu / unikalni użytkownicy

Tak też liczą ten współczynnik wszystkie inne znane mi narzędzia do przeprowadzania testów. Ma to jedno bardzo dobre uzasadnienie: tylko w przypadku pierwszego zamówienia danego użytkownika w teście możemy mówić o tym, że przekonała go do tego dana wersja serwisu. Do kolejnym konwersji przekonała go albo super obsługa albo np. błąd, który spowodował, że musiał przekonwertować po raz kolejny. Z tego powodu zazwyczaj znacznie lepszy jest współczynnik konwersji liczony po unikalnych realizacjach celu i unikalnych użytkownikach.

W Eksperymentach Google Analytics mamy natomiast do czynienia z mierzeniem współczynnika konwersji w którym mianownik jest liczbą odwiedzin, a licznik liczbą realizacji celu (które są liczone jako 1 na odwiedziny, a nie 1 na użytkownika). Podejrzewam, że zmiana ta wzięła się z chęci ujednolicenia metryk, aby osoby korzystające z nowej funkcjonalności nie zastanawiały się nad różnicą pomiędzy współczynnikami konwersji notowanymi przez różne raporty w obrębie Google Analytics.

Osobiście uważam to jednak za błąd. U jednego z naszych Klientów mieliśmy niedawno taką sytuację: na wersji oryginalnej cel złożenia zamówienia był zrealizowany 200 razy. Podobną wielkość wskazywała liczba realizacji tego celu w wersji alternatywnej. Obie wersje miały podobną liczbę odwiedzin (a także unikalnych użytkowników), a co za tym idzie niemal identyczne współczynniki konwersji. Wniosek: nic się nie zmieniło.

Jak się jednak okazało około 50 zamówień z wersji oryginalnej nie została nigdy opłacona (przy praktycznie 100% skuteczności w wersji zmienionej). Co więcej, okazało się, że praktycznie wszyscy użytkownicy, którzy nie opłacili tych zamówień złożyli kolejne zamówienia, które już opłacili. Problem polegał na tym, że w wersji oryginalnej użytkownik musiał opłacić zamówienie odrazu po jego złożeniu. Jeżeli tego nie zrobił, musiał składać zamówienie ponownie, aby mieć jakikolwiek zamówienie do opłacenia.

Reasumując okazuje się, że tak, obie wersje miały po 200 zamówień liczonych po celach, ale licząc po unikalnych transakcjach wersja oryginalna zanotowała około 150 zakupów, natomiast wersja zmieniona notowała wciąż około 200 zamówień.

Z tego powodu nie rozumiem zmiany w liczeniu metryki współczynnika konwersji pomiędzy Google Website Optimizer, a Eksperymentami Google Analytics.

1. 1. Sposób prezentacji danych

W Google Website Optimizer raport nie był nazbyt zaawansowany i pokazywał niezbyt wiele:

Tak wyglądały raporty z testu w Google Website Optimizer…

W Eksperymentach Google Analytics raporty są znacznie bardziej rozbudowane:

…a tak wyglądają w przypadku Eksperymentów Google Analytics

Nim przejdę do plusów i minusów nowego raportowania na pewno wielu z Was zwróci uwagę na znacznie większa liczbę odwiedzin i konwersji lepszej w tym teście, oryginalnej wersji. Jest to zachowanie typowe dla Eksperymentów Google Analytics, które automatycznie kierują większy procent odwiedzających nas użytkowników na wersję bardziej efektywną, aby zmaksymalizować korzyści, które generuje nam nasza strona internetowa w czasie testu (prawdopodobnie jest to lekarstwo na to, że nie możemy zatrzymać pojedynczej — nawet najgorzej konwertującej — wersji strony w trakcie trwania testu).

W nowych raportach lubię kilka rzeczy:
1. na wykresie możemy zobaczyć współczynnik konwersji dzień po dniu jak i liczbę odwiedzin eksperymentu i liczbę konwersji także w widoku dzień po dniu (wcześniej tego nie było).
2. w bardzo łatwy sposób przejdziemy pomiędzy metrykami i porównamy wydajność oryginału i wersji zmienionej także pod względem średniego czasu na stronie, współczynnika odrzuceń (zakładka „Wykorzystanie witryny” ponad wykresem) jak i współczynników e-commerce: średniej wartości zamówienia, współczynnika konwersji e-commerce itd.
3. wyniki eksperymentu możemy sobie posegmentować z wykorzystaniem segmentów zaawansowanych (love it!).

Te trzy powyższe rzeczy są naprawdę fajne i co najważniejsze dostępne od ręki. Z GWO też można było do nich dotrzeć — zajmowało to jednak 5 min dłużej

Jest też kilka rzeczy, które mi się nie podobają:
1. na wykresie nie da się przedstawić średniej kroczącej współczynnika konwersji (tak jak było to zrobione domyślnie w Google Website Optimizer). Co więcej, pod wykresem podana metryka jest średnią kroczącą, ale domyślnie wykres pokazuje średni współczynnik konwersji dzień po dniu — osobiście cały czas się łapię, że zapominam, że patrzę na inny wykres niż wcześniej.
2. w Eksperymentach Google Analytics nie zobaczymy wiążącego wyniku eksperymentu przed upływem 2 tygodni. Oczywiście, sam przestrzegam przed zbyt szybkim kończeniem testów, ale w niektórych przypadkach można spokojnie zamknąć test już po upływie 10 dni (patrz wyniki z GWO, które prezentujemy wyżej). Na szczęście cały czas jest nam prezentowana metryka „Prawdopodobieństwa uzyskania lepszego wyniku niż oryginalna”, która jeżeli przekroczy 95% po 10 dniach to możemy spokojnie zamknąć eksperyment bez czekania na arbitralny wynik od CE
3. w nowym zestawieniu danych mocno brakuje wykresów pudełkowych, które były prezentowane w Google Website Optimizer. Dzięki nowej możliwości widoku konwersji i odwiedzin po dniu znacznie łatwiej narysować je sobie w Excelu, ale wciąż nie jestem fanem tego ograniczenia. Zapewne ono również wzięło się z wizji uproszczenia całego narzędzia, aby jak najmniej elementów wzbudzało pytania i wątpliwości potencjalnych użytkowników.

1. 1. Względne URLe

To jest kompletna nowość w porównaniu do Google Website Optimizera. Niestety nie ma jeszcze polskiej instrukcji na ich temat — po angielsku możecie poczytać o nich tutaj. W skrócie chodzi o to, że w GWO mogliśmy jedynie definiować testy A/B, które przekierowywały nas pomiędzy z góry zdefiniowanymi (bezwzględnymi) URLami. Czyli oryginał miał adres https://www.conversion.pl/oryginal.html i użytkownik mógł albo pozostać na nim (jeżeli wylosowano oryginał) lub mógł zostać przekierowany na wersję zmienioną, która miała adres np. https://www.conversion.pl/abrakadabra.html.

Rodziło to problem następującej natury: jak za pomocą testów A/B przetestować większa liczbę URLi? Przykład: jeżeli mamy strony produktowe w sklepie internetowym to mają one wspólny szablon, ale różnią się URLami. Mamy w naszym sklepie np. /produkt1.html i /produkt2.html. Nie dałoby się obu tych stron przekierować na wspólny URL alternatywny, ponieważ każdy produkt jest inny. Teraz jest to możliwe dzięki właśnie tak zwanym względnym URLom.

Definiujemy więc, żeby wersja alternatywna miała doklejany jakiś parametr (czyli URL względny)— np. ?var-1. Teraz, jeżeli Eksperymenty Google Analytics wylosują dla użytkownika wersję zmienioną, to zostanie on przekierowany ze stronie /produkt1.html na stronę /produkt1.html?var-1, natomiast ze strony /produkt2.html na stronę /produkt2.html?var-1. Będziemy musieli jedynie zadbać o to, aby nasz sklep wyświetlał zmienioną wersję strony produktu w momencie, gdy URL będzie zawierał var-1.

Plusów tego rozwiązania nie muszę chyba wymieniać. Daje nam ono całkowicie nowe możliwości testowania pomiędzy domenami i całymi serwisami. Dla mnie rewelacja

Podsumowując Eksperymenty Google Analytics

Jedno jest pewne: Eksperymenty Google Analytics w wydatny sposób pomogą wielu osobom rozpocząć przygodę z testowaniem. Odpalenie testu A/B staje się jeszcze łatwiejsze, a prezentowane metryki znacznie prostsze do zrozumienia.

Z drugiej strony martwi mnie fakt, że zmiana ta została dokonana kosztem bardziej zaawansowanych użytkowników, którzy korzystali np. z testów wielowymiarowych. Nie rozumiem również dlaczego został zmieniony sposób liczenia współczynnika konwersji (mam nadzieję, że zostanie to rychło poprawione).

Na pewno optymizmem napawa fakt, że wreszcie ktoś się schylił do pracy nad rozwojem aplikacji do przeprowadzania testów A/B w Google. GWO coraz bardziej zarastał pajęczyną, a konkurencja uciekała mu coraz dalej. Miejmy nadzieję, że nowe Eksperymenty Google Analytics będą starały się dotrzymać kroku konkurencji. Mam jedynie nadzieję, że dodatkowe funkcjonalności, jak choćby wspominane testy wielowymiarowe, nie staną się przywilejem jedynie użytkowników Google Analytics Premium.

Na koniec jeszcze jedno słowo: w polskim tłumaczeniu okropnie nie odpowiada mi słowo „eksperymenty”, które w naszym języku jest imho bardzo negatywnie nacechowane i mi osobiście kojarzy się z bardzo losowym sprawdzaniem, czy może uda nam się coś ustrzelić. Z drugiej strony mamy słowo „test”, który kojarzy mi się znacznie lepiej z próbą, która weryfikuje jakieś założenia. W związku z tym mam nadzieję, że w naszym branżowym języku słowo „testy A/B” nie zostanie wypchnięte przez „Eksperymenty A/B”

A teraz pytanie do Was: jak podoba Wam się to nowe narzędzie? Czy zgadzacie się z moimi spostrzeżeniami z tego artykułu, czy któreś z nich Wam się nie podobają? Umieszczajcie swoje opinie w komentarzach poniżej.

The post Eksperymenty Google Analytics (Content Experiments) first appeared on Conversion.