• W projekcie dla klienta z globalnego marketplace’u e-commerce Conversion przeprowadził wdrożenie analityczne skoncentrowane na odzyskaniu widoczności powracających użytkowników na Safari i iOS, gdzie standardowy pomiar zniekształcał obraz retencji i skuteczności marketingu.
• Kluczowym wyzwaniem były ograniczenia prywatności przeglądarek Apple, w tym Intelligent Tracking Prevention, które skracały żywotność cookies analitycznych i powodowały, że użytkownicy wracający po kilku lub kilkunastu dniach byli często rozpoznawani jako nowi.
• Przy ponad 50% ruchu mobilnego pochodzącego z iOS prowadziło to do zaburzeń w ocenie nowych użytkowników, retencji, ścieżek konwersji oraz skuteczności kanałów marketingowych.
• Zespół wdrożył rozwiązanie oparte na Cloudflare reverse proxy oraz server-side Google Tag Managerze, konfigurując środowisko tak, aby żądania narzędzi marketingowych były traktowane jako 1st party i były mniej podatne na ograniczenia przeglądarek.
• Następnie, na bazie eksportu danych z GA4 do BigQuery, porównano zachowanie użytkowników przed i po wdrożeniu, analizując m.in. powroty po ponad 7 dniach, liczbę sesji na użytkownika oraz różnice między przeglądarkami i urządzeniami.
• Efektem było odzyskanie widoczności realnych powrotów użytkowników na urządzeniach Apple: liczba rozpoznanych powrotów po 8 lub więcej dniach wzrosła z 33 do 451.
• Jednocześnie nie oznaczało to nagłego wzrostu liczby powracających użytkowników, lecz to, że system analityczny zaczął wreszcie poprawniej rozpoznawać zachowania, które wcześniej były ukryte przez ograniczenia technologiczne Safari i iOS.
• Projekt potwierdził, że w globalnym e-commerce poprawa jakości identyfikacji użytkowników może mieć bezpośredni wpływ na wiarygodność decyzji marketingowych.

Punkt wyjścia

Nasz klient działa w modelu globalnego marketplace’u e-commerce. Sprzedaje klucze do gier i oprogramowania klientom indywidualnym na wielu rynkach, współpracując jednocześnie z wieloma partnerami.

Przy takiej skali dane marketingowe są jednym z kluczowych elementów zarządzania biznesem. To na ich podstawie zespół podejmuje decyzje o budżetach reklamowych, kanałach, retargetingu i ocenie skuteczności działań performance.

Problem polegał na tym, że część tych danych mogła nie pokazywać rzeczywistości.

Szczególnie dotyczyło to użytkowników korzystających z urządzeń Apple’a iOS odpowiadał za ponad 50% całego ruchu mobilnego na stronie klienta.

Problem: powracający użytkownicy wyglądali jak nowi

Klient korzystał z danych w GA4 do oceny skuteczności marketingu. Jednak w przypadku Safari i przeglądarek na iOS pojawiał się istotny problem technologiczny.

Mechanizmy ochrony prywatności, w tym Intelligent Tracking Prevention, ograniczają żywotność cookies analitycznych. W praktyce oznacza to, że użytkownik, który odwiedził stronę, a następnie wrócił po kilku lub kilkunastu dniach, mógł zostać rozpoznany jako zupełnie nowa osoba.

Dla biznesu to nie jest techniczny detal. Jeśli system nie rozpoznaje użytkowników powracających, zaczyna zniekształcać podstawowe wnioski o marketingu.

Nowych użytkowników wydaje się być więcej, niż jest w rzeczywistości. Retencja wygląda gorzej, niż powinna. Ścieżki konwersji na iOS i Safari stają się mniej wiarygodne. Kanały, które skutecznie przyciągają użytkowników z powrotem, mogą być niedoceniane. A działania nastawione na pozyskanie nowych klientów mogą wyglądać na skuteczniejsze, niż są w rzeczywistości.

W efekcie decyzje o budżetach, retargetingu i ocenie kanałów były podejmowane na danych, które w przypadku istotnej części ruchu mobilnego mogły być zaburzone.

Nasze zadanie: dane powinny lepiej oddawać rzeczywiste zachowanie użytkowników

Celem projektu było poprawienie jakości identyfikacji użytkowników na Safari i iOS. Nie chodziło o „wyprodukowanie” lepszych wyników w raportach. Chodziło o to, żeby klient mógł zobaczyć to, co faktycznie działo się na stronie: że część osób wracała po kilku, kilkunastu lub ponad dwudziestu dniach – tylko wcześniej system analityczny nie zawsze potrafił ich poprawnie rozpoznać.

Wdrożyliśmy rozwiązanie oparte na Cloudflare reverse proxy oraz server-side Google Tag Managerze.

W uproszczeniu: skonfigurowaliśmy środowisko tak, aby żądania narzędzi marketingowych były traktowane jako 1st party, czyli jako bliżej powiązane z domeną klienta. Dzięki temu ograniczenia przeglądarek miały mniejszy wpływ na trwałość identyfikatorów analitycznych.

Architektura rozwiązania wyglądała następująco:

strona klienta → Cloudflare i konfiguracja DNS → server-side GTM na Cloud Run → GA4

Do analizy wykorzystaliśmy eksport danych z GA4 do BigQuery. Dzięki temu mogliśmy porównać sytuację przed i po wdrożeniu nie tylko na poziomie ogólnych metryk, ale przede wszystkim na poziomie zachowania użytkowników.

Sprawdzaliśmy między innymi:

• ilu użytkowników wracało po więcej niż 7 dniach,
• jak wyglądała liczba sesji na użytkownika,
• jak zmieniała się powracalność według przeglądarki,
• jak różniły się dane dla urządzeń mobilnych i desktopowych,
• czy Safari i iOS zaczęły pokazywać bardziej realistyczny obraz powrotów.

Wyniki analizy zostały przedstawione w Google Sheets, w formie pozwalającej zespołowi klienta łatwo porównać dane przed i po wdrożeniu.

Największe wyzwanie: tego efektu nie widać na pierwszy rzut oka w GA4

Reverse proxy nie jest typem wdrożenia, którego efekt można łatwo ocenić po jednym wykresie w standardowym panelu GA4.

Jeśli po wdrożeniu rośnie liczba sesji, użytkowników albo zdarzeń, nie oznacza to automatycznie, że odpowiada za to reverse proxy. Ruch może wzrosnąć z wielu powodów: kampanii reklamowych, sezonowości, promocji, zmian w budżetach czy naturalnych wahań popytu.

Dlatego kluczowe było zejście głębiej – do danych w BigQuery – i sprawdzenie konkretnego zachowania: czy użytkownicy wracający po okresie dłuższym niż 7 dni są lepiej rozpoznawani jako te same osoby.

To właśnie tam było widać realny efekt projektu.

Efekt: klient zobaczył powroty, których wcześniej nie widział

Przed wdrożeniem, gdy użytkownik korzystający z Safari lub iOS odwiedził stronę, a następnie wrócił na przykład po 10 dniach, GA4 często nie rozpoznawało go jako tej samej osoby. Cookie zdążyło wygasnąć, więc użytkownik dostawał nowy identyfikator.

W analizowanym okresie przed wdrożeniem zarejestrowano tylko 33 rozpoznane powroty użytkowników po 8 lub więcej dniach.

Po wdrożeniu reverse proxy takich powrotów było już 451.

To bardzo ważne: nie oznacza to, że nagle pojawiło się kilkanaście razy więcej powracających użytkowników.

Oznacza to, że ci użytkownicy najprawdopodobniej wracali już wcześniej, ale GA4 ich nie rozpoznawało. Po wdrożeniu system zaczął widzieć zachowania, które wcześniej były ukryte przez ograniczenia technologiczne przeglądarki.

Dzięki temu klient uzyskał bardziej wiarygodny obraz retencji, powracalności i ścieżek użytkowników na urządzeniach Apple.

Co zmieniło się biznesowo?

Po wdrożeniu klient może podejmować decyzje marketingowe na podstawie danych, które lepiej pokazują realne zachowania użytkowników. Zespół marketingu ma większą pewność, że osoba wracająca po 10, 15 czy 23 dniach na Safari lub iOS nie zostanie automatycznie potraktowana jako nowy użytkownik.

To przekłada się na lepszą ocenę:

• które kanały rzeczywiście pozyskują nowych użytkowników,
• które kanały wspierają powroty i konwersję w dłuższym czasie,
• jak wygląda retencja na urządzeniach Apple,
• jak interpretować ścieżki konwersji dla dużej części ruchu mobilnego,
• jak planować budżety reklamowe i retargeting.

Najważniejsza zmiana nie polegała więc na poprawieniu jednego wskaźnika w raporcie. Najważniejsze było odzyskanie zaufania do danych, na podstawie których podejmowane są decyzje marketingowe.

Podsumowanie

W globalnym e-commerce nawet niewielkie zniekształcenie danych może prowadzić do dużych konsekwencji biznesowych. Szczególnie wtedy, gdy dotyczy kanałów i urządzeń odpowiadających za znaczącą część ruchu.

W tym przypadku problemem nie było to, że użytkownicy nie wracali.

Problemem było to, że analityka nie zawsze była w stanie ich rozpoznać.

Dzięki wdrożeniu Cloudflare reverse proxy i server-side GTM klient zaczął widzieć znacznie więcej realnych powrotów użytkowników na Safari i iOS. Liczba rozpoznanych powrotów po 8+ dniach wzrosła z 33 do 451.

To dało zespołowi marketingu solidniejszą podstawę do oceny retencji, kanałów, remarketingu i alokacji budżetów.

Bo w analityce marketingowej nie chodzi tylko o to, żeby mieć dane.
Chodzi o to, żeby dane pokazywały rzeczywistość, a nie ograniczenia technologii.

The post Case Study – Jak odzyskaliśmy widoczność powracających użytkowników na iOS i Safari first appeared on Conversion.

Jak pomogliśmy TME.eu lepiej interpretować równoległe ścieżki użytkowników w wielu kartach przeglądarki?

W e-commerce B2B ścieżka zakupowa rzadko jest prosta i liniowa. Użytkownicy porównują produkty, wracają do wcześniejszych stron, otwierają kolejne karty, analizują szczegóły oferty i prowadzą kilka równoległych wątków zakupowych jednocześnie.

Dla standardowych narzędzi analitycznych taka aktywność często wygląda jak jeden ciąg zdarzeń w ramach jednej sesji. Problem pojawia się wtedy, gdy trzeba odpowiedzieć na pozornie proste pytanie: czy sekwencja zdarzeń rzeczywiście odzwierciedlała jedną liniową ścieżkę, czy w praktyce była efektem równoległej pracy w kilku kartach przeglądarki?

Dla zespołu TME.eu była to istotna bariera w interpretacji customer journey. Standardowe dane pokazywały aktywność użytkownika, ale nie zawsze pozwalały uchwycić kontekst, w którym ta aktywność miała miejsce. W efekcie analiza zachowań zakupowych mogła prowadzić do uproszczonych wniosków na temat kolejności działań, zależności między stronami i elementów ścieżki wymagających dalszej analizy.

Sytuacja TME.eu

TME.eu działa w modelu e-commerce B2B, w którym użytkownicy często wykonują bardziej złożone działania niż w prostym zakupie konsumenckim. Proces decyzyjny może obejmować analizę wielu produktów, porównywanie wariantów, powroty do wcześniejszych widoków oraz przechodzenie pomiędzy różnymi sekcjami serwisu.

W takim środowisku klasyczna analiza sesji użytkownika nie zawsze wystarcza. Jedna sesja może obejmować kilka równoległych wątków pracy: użytkownik otwiera produkt w nowej karcie, porównuje go z innym, wraca do listingu, sprawdza szczegóły techniczne, a następnie przechodzi dalej w procesie zakupowym.

Z perspektywy danych analitycznych wszystkie te działania mogą zostać zapisane jako jeden ciąg zdarzeń. Z perspektywy realnego zachowania użytkownika są to jednak często osobne konteksty pracy, które warto rozróżnić, aby lepiej interpretować dane.

Problem biznesowy

Zespół TME.eu potrzebował lepszego sposobu rozróżniania aktywności użytkowników w ramach jednej sesji, szczególnie w sytuacjach, gdy ta sama osoba korzystała równolegle z kilku kart przeglądarki.

Standardowe dane analityczne pozwalały zobaczyć kolejne zdarzenia użytkownika, ale nie dawały wystarczająco jasnej odpowiedzi, czy dane działania były częścią jednej liniowej ścieżki, czy kilku równoległych wątków.

To utrudniało interpretację customer journey.

Problem nie był wyłącznie techniczny. Dotyczył jakości interpretacji danych, na których później mogą opierać się analizy i rekomendacje optymalizacyjne. Jeżeli analityka nie rozróżnia aktywności wykonywanej w różnych kartach, łatwo o błędne lub zbyt uproszczone wnioski dotyczące:

• kolejności działań użytkownika,
• znaczenia poszczególnych stron w ścieżce zakupowej,
• zależności pomiędzy listingami, kartami produktów i kolejnymi krokami procesu,
• momentów, w których użytkownik zmieniał kontekst pracy,
• elementów serwisu wymagających dalszej analizy.

W praktyce mogło to prowadzić do mniej precyzyjnej interpretacji tego, jak użytkownicy poruszają się po serwisie i które fragmenty ścieżki zakupowej warto analizować w pierwszej kolejności.

Co zrobiliśmy?

Projekt rozpoczęliśmy od analizy zachowania identyfikatora karty w najważniejszych scenariuszach korzystania z przeglądarki.

Sprawdziliśmy między innymi:

• przeładowania strony,
• przejścia wewnętrzne w ramach serwisu,
• otwieranie nowych kart,
• duplikowanie istniejących kart,
• przywracanie sesji przeglądarki,
• pracę w różnych domenach i subdomenach,
• zachowanie mechanizmu w kontekście zgód analitycznych.

Na tej podstawie zaprojektowaliśmy mechanizm, który pozwala wzbogacać wybrane zdarzenia analityczne objęte wdrożeniem o dodatkowy kontekst techniczny pozwalający rozróżniać równoległe aktywności w obrębie jednej sesji.

Dzięki temu późniejsza analiza danych nie musi opierać się wyłącznie na liniowym ciągu zdarzeń w sesji, ale może uwzględniać dodatkowy kontekst: w jakiej karcie przeglądarki wystąpiła dana aktywność analityczna.

Celem rozwiązania nie było zwiększanie identyfikowalności użytkowników, lecz ograniczenie błędów interpretacyjnych w analizie ścieżek zakupowych. Dodatkowy parametr miał pomóc w lepszym uporządkowaniu danych analitycznych i rozróżnianiu równoległych kontekstów pracy w obrębie jednej sesji.

Technikalia

Rozwiązanie zostało oparte na dodatkowym identyfikatorze karty przeglądarki. Identyfikator został zaprojektowany tak, aby spełniał trzy kluczowe wymagania.

1. Losowość

Parametr musiał być wystarczająco unikalny, aby wiarygodnie odróżniać aktywność w różnych kartach.

2. Kompaktowość

Identyfikator musiał być możliwie krótki, aby nie zwiększać niepotrzebnie kosztów przechowywania i przetwarzania danych.

3. Możliwość sortowania po czasie utworzenia

Konstrukcja identyfikatora miała wspierać późniejszą analizę kolejności powstawania kontekstów pracy użytkownika.

Jak to przełożyło się na dane?

Parametr był tworzony w ramach odsłony i funkcjonował jako techniczny kontekst przypisany do danej karty przeglądarki. Wybrane zdarzenia analityczne objęte wdrożeniem mogły zostać wzbogacone o dodatkowy kontekst techniczny pozwalający rozróżniać równoległe aktywności w obrębie jednej sesji.

Dzięki temu zdarzenia mogły być analizowane nie tylko na poziomie sesji, ale również z uwzględnieniem technicznego kontekstu pracy w przeglądarce – konkretnej karty.

Przekazywanie parametru odbywało się z uwzględnieniem statusu zgód użytkownika. Rozwiązanie nie służyło identyfikacji konkretnych osób ani rozszerzaniu zakresu danych osobowych. Jego celem było poprawienie jakości interpretacji danych analitycznych poprzez dodanie technicznego kontekstu do zdarzeń objętych wdrożeniem.

Wdrożenie zostało przygotowane z uwzględnieniem specyfiki działania Google Tag Managera oraz istniejącego ekosystemu analitycznego TME.eu. Dzięki temu dodatkowy parametr mógł wzbogacać dane trafiające do Google Analytics 4 i BigQuery, tworząc nową warstwę kontekstu do dalszych analiz.

Wyzwania po drodze

Samo wdrożenie nie wymagało dodatkowego angażowania IT i nie wiązało się z problemami technicznymi po stronie TME.eu. Najważniejszym etapem była eksploracja dostępnych opcji i sprawdzenie, jak identyfikator karty będzie zachowywał się w realnych scenariuszach korzystania z przeglądarki.

Szczególnie istotne były przypadki, w których zachowanie użytkownika nie jest liniowe:

• użytkownik otwiera kilka produktów w osobnych kartach,
• duplikuje kartę,
• wraca do wcześniejszego widoku,
• przywraca sesję po zamknięciu przeglądarki,
• przechodzi pomiędzy domenami lub subdomenami,
• wykonuje działania w kilku kartach w krótkim odstępie czasu.

To właśnie te scenariusze były kluczowe z perspektywy jakości późniejszej interpretacji danych. Bez dodatkowego kontekstu technicznego część aktywności mogła wyglądać w raportach jak jeden liniowy ciąg zdarzeń, mimo że w praktyce była realizowana równolegle w kilku kartach.

Co się zmieniło po wdrożeniu?

Po wdrożeniu zespół TME.eu zyskał dodatkową warstwę kontekstu w danych analitycznych.

Zdarzenia analityczne mogą być analizowane nie tylko jako część jednej sesji, ale również z uwzględnieniem tego, w jakim technicznym kontekście pracy w przeglądarce wystąpiły.

Dzięki temu zespół TME.eu może dokładniej interpretować aktywność użytkowników, szczególnie w sesjach wielokartowych. To istotne w e-commerce B2B, gdzie użytkownicy często nie przechodzą przez serwis w prosty, sekwencyjny sposób, ale prowadzą kilka równoległych ścieżek analizy i porównywania produktów.

Nowe dane pomagają trafniej odpowiadać na pytania:

• czy sekwencja zdarzeń rzeczywiście odzwierciedlała jedną liniową ścieżkę,
• które działania były częścią tego samego kontekstu,
• kiedy użytkownik rozpoczął nowy wątek analizy,
• jak w danych przejawiają się równoległe scenariusze porównywania produktów,
• które elementy ścieżki zakupowej warto analizować dokładniej.

Nowe dane dały zespołowi TME.eu możliwość dokładniejszej analizy sesji wielokartowych. Dzięki dodatkowemu parametrowi zespół mógł sprawdzać, które zdarzenia należały do tego samego kontekstu pracy w przeglądarce, a które były częścią równoległego wątku.

Zespół TME.eu korzystał z rozwiązania i uznał je za wartościowe. Na tym etapie nie mamy jednak potwierdzonych informacji o konkretnych zmianach optymalizacyjnych wdrożonych bezpośrednio na podstawie tych danych, dlatego wartość projektu opisujemy przede wszystkim przez pryzmat poprawy jakości interpretacji danych.

Wartość biznesowa

Projekt nie polegał na dodaniu kolejnego parametru do raportu. Jego wartość polegała na poprawie sposobu interpretacji zachowań użytkowników w sytuacjach, w których standardowa analiza sesji mogła prowadzić do zbyt uproszczonych wniosków.

Wcześniej aktywność w wielu kartach mogła wyglądać w danych jak jedna liniowa ścieżka. Po wdrożeniu zespół TME.eu zyskał możliwość rozdzielania równoległych wątków pracy użytkownika i analizowania ich w bardziej realistyczny sposób.

To szczególnie ważne w kontekście e-commerce B2B, gdzie błędna interpretacja customer journey może wpływać na sposób oceny kluczowych elementów doświadczenia zakupowego.

Lepszy kontekst danych oznacza lepszą diagnozę sytuacji. A lepsza diagnoza daje solidniejszą podstawę do dalszych analiz, rekomendacji i potencjalnych działań optymalizacyjnych.

Przykład przed i po

Przed wdrożeniem

Użytkownik w jednej sesji otwiera kilka kart, porównuje produkty i wraca do wcześniejszych widoków. W danych analitycznych jego aktywność wygląda jak jeden ciąg zdarzeń.

Analityk widzi kolejne zdarzenia, ale nie ma pewności, które z nich były wykonane w tej samej karcie, a które były częścią równoległego wątku.

Efekt: trudniejsza interpretacja ścieżki i większe ryzyko uproszczonych wniosków.

Po wdrożeniu

Wybrane zdarzenia analityczne objęte wdrożeniem mogą zostać wzbogacone o techniczny kontekst konkretnej karty przeglądarki.

Analityk może rozdzielić aktywność użytkownika na równoległe konteksty i odtworzyć bardziej precyzyjny obraz sesji wielokartowej.

Efekt: dokładniejsza analiza customer journey i lepsza podstawa do dalszych rekomendacji analitycznych.

Podsumowanie

Projekt dla TME.eu pokazuje, jak dodatkowy kontekst techniczny może znacząco poprawić jakość interpretacji danych w złożonym środowisku e-commerce B2B.

Dzięki wdrożeniu identyfikatora karty przeglądarki zespół TME.eu zyskał możliwość rozróżniania równoległych ścieżek użytkowników w ramach jednej sesji, dokładniejszej analizy customer journey oraz lepszego zrozumienia sposobu porównywania produktów i poruszania się po serwisie.

Rozwiązanie wzbogaciło dane trafiające do Google Analytics 4 i BigQuery, tworząc solidniejszą podstawę do dalszych analiz i rekomendacji optymalizacyjnych.

The post TME.eu – Kiedy jedna sesja nie opowiada całej historii first appeared on Conversion.

Marketing i analityka – wyzwania
Metodyka KPI Tree – co to jest?
4 kroki metodyki KPI Tree
KPI Tree w praktyce – case study
Podsumowanie

Marketing i analityka – wyzwania

Z każdym rokiem rośnie liczba narzędzi i danych, z których korzystają zespoły marketingowe. W efekcie coraz trudniej utrzymać porządek, połączyć wszystkie elementy i zbudować z nich spójny system analityczny. W 2025 roku marketerzy e-commerce mieli do dyspozycji ponad 15 tysięcy różnych narzędzi. Różnica między marketingiem i e-commerce a układaniem klocków Lego polega na tym, że w przypadku Lego od początku wiadomo, jak z chaosu rozsypanych elementów zbudować konkretny model.

W pudełku znajduje się instrukcja, podział na mniejsze zestawy i jasny schemat łączenia kolejnych elementów. W marketingu sytuacja wygląda inaczej. Z chaosu metryk, źródeł danych i narzędzi powstają raporty oraz dashboardy, które często nie mają spójnej struktury ani jasnego celu.

Z moich obserwacji wynika, iż 90% dashboardów trafia do kosza w ciągu 30 dni od ich utworzenia. W analogii do klocków Lego taki dashboard w Data Studio przypomina model składany z kilku różnych zestawów, dodatkowo według instrukcji napisanej w niezrozumiałym języku. Skąd czerpać właściwe instrukcje, aby wykorzystywać wartościowe dane w marketingu? Jak przekształcić chaos metryk i narzędzi w raporty, które realnie wspierają marketing oraz e-commerce?

Metodyka KPI Tree – co to jest?

Odpowiedzią jest metodyka KPI Tree, którą opiszę w tym artykule. To podejście pomaga szybciej docierać do wniosków i skraca Time to Insight, czyli czas od pojawienia się problemu w biznesie, marketingu lub e-commerce do postawienia konkretnej hipotezy dotyczącej jego przyczyny.

Metodyka KPI Tree zwiększa też poczucie kontroli nad danymi i wynikami. Gdy pojawia się problem, można szybciej zidentyfikować jego źródło i podjąć odpowiednie działania. Zamiast przez tygodnie ustalać, gdzie „się pali”, zespół może już w ciągu jednego dnia przejść od sygnału ostrzegawczego do analizy przyczyn i rekomendacji. Jeśli odpowiadasz za wdrożenia narzędzi marketingowych i analitycznych, metodyka KPI Tree pomaga szybciej ustalić priorytety. Drzewo metryk pokazuje, które dane są istotne dla biznesu, dzięki czemu nie trzeba wdrażać wszystkiego naraz.

W wielu projektach przed zastosowaniem KPI Tree klienci chcieli mierzyć wszystko. Prowadziło to do przeciągania wdrożeń i opóźniało moment, w którym dane zaczynały realnie wspierać decyzje biznesowe. Dzięki KPI Tree szybciej uzyskujemy wartość z dostępnych danych, ponieważ koncentrujemy się na metrykach powiązanych z celami firmy.

W tym artykule opiszę metodykę, którą stosujemy u naszych klientów. KPI Tree składa się z czterech kroków i opiera się na dwóch znanych koncepcjach: mapowaniu Customer Journey oraz metodyce GSM.

4 kroki metodyki KPI Tree

Aby lepiej wyjaśnić znaczenie tego podejścia, warto przywołać typową sytuację ze spotkania statusowego z klientem lub zarządem. Pada pytanie: dlaczego marketing nie dowiózł wyników? Pierwszy problem polega na tym, że osoba zadająca pytanie ma w głowie własny model oczekiwań – coś w rodzaju gotowej konstrukcji z klocków Lego. Tymczasem zespół ma przed sobą jedynie stertę klocków, czyli dane, metryki i narzędzia, które wymagają uporządkowania. Często nie wiemy, co dokładnie mamy ułożyć z dostępnych „klocków” danych.

Krok 1: Definicja głównych KPI biznesowych

Pierwszym krokiem metodyki KPI Tree jest więc zdefiniowanie najważniejszych KPI w biznesie. Innymi słowy: trzeba ustalić, jaki cel ma w głowie zarząd, dyrektor lub klient, gdy zadaje pytanie o wyniki. W praktyce oznacza to wskazanie dwóch lub trzech najważniejszych KPI szefa, klienta, a jeszcze lepiej – szefa Twojego szefa lub szefa klienta. To właśnie ta osoba decyduje, czy partner, z którym rozmawiasz, osiąga sukces biznesowy.

Można porównać to do klocków LEGO. Wyobraźmy sobie mały klocek wyjęty z większego modelu. W metodyce KPI Tree taka metryka powinna być odczuwalna jak nadepnięcie bosą stopą na mały klocek w środku nocy. Jeśli dany KPI realnie „boli”, oznacza to, że ma znaczenie biznesowe. Dlatego większość kluczowych KPI jest powiązana z finansami firmy. Są blisko raportu zysków i strat, ponieważ bezpośrednio wpływają na ocenę kondycji biznesu.

Ostatnio przekonałem się o tym w bardzo konkretny sposób. Jesteśmy na etapie zbierania feedbacku dotyczącego naszego nowego rozwiązania. Jednym z elementów prezentacji jest slajd, na którym pytamy dyrektorów e-commerce i dyrektorów marketingu, jak wyglądają ich spotkania z zarządem oraz jakie tematy pojawiają się w kontekście danych. Ostatnio Michał, który przekazywał nam feedback do narzędzia, zwrócił uwagę na ważną rzecz: na takich spotkaniach zarządu nikt zwykle nie pyta o ROAS ani modele atrybucji. Najczęściej pojawiają się pytania o pieniądze: przychody, wyniki, sprzedaż i zysk.

Dobrym przykładem może być e-commerce pokroju Leroy Merlin. Gdy analizujemy KPI dla takiej organizacji, trzy główne wskaźniki to zazwyczaj: przychody, transakcje, liczba zakupionych produktów. W 70–80% przypadków główne KPI są bezpośrednio związane ze sprzedażą. Kluczowe jest jednak ich precyzyjne zdefiniowanie. Jeśli analizujemy przychód, trzeba ustalić, czy mówimy o wartości z VAT, czy bez VAT. Narzędzia analityczne najczęściej raportują przychody z VAT, co wpływa na sposób prezentacji danych. W finansach, zwłaszcza w rachunku zysków i strat, VAT pozostaje neutralny.

Dane mogą obejmować koszt dostawy lub go pomijać. Z perspektywy CFO koszty dostawy w raportowaniu przychodów często nie są kluczowe, ponieważ nierzadko obniżają zysk organizacji. Coraz częściej firmy częściowo dofinansowują dostawy dla użytkowników. Podobnie należy uwzględnić sposób raportowania zwrotów. Dla marketingu istotny jest przychód wygenerowany przez e-commerce, ale w analizie finansowej trzeba jasno określić, czy raport obejmuje VAT, koszty dostawy oraz zwroty. CFO musi uwzględnić dodatkowe odliczenia. Często są to bardzo duże kwoty, sięgające nawet 50% raportowanego przychodu. Oznacza to, że przychód wygenerowany lub zaraportowany przez marketing trzeba pomniejszyć o zwroty, które pojawiły się po finalizacji transakcji.

Pierwszym krokiem jest więc precyzyjna definicja analizowanego wyniku. Jeśli partner podczas spotkania pyta, dlaczego nie osiągnęliście zakładanych wyników, warto doprecyzować, czy chodzi o przychód. Dzięki temu wiadomo, z jakich narzędzi i danych dostępnych w marketingu trzeba skorzystać oraz jak powinien wyglądać model analityczny. W przypadku e-commerce mechanizm generowania przychodu jest stosunkowo prosty. Przychód w e-commerce składa się z trzech głównych elementów. Pierwszym z nich jest pozyskanie użytkownika, czyli ruch na stronie. Użytkownika trzeba skutecznie doprowadzić do konwersji. Jakość tego procesu opisuje współczynnik konwersji, który pokazuje, jak serwis i działania marketingowe przekładają się na oczekiwane działania użytkowników.

Kolejną istotną metryką jest średnia wartość zamówienia, zależna od tego, jakie produkty kupują użytkownicy. Te dane są dostępne bezpośrednio w narzędziach analitycznych i można je szybko zwizualizować. Na wykresie warto zestawić cztery metryki: przychody, współczynnik konwersji, ruch oraz średnią wartość zamówienia. Przychody są metryką wynikową, natomiast pozostałe trzy wyjaśniają, z czego wynika poziom przychodów w e-commerce.

Krok 2: Mapowanie Customer Journey i touchpointów

Taka wizualizacja pozwala szybko zauważyć, czy spadek przychodów wynika na przykład ze spadku współczynnika konwersji. Jeśli klient lub przełożony zapyta, dlaczego przychód nie został osiągnięty, odpowiedź „ponieważ spadł współczynnik konwersji” zwykle nie wystarczy. Taka informacja nie wyjaśnia przyczyny problemu ani nie wskazuje, które elementy procesu wymagają poprawy. Dlatego drugim krokiem w metodyce KPI Tree jest zmapowanie touchpointów, z którymi użytkownik styka się w ekosystemie online. W praktyce często obejmuje on e-commerce oraz powiązane z nim produkty, usługi, serwisy lub aplikacje.

W kontekście customer journey najczęściej pojawia się skojarzenie z lejkiem marketingowym. Istnieje wiele modeli takiego lejka, a jednym z najpopularniejszych jest model AIDA. Zakłada on, że użytkownik przechodzi przez etapy: świadomości (awareness), zainteresowania (interest), pożądania (desire) oraz podjęcia konkretnej akcji (action). Problem polega na tym, że decyzje użytkowników nie zawsze przebiegają liniowo. Ścieżka zakupowa rzadko wygląda jak prosty, przewidywalny proces od pierwszego kontaktu z marką do konwersji. Liczba użytkowników, którzy otrzymali trigger zakupowy, jest największa na początku procesu. Część z nich zyskuje świadomość marki lub produktu. Następnie mniejsza grupa wykazuje zainteresowanie, a jeszcze mniejsza zaczyna odczuwać potrzebę zakupu. Ostatecznie tylko część użytkowników dokonuje transakcji.

W praktyce proces zakupowy coraz częściej opisuje się za pomocą koncepcji tzw. Messy middle to koncepcja opisana w badaniu Google, które pokazuje, jak użytkownicy podejmują decyzje zakupowe. Proces ten jest silnie nieliniowy – użytkownik przechodzi między różnymi etapami i punktami styku, zanim zdecyduje się na zakup. Na etapie tworzenia KPI Tree kluczowe jest zmapowanie elementów ekosystemu, które mogą wpływać na decyzję zakupową. Istotne są przede wszystkim te obszary, na które firma ma realny wpływ. Oznacza to, że można pozyskać z nich dane, a następnie – na podstawie wniosków z analizy – wprowadzać konkretne zmiany optymalizacyjne.

Dobrym przykładem jest Leroy Merlin, szczególnie w kontekście kategorii łazienek. Touchpointami wpływającymi na złożenie zamówienia będą tu między innymi proces zakupowy, czyli checkout, koszyk, karta produktu oraz karta kategorii. Wokół samego e-commerce związanego z łazienkami pojawiają się również dodatkowe elementy wspierające użytkownika w procesie decyzyjnym. Należą do nich strony z poradami, kalkulator liczby płytek czy sekcja dotycząca projektowania łazienki. Każdy z tych elementów może pomagać użytkownikowi w podjęciu decyzji zakupowej, dlatego powinien zostać uwzględniony w analizie KPI. W analogii z klockami LEGO Customer Journey oznacza identyfikację „torebek”, które wyselekcjonowaliśmy z całego zestawu. Każda z nich jest potrzebna do złożenia konkretnego elementu naszej budowli: dźwigu, podwozia, kabiny lub innej części konstrukcji.

Krok 3: Wykorzystanie metodyki GSM (Goal, Signal, Metric)

Pojawia się jednak pytanie: skoro mamy już wyodrębniony subzestaw, jak połączyć jego poszczególne elementy? W tym miejscu wchodzi trzeci krok metodyki KPI Tree, czyli metodyka GSM. GSM pomaga określić: jaki cel ma dany touchpoint, czyli goal, jakie sygnały, czyli zachowania użytkownika, wskazują na realizację tego celu – signals, oraz jakie metryki możemy przypisać do tych sygnałów i zachowań. W praktyce oznacza to przełożenie faktycznych zachowań użytkowników na język danych.

Przykładem mogą być strony z poradami w serwisie leroymerlin.pl. Ich celem jest wsparcie użytkowników w procesie zakupowym. Jeśli użytkownicy trafiają na takie treści, powinny one pomóc im podjąć decyzję i finalnie zrobić zakupy w sklepie. Po pierwsze, użytkownicy muszą trafiać na treści poradnikowe. Po drugie, powinni przechodzić z porad do asortymentu sklepu. Do tych celów należy dobrać odpowiednie metryki. Dla oceny zasięgu treści poradnikowych sprawdzi się liczba użytkowników. Dla analizy przejść warto wykorzystać procent użytkowników, którzy po wizycie na stronie z poradami przeszli na strony kategorii, strony konkretnych produktów lub wyniki wyszukiwania.

W przypadku kalkulatora liczby płytek GSM może opierać się na podobnym podejściu, choć jego definicja zależy od celu tego narzędzia. Kalkulator liczby płytek ma usuwać obiekcję zakupową i pomagać użytkownikowi określić, ile płytek powinien kupić. Sygnałem zainteresowania kalkulatorem jest liczba użytkowników, którzy weszli z nim w interakcję. Sygnałem potwierdzającym, że kalkulator spełnił swoją funkcję, są przejścia z kalkulatora na stronę produktu lub stronę kategorii. Do tych sygnałów należy dobrać odpowiednie metryki: liczbę użytkowników korzystających z kalkulatora oraz procent przejść z kalkulatora do asortymentu.

Krok 4: Szukanie zależności i budowa ekosystemu

Dzięki przypisaniu celów, sygnałów i metryk do poszczególnych elementów otrzymujemy instrukcję mapowania ich w spójny system analityczny. Jeśli każdy element jest opisany osobno, na końcu pozostaje połączenie ich w całość, która działa jako jeden uporządkowany mechanizm. Ostatni, czwarty krok metodyki KPI Tree polega na szukaniu zależności pomiędzy touchpointami. To rodzaj mapy, na której rozpisane są touchpointy wraz z przypisanym do nich GSM. Stanowi ona uzupełnienie customer journey i pokazuje, jak użytkownik przechodzi pomiędzy kolejnymi elementami ścieżki.

Finalnym efektem pracy nad KPI Tree jest rozpisanie w pliku Excel poszczególnych elementów: touchpointów wynikających z mapowania customer journey oraz przypisanego do nich GSM. Najwygodniejszym rozwiązaniem jest prosta struktura w Excelu. Alternatywnie można wykorzystać mapę myśli, jednak w naszych projects najczęściej pracujemy właśnie na arkuszach. Dopiero na ich podstawie powstaje ostateczny dashboard.

KPI Tree w praktyce – case study

Pierwszy dashboard ma charakter ogólny – pokazuje dane z perspektywy całego ekosystemu. W kolejnym etapie analizy przechodzimy głębiej i tworzymy raporty szczegółowe dla poszczególnych touchpointów. KPI Tree można analizować zarówno na poziomie całego ekosystemu, jak i wybranych jego elementów. Przykładem jest kategoria łazienek w Leroy Merlin, ale równie dobrze można przygotować osobne raporty dla strony z poradami czy kalkulatora liczby płytek. Na tym poziomie analiza obejmuje już znacznie bardziej szczegółowe dane.

Dobrym przykładem wykorzystania KPI Tree jest sytuacja jednego z naszych klientów, firmy o skali porównywalnej do Leroy Merlin. W 2025 roku klient zauważył spadek przychodów. Po stworzeniu KPI Tree szybko zidentyfikowaliśmy przyczynę spadku przychodu końcowego. Analiza wykazała znaczący spadek ruchu na stronach poradnikowych. Zbiegło się to w czasie z wdrożeniem AI Overviews, które wprowadzono w marcu 2025 roku.

Dzięki szybkiemu zidentyfikowaniu przyczyny mogliśmy przeznaczyć czas, który zwykle zajmuje diagnoza problemu, na pogłębioną analizę wpływu AI Overviews na ruch organiczny. Kluczowe jest to, że bez KPI Tree proces analizy danych wyglądałby inaczej. Najpierw pojawiłby się problem. Następnie zespół musiałby go zauważyć, najlepiej od razu, a dopiero później rozpocząłby analizę przyczyn spadku. Kiedy brakuje KPI Tree, problem zwykle zauważamy dopiero po kilku dniach. Następnie trzeba znaleźć osobę odpowiedzialną za analizę, która rozpoczyna zbieranie niezbędnych danych. Jeśli nie pojawią się rozbieżności wymagające dodatkowych wyjaśnień, proces przebiega sprawniej. Po zakończeniu analizy formułujemy insight, co zazwyczaj zajmuje od dwóch do trzech tygodni.

W przypadku KPI proces wygląda inaczej. Insight pojawia się w ciągu kilku dni, często jeszcze tego samego dnia. Zaoszczędzony czas można przeznaczyć na pogłębienie analizy, podobnie jak w opisanym case study. Insight wskazuje, gdzie pojawia się problem. Można porównać go do zwiadu, który rozpoznaje sytuację i identyfikuje obszary wymagające uwagi. Gdy wiadomo, gdzie leży problem, przechodzimy do pogłębionej analizy, która pozwala znaleźć jego przyczynę i zaproponować konkretne rozwiązanie.

Podsumowanie

Tak działa praca z metodyką KPI Tree. Gdy podczas kolejnego statusu pojawi się pytanie o wyniki, nie trzeba wracać do chaosu danych, rozproszonych metryk i dashboardów tworzonych ad hoc, które po 30 dniach przestają być użyteczne. Istnieje lepsze podejście: uporządkowanie pracy z danymi z wykorzystaniem metodyki KPI Tree.

Proces opiera się na czterech krokach: pracy na kanwie, mapowaniu Customer Journey oraz metodyce GSM. Najpierw definiujemy najważniejsze KPI. Następnie mapujemy touchpointy w ekosystemie, które wspierają decyzję o zakupie. Po trzecie, dla każdego touchpointu określamy cele, sygnały potwierdzające ich realizację oraz dobieramy odpowiednie metryki. Po czwarte, mapujemy wszystkie elementy i opisujemy zależności między nimi.

Zachęcam do skorzystania z tej metodyki. Jeśli ten materiał nie wyczerpuje tematu, w opisie znajduje się link do naszego bezpłatnego e-booka o tym, jak przejść przez metodykę KPI Tree i przygotować drzewo metryk. Metodyka opisana w e-booku pomoże uporządkować cele, sygnały i metryki oraz przełożyć je na praktyczną analizę danych. Zachęcam do skorzystania z tego materiału oraz bezpłatnego e-booka.

The post Sposób na chaos w danych – KPI Tree first appeared on Conversion.

Czym jest DataMate?
Jak działa DataMate w praktyce?
Jak uzyskać dostęp do narzędzia?
Podsumowanie

Czym jest DataMate?

DataMate to asystent AI, w którym zgromadziliśmy naszą wiedzę z zakresu analityki internetowej, narzędzi Google i procesów data-driven marketingu. W tym artykule opiszę, czym jest DataMate i jak może wspierać zespoły marketingowe w codziennej pracy z danymi. DataMate jest obecnie agregatorem wiedzy z kanału YouTube Conversion oraz firmowego bloga. W przyszłości rozwiniemy go o wewnętrzne bazy wiedzy, metodyki wypracowywane we współpracy z klientami oraz materiały zewnętrzne, takie jak dokumentacje.

Ambicją Conversion w kontekście DataMate jest stworzenie jednego, kompletnego źródła wiedzy o marketingu, technologii i danych online.

Jak działa DataMate w praktyce?

Jak działa DataMate? Poniżej opisuję to na przykładzie jednego z ostatnich zadań projektowych. Na początku czerwca podczas konferencji SemKRK zaprezentowałem temat KPI Tree – zachęcam również do obejrzenia materiału podsumowującego to wystąpienie. Po wystąpieniu otrzymałem pytania od uczestników. Na część z nich odpowiedziałem na scenie, a pozostałe przekazali mi organizatorzy z prośbą o przygotowanie odpowiedzi w formie wywiadu.

Przykładowe wykorzystanie asystenta

Poniżej przedstawiam te pytania oraz sposób, w jaki można odpowiedzieć na nie z pomocą naszego asystenta. W tym celu przechodzę do Datamate. Po zalogowaniu widoczna jest historia dotychczasowej konwersacji oraz okno czatu, w którym można zadać konkretne pytanie. Po wybraniu pierwszego pytania i kliknięciu „Wyślij” narzędzie przeszukuje bazę wiedzy, a następnie generuje odpowiedź na podstawie dostępnych informacji.

Przykładowe pytanie brzmi: „Wchodzisz do firmy, która ma dane, ale nic z nimi nie robi. Od czego konkretnie zaczynasz w pierwszym tygodniu?”.

Odpowiedź: W pierwszym tygodniu nie zaczynam od budowania dashboardu. Priorytetem jest szybki audyt: jakie dane są zbierane, gdzie się znajdują i kto ma do nich dostęp. Proces można podzielić na cztery konkretne etapy. Odpowiedzi na 13 pytań zadanych po konferencji dobrze pokazują, w jaki sposób można wykorzystać DataMate w praktyce. Narzędzie wspiera pracę z danymi i pomaga szybciej uzyskać konkretne odpowiedzi analityczne.

Jak uzyskać dostęp do narzędzia?

Jak uzyskać dostęp do DataMate? Wystarczą trzy proste kroki:

1. Wejdź na stronę datamate.pl.

2. Podaj adres e-mail, na który zostanie wysłany indywidualny link dostępowy.

3. Korzystaj z narzędzia, zadawaj pytania i testuj jego możliwości. Sposób zadawania pytań wpływa na to, jak DataMate uczy się podsuwać odpowiedzi. Użytkownik może ocenić każdą odpowiedź za pomocą kciuka w górę lub kciuka w dół. Na podstawie tych ocen narzędzie doskonali swoje działanie.

Obecnie prowadzimy otwarte testy, a DataMate pozostaje bezpłatny. Tworzymy grupę użytkowników, z którymi rozwijamy narzędzie i zbieramy informacje zwrotne. Z DataMate korzysta już ponad 100 zaangażowanych osób.

Pierwsze statystyki oraz dodatkowe informacje opublikowaliśmy w podsumowaniu wyników z testów. Link do posta na LinkedIn znajduje się poniżej. Zawiera konkretne statystyki, które mogą pomóc lepiej zrozumieć omawiany temat.

Podsumowanie

DataMate pozwala korzystać z wiedzy Conversion w uporządkowany sposób, szczególnie w kontekście FOMO obecnego na rynku analityki i AI. Liczba źródeł wiedzy rośnie bardzo szybko, a użytkownicy często mierzą się z nadmiarem informacji. W przypadku DataMate’a wiedza jest sprofilowana na podstawie naszych projektów, pracy z klientami i doświadczenia zespołu Conversion. Zachęcam do podzielenia się feedbackiem po rozpoczęciu korzystania z rozwiązania.

The post Datamate, czyli 100k+ godzin doświadczenia w analityce online w jednym narzędziu first appeared on Conversion.

• W projekcie dla klienta z branży retail / e-commerce Conversion przeprowadził analizę ścieżki zakupowej, koncentrując się na identyfikacji ukrytego tarcia wpływającego na wygodę zakupu i interpretację danych.
• Kluczowym wyzwaniem było to, że 12% wszystkich dodań do koszyka następowało dopiero na stronie koszyka, a nie na karcie produktu, co wydłużało proces zakupowy, obniżało intuicyjność ścieżki i mogło prowadzić do błędnych wniosków analitycznych dotyczących zachowań użytkowników.
• Zespół przeanalizował moment dodania produktu do koszyka, porównał zachowania użytkowników na poziomie karty produktu i koszyka oraz zestawił dane z kategoriami i typami produktów.
• Analiza opierała się na danych eventowych z platformy e-commerce oraz danych GA4 dostępnych w BigQuery.
• Efektem było wykrycie, że problem nie wynikał z samych intencji zakupowych użytkowników, lecz z ograniczenia UX, które przesuwało część działań na późniejszy etap procesu i zniekształcało obraz ścieżki zakupowej.
• Projekt pokazał, że rozwinięta analityka e-commerce może ujawniać nieoczywiste bariery zakupowe, które jednocześnie wpływają na doświadczenie użytkownika i jakość wniosków biznesowych opartych na danych.

Detale w ścieżce zakupowej mają znaczenie w każdym e-commerce. W segmencie premium ich waga jest jednak jeszcze większa – gdy transakcji jest mniej, ale ich wartość pozostaje wysoka, nawet niewielkie tarcie może przełożyć się na odczuwalną stratę sprzedaży.

Tak było w tym projekcie. Nasz klient chciał lepiej zrozumieć zachowania użytkowników i sprawdzić, które produkty oraz kategorie najczęściej kończą się zakupem, a które odpadają po drodze. Analiza miała pomóc odpowiedzieć na pytania związane z konwersją i optymalizacją ścieżki zakupowej.

W praktyce wydarzyło się coś więcej. Dzięki szczelnemu śledzeniu i pracy na danych eventowych udało się wychwycić nieoczywisty problem, który nie tylko utrudniał zakup, ale też zaburzał interpretację danych o konwersji poszczególnych kroków zakupowych.

Sytuacja klienta z branży retail / e-commerce?

Klient działa w branży retail / e-commerce, w segmencie mebli premium i wyposażenia wnętrz. Model biznesowy jest omnichannelowy i obejmuje zarówno sprzedaż online, jak i salony stacjonarne. Firma działa głównie na rynku polskim.

Z perspektywy analitycznej istotne było to, że biznes operuje na:

• relatywnie niższym wolumenie transakcji,
• ale przy wysokiej wartości koszyka,
• co oznacza, że nawet pozornie drobne tarcie w ścieżce zakupowej może mieć istotne znaczenie biznesowe.

Po stronie klienta współpraca odbywała się przede wszystkim z:

• Head of Technology
• Digital Marketing Supervisorem

Punkt wyjścia: potrzeba lepszego zrozumienia koszyka

Celem analizy było dokładniejsze poznanie zachowań użytkowników na etapie koszyka. Klienta interesowało między innymi:

• dlaczego użytkownicy porzucają koszyk,
• czy dodają więcej produktów z tej samej kategorii, a kupują tylko część z nich,
• które produkty i kategorie mają najlepszy lub generują najwięcej porzuconych koszyków

Był to więc klasyczny temat związany z analizą konwersji i zachowań zakupowych. Jednak już na etapie pracy z danymi okazało się, że część obrazu jest bardziej złożona, niż sugerowały to standardowe wskaźniki.

Problem, który pojawił się “przy okazji”

W toku analizy zauważyliśmy istotny wzorzec zachowań: część użytkowników dodawała produkty do koszyka dopiero na stronie koszyka, a nie na karcie produktu.

To nie było przypadkowe. Wynikało z konstrukcji ścieżki zakupowej.

Nie był to problem, który musiał od razu rzucać się w oczy. W segmencie mebli premium wiele produktów kupuje się pojedynczo – jedną sofę, jeden stół czy jeden regał – więc brak możliwości wyboru liczby sztuk na karcie produktu przez długi czas mógł pozostawać niezauważony.

Ograniczenie stawało się istotne przede wszystkim przy produktach kupowanych w większej liczbie, zwłaszcza krzesłach. W tych przypadkach użytkownik najpierw musiał dodać produkt do koszyka, a dopiero tam zwiększyć jego liczbę.

Na pierwszy rzut oka mogło to wyglądać jak naturalne zachowanie użytkownika. W rzeczywistości było skutkiem ograniczenia UX, które wpływało zarówno na wygodę zakupu, jak i na sposób odczytywania danych.

Dlaczego to miało znaczenie?

Z analizy wynikało, że 12% wszystkich dodań do koszyka następowało dopiero na stronie koszyka.

To był bardzo ważny sygnał. Taka sytuacja pokazywała, że część użytkowników zainteresowanych zakupem kilku sztuk tego samego produktu nie przechodziła ścieżki w sposób naturalny i wygodny.

Wpływ był wielowymiarowy.

Po pierwsze, doświadczenie zakupowe traciło na intuicyjności. Teoretycznie użytkownik mógł dodać ten sam produkt do koszyka wielokrotnie już z poziomu karty produktu, ale nie była to ścieżka szczególnie wygodna. W efekcie część osób przechodziła do koszyka wcześniej, aby dopiero tam sprawniej ustawić docelową liczbę sztuk.

Po drugie, zakup się wydłużał. Każdy dodatkowy krok to potencjalne miejsce frustracji, wahania lub porzucenia procesu.

Po trzecie, zaburzeniu ulegała interpretacja danych. Jeśli część aktywności związanej z dodaniem produktu do koszyka przenosi się z karty produktu na poziom koszyka, to standardowe odczyty dotyczące konwersji poszczególnych etapów mogą prowadzić do niepełnych lub błędnych wniosków.

W praktyce oznaczało to, że klient mógł oceniać skuteczność ścieżki zakupowej na podstawie obrazu, który nie do końca oddawał rzeczywiste intencje użytkowników.

Nasze podejście

W ramach analizy przyjrzeliśmy się dokładnie momentowi dodania produktu do koszyka i sprawdziliśmy, czy akcja następowała na karcie produktu, czy dopiero w koszyku. Zestawiliśmy te dane z kategoriami i typami produktów, żeby zobaczyć, gdzie wzorzec występuje najczęściej i z czego może wynikać.

Od strony technicznej analiza opierała się na danych eventowych z platformy e-commerce oraz danych GA4 dostępnych w BigQuery. Kluczowe było szczelne śledzenie zdarzeń koszykowych, spójna identyfikacja produktów i dobra jakość danych, bo tylko to pozwalało poprawnie odtworzyć rzeczywistą ścieżkę użytkownika.

Dzięki temu mogliśmy precyzyjnie wskazać, że zjawisko dodawania produktów do koszyka dopiero na etapie koszyka koncentrowało się przede wszystkim wokół krzeseł, czyli kategorii naturalnie częściej kupowanej w większej liczbie sztuk.

Biznesowo przełożyło się to na coś więcej niż sam raport. Klient zyskał jasną diagnozę, że część zachowań w koszyku nie wynikała z naturalnych decyzji użytkowników, ale z ograniczenia na karcie produktu. To pozwoliło spojrzeć na dane o konwersji w bardziej trafny sposób i wskazać konkretny obszar do poprawy w ścieżce zakupowej.

Co zmieniło się po analizie?

Analiza na danych i wynikająca z niej rekomendacja dały klientowi konkretną podstawę do dalszych działań. Problem został precyzyjnie nazwany, osadzony w danych i przełożony na jasny kierunek zmian po stronie IT.

W praktyce oznaczało to możliwość zakolejkowania modyfikacji karty produktu — tak, aby użytkownik mógł wybrać liczbę sztuk już przed przejściem do koszyka, szczególnie w przypadku produktów częściej kupowanych po kilka sztuk.

The post Case Study: 12% dodań do koszyka działo się zbyt późno. Jak analityk odkrył problem w ścieżce zakupowej? first appeared on Conversion.

• W projekcie dla klienta z branży Health & Beauty / FMCG Conversion wykorzystał wcześniej wdrożoną architekturę server-side GTM, aby uruchomić dodatkowy pomiar konwersji zakupowych dla wybranych marek promowanych w aplikacji mobilnej.
• Kluczowym wyzwaniem była potrzeba szybkiego wdrożenia nowej logiki analitycznej bez angażowania zespołu IT, bez zmian w kodzie aplikacji i bez czekania na release oraz aktualizacje po stronie użytkowników.
• Dodatkowo pierwsze próby budowy zdarzenia po stronie aplikacji nie dawały kompletnych danych.
• Zespół przeanalizował dane przesyłane z aplikacji, opracował logikę identyfikującą transakcje dla wskazanych marek i przygotował dodatkowe zdarzenie zakupowe w warstwie server-side GTM, dbając o poprawność danych i zgodność z wymaganiami ekosystemu Google.
• Całość wdrożono bez angażowania zespołu developerskiego klienta.
• Efektem było znaczące skrócenie czasu wdrażania zmian analitycznych, większa elastyczność przy działaniach promocyjnych i partnerskich oraz mniejsze uzależnienie marketingu i analityki od backlogu IT.
• Klient zyskał możliwość uruchamiania nowych konwersji zakupowych w aplikacji bez każdorazowego wydawania nowej wersji aplikacji.
• Projekt potwierdził, że dobrze zaprojektowana architektura server-side GTM może nie tylko poprawiać jakość pomiaru, ale też realnie zwiększać szybkość działania biznesu i przewagę operacyjną w środowisku retailowym.

Punkt wyjścia

W retailu i marketingu cyfrowym sama dostępność danych to za mało. Równie ważna jest możliwość szybkiego reagowania na potrzeby biznesu. Problem zaczyna się wtedy, gdy nawet drobna zmiana w analityce wymaga zaangażowania zespołu IT, publikacji nowej wersji aplikacji i czekania, aż użytkownicy ją zaktualizują.

W tym przypadku klient potrzebował uruchomić dodatkowy pomiar konwersji zakupowych dla wybranych marek promowanych w aplikacji mobilnej. Na pierwszy rzut oka była to niewielka modyfikacja. W praktyce mogła jednak oznaczać długi proces po stronie developmentu i znacznie ograniczyć tempo działania biznesu.

Dzięki temu, że wcześniej wdrożyliśmy server-side GTM, mogliśmy podejść do tego inaczej – szybciej, sprawniej i bez konieczności wprowadzania zmian w kodzie aplikacji.

Wyzwanie: nowa konwersja, stary problem

Klient działa na polskim rynku w modelu retail, w segmencie Health & Beauty / FMCG. W projekcie współpracowaliśmy bezpośrednio z osobą odpowiedzialną za analitykę online w obszarze Marketingu, MarTech & Own Media.

Potrzeba biznesowa była jasna: uruchomić dodatkowe konwersje zakupowe dla transakcji obejmujących wybrane marki, tak aby dokładniej mierzyć skuteczność działań promocyjnych prowadzonych w aplikacji mobilnej. Wydawałoby się proste, a jednak.

W tym projekcie pojawiły się dwa kluczowe ograniczenia. Po pierwsze, dostępność zespołu IT była ograniczona, co utrudniało szybkie wdrażanie zmian. Po drugie, pierwsze próby przygotowania dodatkowego zdarzenia po stronie aplikacji nie dały oczekiwanego efektu — zdarzenia były niekompletne i nie zawierały wszystkich parametrów potrzebnych do dalszego wykorzystania.

To oznaczało realne ryzyko, że zmiana, która biznesowo powinna być szybka i operacyjna, utknie w procesie developmentu, testów, publikacji nowej wersji aplikacji i oczekiwania na aktualizacje po stronie użytkowników

Rozwiązanie: więcej z danych, mniej pracy po stronie aplikacji

Klient miał już wcześniej wdrożony server-side GTM dla aplikacji mobilnej, który zrealizowaliśmy w ramach naszej współpracy. Dzięki temu mieliśmy solidną bazę do kolejnych działań.

Zamiast ingerować w kod aplikacji, zaproponowaliśmy wykorzystanie istniejącej architektury server-side, która daje pełną kontrolę nad danymi jeszcze zanim trafią one na serwery Google. Dzięki temu nie trzeba było przebudowywać aplikacji — wykorzystaliśmy istniejącą warstwę pośredniczącą, by przetworzyć i rozszerzyć dane, które już były zbierane z aplikacji.

Po naszej stronie zakres prac obejmował:

• analizę danych przesyłanych z aplikacji,
• opracowanie logiki identyfikującej transakcje dotyczące wskazanych marek,
• przygotowanie dodatkowego zdarzenia zakupowego w warstwie server-side GTM,
• zadbanie o poprawność i zgodność danych z wymaganiami ekosystemu Google.

Całość wdrożyliśmy bez konieczności angażowania zespołu developerskiego klienta.

W praktyce oznaczało to, że zamiast przebudowywać aplikację, wykorzystaliśmy istniejącą warstwę pośredniczącą do przetworzenia i rozszerzenia danych, które były już zbierane z aplikacji.

Klasyczny model vs. nasze podejście

Klasyczny model:

• angażuje zespół IT i zwiększa koszty implementacji,
• wymaga zmian w kodzie aplikacji,
• oznacza testy i nowy release,
• zależy od aktualizacji aplikacji przez użytkowników,
• utrudnia szybkie reagowanie na potrzeby biznesu.

Nasze podejście:

• wykorzystuje istniejącą architekturę server-side,
• nie wymaga zmian w kodzie aplikacji,
• pozwala wdrażać logikę po stronie GTM,
• uruchamia zmiany bez czekania na aktualizację aplikacji,
• daje większą elastyczność i krótszy time-to-market.

To podejście okazało się szczególnie wartościowe także dlatego, że w trakcie projektu pojawiła się potrzeba zmiany listy marek objętych dodatkową logiką. W klasycznym modelu oznaczałoby to kolejny cykl developmentu i następny release aplikacji. W naszym modelu mogliśmy zareagować znacznie szybciej.

Efekt: szybsze wdrożenia, większa elastyczność, mniej zależności od IT

Najważniejsza zmiana polegała na tym, że Klient zyskał możliwość uruchamiania nowych konwersji zakupowych w aplikacji bez każdorazowego angażowania developerów i bez wydawania nowej wersji aplikacji.

Biznesowo przełożyło się to na:

• krótszy czas wdrażania zmian analitycznych,
• większą elastyczność przy działaniach promocyjnych i partnerskich,
• mniejsze uzależnienie marketingu i analityki od backlogu IT,
• możliwość szybszego uruchamiania pomiaru pod konkretne potrzeby kampanijne.

W środowisku retailowym, gdzie okna decyzyjne są krótkie, a działania promocyjne wymagają szybkiej reakcji, to realna przewaga operacyjna. Dzięki server-side GTM klient nie musiał wybierać między jakością danych a tempem działania.

Big Picture: więcej niż jednorazowe wdrożenie

Ten case nie był jednorazowym obejściem problemu. Potwierdził wartość wcześniej wdrożonej architektury ssGTM – zarówno po stronie webu, jak i aplikacji mobilnej.

I właśnie to jest najważniejszy wniosek z całego projektu: dobrze zaprojektowana architektura analityczna nie tylko zbiera dane. Daje biznesowi większą kontrolę, skraca czas reakcji i pozwala szybciej przekładać potrzeby marketingowe na konkretne działania.

The post Case Study – Gdy analityka musi nadążać za biznesem first appeared on Conversion.

Czego dowiesz się z tego wywiadu:

Czym jest Marketing Mix Modeling (MMM) i czy istnieje wzór na biznes?

Proces modelowania i znaczenie jakości danych

Współpraca z biznesem i ewolucja w stronę in-house

Zastosowanie MMM: Performance a budowanie marki

Kiedy firma powinna pomyśleć o wdrożeniu MMM?

Podsumowanie: Główne wnioski z rozmowy

Czym jest Marketing Mix Modeling (MMM) i czy istnieje wzór na biznes?

Wprowadzenie do MMM i optymalizacji budżetów

Mariusz Michalczuk: Cześć, witam Cię w kolejnym odcinku podcastu 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 Karol Dulęba. Cześć Karol.

Karol Dulęba: Cześć.

Mariusz Michalczuk: Karol zajmuje się modelowaniem marketingu Mix. Mógłbyś opowiedzieć, jak to wygląda? Może trochę więcej o Twoim doświadczeniu, jak doszedłeś do tego momentu, w którym jesteś? Mnie najbardziej będzie interesowało, jak twoja praca wygląda na co dzień.

Karol Dulęba: Myślę, że wiele osób już dzisiaj zna rozwinięcie tego skrótu MMM czy to, czym zajmuje się modelowanie marketing mixu. Finalnie chodzi o to, żeby znaleźć wskazówkę, w jaki sposób alokować budżety marketingowe na przeróżne media, na przeróżne aktywności, żeby zrealizować jakiś cel jak najlepiej. Zazwyczaj tym celem jest wzrost sprzedaży albo wzrost marży.

Żeby zakończyć to klamrą, do tego używamy danych, a te dane są procesowane różnymi algorytmami statystycznymi, ekonometrycznymi, tak, żeby dostać rekomendację, którą marketer może wykorzystać w swojej codziennej pracy.

Czy da się stworzyć matematyczny wzór na biznes?

Mariusz Michalczuk: Czy można to określić tak, że to jest taki wzór na biznes? Mam wynikową, niech to będzie przychód lub marża, i mam zmienne, które to objaśniają. Tu będziemy wykorzystywali zmienne głównie związane z marketingiem czy jeszcze jakieś inne wchodzą w grę? Może opowiesz o procesie, jak dochodzisz do tego wzoru, i czy to w ogóle dobra analogia.

Karol Dulęba: Gdyby udało się zbudować taki wzór, to skończyłaby nam się historia i wszystko byłoby bardzo łatwe. Jeżeli mamy dokładny przepis, po prostu podstawialibyśmy odpowiednie wartości i dostalibyśmy to, co chcemy. To jest raczej poszukiwanie czegoś, co mogłoby być wzorem, który nam bardzo przybliży ten świat, w którym biznes operuje. Nie spotkałem jeszcze firmy, która byłaby w stanie funkcjonować tylko na podstawie takiej jednej analizy.

To jest raczej punkt, do którego wszyscy zaangażowani w MMM starają się dotrzeć. Musimy wiedzieć, że biznes jest dużo bardziej skomplikowany niż jedna prosta formuła matematyczna. Wszystkie ograniczenia i przeróżne informacje, które powinniśmy wziąć do takiego modelu powodują, że jest to trochę utopijne myślenie. Natomiast jest to coś, co ma pewną wartość, którą świadomy marketingowiec jest w stanie wykorzystać, żeby jego wyniki odzwierciedlały wzrost wartości wygenerowany dla organizacji.

Do tego MMM jest przygotowany. Aby zbudować takie modele, kluczową rzeczą jest informacja jak najwyższej jakości, czyli dane. Na tych danych budujemy modele, które w porozumieniu albo w ostrym sporze z innymi metrykami, przybliżają marketingowca do odpowiedzi, gdzie powinien alokować budżet, żeby było lepiej.

Mariusz Michalczuk: Trochę to tak mi się kojarzy. Zawsze powtarzam, że analityka to nie jest matematyka, tam nie ma aksjomatów, że 2 plus 2 równa się 4, tylko tam są hipotezy. Pewnie tak samo jest z tym wzorem. On coś podpowiada, ale to nie jest aksjomat „if this then that”. Jeżeli widzimy coś, stawiamy hipotezę, dlaczego tak może wyglądać.

Karol Dulęba: Dokładnie tak. Nawet jeżeli wyobrazimy sobie, że taki teoretyczny wzór istnieje, to nie jest on stały w czasie. Nie jest też stały w ramach warunków operowania biznesu, dlatego tym trudniejsze jest dotarcie do niego.

Proces modelowania i znaczenie jakości danych

Zmienne kontrolowane i czynniki zewnętrzne

Karol Dulęba: Sposób modelowania nazywam procesem, a nie projektem. Projekt zakłada koniec i to, że świat już odkryliśmy. A tu nie mamy tych aksjomatów. To nie jest tak, że jeżeli zrobiliśmy jedną dobrą kampanię i ona ma ROI wynoszące 2, to świat się skończył i ta kampania będzie miała to ROI zawsze. Naiwnością jest sądzić, że tak będzie. Myśląc o tym, jak do modelowania najlepiej podejść, trzeba patrzeć w horyzoncie czasowym.

Mariusz Michalczuk: Pierwszy krok to rozmowa z właścicielami biznesowymi, żebyś zrozumiał zależności w biznesie i skąd się bierze na końcu ten przychód. Drugi krok to sprawdzenie, jakie dane mamy. Często wykorzystujemy dane związane z online’em, ale czy mógłbyś podać przykłady danych niekontrolowanych, które wykorzystujesz w modelowaniu?

Karol Dulęba: To mogą być przeróżne dane. To, jak generuje się popyt w danym momencie, może wcale nie zależeć od czynników, na które mamy wpływ. Prosty przykład: rośnie sprzedaż importowanych samochodów, więc rośnie popyt na ubezpieczenia pojazdów, które są nowe i nie miały wcześniejszego produktu. Nieuwzględnienie zmiennej, która mówi o rosnącym imporcie przy analizie sprzedaży nowych ubezpieczeń, może spowodować pominięcie ważnego trendu.

Inny przykład to konkurencja. W branży FMCG możemy bardzo dobrze śledzić rywali, mając dostęp do podobnych danych z nowoczesnego handlu. Widzimy, czy rośnie im dystrybucja i czy wypierają nas z półki, co oznacza, że jesteśmy wybierani rzadziej. Nieuwzględnienie tego może nas prowadzić do fałszywego wniosku, że coś z naszą kampanią jest nie tak. Kompletność opisu na początku to naprawdę kluczowy element całego procesu.

Mariusz Michalczuk: Miałem epizod w swoim życiu zawodowym jako ekonometryk w Domu Mediowym w 2009 roku. Online był wtedy ciekawostką, modelowałem głównie na podstawie danych telewizyjnych z Nielsena. Jak to jest dzisiaj z tą jakością danych?

Karol Dulęba: Jakość danych sukcesywnie się poprawia. Proces zbierania danych jest wyczyszczony, zautomatyzowany. Z kolei dane poboczne, jak monitoring wzmianek w mediach czy konsumpcja outdooru, są coraz lepsze, ale nie tak dokładne jak dane sprzedażowe klienta. Mimo to, praca nad jakością danych daje świetne efekty. Najlepiej poprawić je z horyzontem kilkuletnim wstecz. Zasada „garbage in, garbage out” nadal obowiązuje. Przy słabych danych możemy otrzymać fałszywy sygnał i podjąć błędne decyzje biznesowe.

Weryfikacja anomalii i sanity check

Mariusz Michalczuk: Jakie są metody sprawdzania tej jakości danych?

Karol Dulęba: Przede wszystkim analityczne sprawdzenie – poszukiwanie ekstremalnych wartości, które mogą się pojawiać. Druga strona to rozmowa z osobami, które pracują przy tych danych. Finalnie te liczby mają zwymiarować wysiłek włożony w marketing. Nazywamy to „sanity check”. Patrzymy, czy to, co widzimy, ma sens. Kiedy widzimy miesiąc z obserwacją milion razy większą od innych, jest to podejrzane. Sprawdzamy też silne trendy czy piki sezonowe i weryfikujemy ich związek z rzeczywistymi działaniami.

Odstająca wartość nie musi oznaczać błędu. Może ktoś zapomniał wyłączyć kampanię albo nagle zablokowała się podpięta pod reklamę karta, przez co wydatki spadły do zera. Takie sytuacje zdarzają się regularnie. Model MMM jest wrażliwy na to, że możemy spotkać się z odczytem, którego nie potrafimy zinterpretować. Jeśli wartość wydaje się odległa od oczekiwań, najprawdopodobniej problem leży w danych i musimy wrócić kilka kroków wstecz.

\

Współpraca z biznesem i ewolucja w stronę in-house

Demokratyzacja narzędzi i praca z zespołami klientów

Mariusz Michalczuk: Załóżmy, że jesteśmy pewni jakości danych i następuje modelowanie. Chciałbym usłyszeć, jak od strony biznesowej pracujesz z klientami nad gotowym MMM?

Karol Dulęba: Pracuję w różny sposób. Dawniej poszukiwano jednego, najlepszego modelu, skupiając się na idealnych zmiennych i funkcjach. Dzisiaj, dzięki tańszej mocy obliczeniowej, modelujemy ogromne liczby scenariuszy. Z nich wybierane są te o największej wartości, a informacje są łączone. Modelowanie musi być niezależne od preferencji analityka. Oczywiście jest tu element sztuki, ale nie można przesadzić – musi on wynikać ze zrozumienia danych i szybkiego reagowania na nieścisłości wspólnie z klientem.

Ostatnio staram się przekonywać klientów do pracy in-house. Tworzymy model całkowicie po ich stronie. Wiedza, ryzyka i benefity zostają w organizacji. Zespół może szukać odpowiedzi w każdej chwili, budując kluczową kompetencję. To rewolucja w MMM: odejście od modeli robionych przez agencje jako snapshot raz na rok, do sytuacji, w której korzystamy z gotowych, często darmowych lub tanich narzędzi.

Cała sztuka polega teraz na weryfikacji, czy to, co wychodzi na końcu, ma sens i wymaga korekt. Dziś firmy mogą mieć pełną wiedzę po swojej stronie, bez czekania tygodniami na odpowiedzi. Działam jako opiekun zespołów, które samodzielnie dostarczają całość.

Mariusz Michalczuk: Jesteś sparing partnerem dla zespołu analitycznego, który jest bliżej biznesu. Gdy pojawia się problem, ci analitycy mogą po prostu zapytać osobę biurko obok i szybciej uzyskać odpowiedź.

Karol Dulęba: Dokładnie. To proces ewolucji. Oczywiście obsługuję też klientów od A do Z, jeśli nie chcą budować wewnętrznych kompetencji. Jednak w nowych projektach badam, czy nie woleliby mieć projektu po swojej stronie i czerpać z niego niezależnie od wsparcia z zewnątrz. To zupełnie zmienia efektywność. Kiedyś spotkania podsumowujące odbywały się raz w roku i często urywały się w połowie z braku czasu. Dziś regularne, miesięczne rozmowy o wynikach, stabilności danych i testach rynkowych przynoszą dużo lepsze rezultaty.

Odchodzenie od wyłącznie last-clickowego podejścia

Mariusz Michalczuk: Przejdźmy do e-commerce. Panuje tam kult performance’u, oczekujemy zwrotu tu i teraz. Ostatnie lata pokazały, że performance drożeje, a popyt bywa niestabilny. Widzę tendencję e-commerce’ów do inwestowania w wizerunek i markę, by wpuścić ruch na górę lejka i później go monetyzować. Jak modele pokazują efekty reklam, które nie przynoszą konwersji tuż przed zakupem?

Karol Dulęba: Podejście MMM wzięło się właśnie z faktu, że mamy bardzo dużo kontaktów z reklamą, których nie jesteśmy w stanie zmierzyć prostą atrybucją i przypisać do użytkownika. Główną rolą MMM stała się ewaluacja kanałów na początku ścieżki zakupowej. Historycznie modele last click przypisywały całą zasługę kampaniom searchowym, a pomijały wpływ telewizji czy nieklikalnego displaya. Z góry zakładano, że ich efekt to zero.

MMM pozwala wyjść z zakleszczenia w kanałach końca lejka i zrozumieć rolę kanałów otwierających. Fałszywy jest podział, że kampanie są albo sprzedażowe, albo brandowe. Jeżeli kampania wizerunkowa nie buduje kiedyś sprzedaży, to znaczy, że nie zbudowała wizerunku. W e-commerce firmy często zjadają własny ogon w performance – patrzą na niezłe ROAS-y, ale ciągle płacą wysoką cenę za pozyskiwanie tych samych klientów i nie rosną.

Mariusz Michalczuk: Co w takim razie należy zrobić, zanim uruchomimy szerokie kampanie wizerunkowe?

Karol Dulęba: MMM to trzeci krok w kolejności. Pierwszym jest upewnienie się, że odrobiliśmy lekcję z lojalizacji. Musimy dbać o bazę klientów, żeby ci użytkownicy wracali sami z siebie, zamiast klikać po raz kolejny w drogie frazy generyczne. Jeżeli zainwestujemy w szeroki zasięg, a nasza retencja leży, szybko przepalimy budżet. Zdobędziemy uwagę na chwilę, ktoś kupi jeden produkt i nigdy nie wróci. Jeśli jednak mamy zbudowane mocne filary lojalności, szansa, że klienci zarekomendują nas znajomym (word of mouth) znacznie rośnie.

To jest moment, w którym możemy bezpiecznie skalować działania i przechodzić do kampanii otwierających, często opartych na wideo i opowiadających historię marki. Jeżeli zrobimy to dobrze, MMM pomoże wyliczyć inkrementalną wartość tej kampanii w dłuższym horyzoncie czasowym.

Kiedy firma powinna pomyśleć o wdrożeniu MMM?

Złożoność miksu i długość ścieżki zakupowej

Mariusz Michalczuk: Jakie są warunki wejścia w MMM? Co determinuje, że firma w ogóle powinna zacząć myśleć o stworzeniu modelu? Czy chodzi o przychody, czy wydatki marketingowe?

Karol Dulęba: Świat się zmienia. Narzędzia do MMM są dzisiaj tanie i dostępne. Głównym wyznacznikiem jest złożoność marketingu. Jeżeli jesteś nawet dużym graczem, ale masz tylko dwa kanały – generyczne i brandowe w wyszukiwarce oraz na Facebooku – to właściwie wszystko widzisz gołym okiem i MMM niewiele Ci da. Sytuacja komplikuje się, kiedy wydajesz solidne budżety na kilkadziesiąt różnych kampanii w wielu mediach, które się zazębiają, i tracisz pewność, co generuje wynik.

Mariusz Michalczuk: Czy długość procesu zakupowego ma tu znaczenie? Wydaje mi się, że operator turystyczny będzie miał trudniej złapać ten efekt niż internetowe delikatesy spożywcze.

Karol Dulęba: Przy dłuższych ścieżkach i wielu kontaktach rzeczywiście trudniej to wyłapać, co sprawia, że MMM jest bardzo przydatny. Ale w biznesach o krótkiej ścieżce model też ma sens, jeśli prowadzimy działania wizerunkowe w telewizji połączone z online’em. Model pomoże sprawdzić, czy klient wraca, czy tylko eksperymentuje. Krótko mówiąc: jeśli nie masz problemu z zaciemnionym obrazem analityki, to nie potrzebujesz MMM. Jeśli masz rozbudowany budżet i gąszcz sprzecznych danych z różnych platform, to jest to odpowiedni moment.

Mariusz Michalczuk: O co firma powinna zadbać tu i teraz, jeśli dojrzeje do decyzji o wdrożeniu MMM?

Karol Dulęba: Najważniejszym zasobem są dane. Jeśli firma o nie zadba, będzie miała doskonały start. Wybór partnera czy narzędzia to sprawa drugorzędna, bo bez danych nikt sobie nie poradzi. Konieczny jest wystarczający horyzont czasowy – przy danych dziennych to minimum półtora roku dobrej jakości informacji. Jeśli bazujemy na danych tygodniowych, np. w branży FMCG, potrzebujemy minimum trzech lat historii, by zbudować sensowne modele.

Mariusz Michalczuk: Gdzie można Cię znaleźć, gdyby ktoś chciał skorzystać z Twojej pomocy w tym zakresie?

Karol Dulęba: Można mnie znaleźć na LinkedInie. Mam introwertyczną naturę i skupiam się głównie na pracy, która jest często obwarowana umowami NDA, dlatego moje dzisiejsze wypowiedzi były dość ogólne. Lubię swoją niezależność, doradzam klientom obiektywnie, a czasem nawet odradzam wejście w drogie kanały, jeśli nie ma to sensu.

Mariusz তৎকালীন: Te procesy są naprawdę cenne, bo dają świetny pogląd na to, jak unikać błędów. Dzięki wielkie za twoją obecność u nas w studiu.

Karol Dulęba: Dzięki bardzo.

Podsumowanie: Główne wnioski z rozmowy

Kluczowe lekcje o MMM dla marketerów i e-commerce

Rozmowa z Karolem Dulębą uświadamia, że Marketing Mix Modeling przestał być niedostępnym, drogim rozwiązaniem zarezerwowanym dla największych korporacji. Demokratyzacja narzędzi sprawiła, że proces ten może być realizowany in-house, stając się stałym elementem oceny efektywności marketingu. Umożliwia to bieżące testowanie hipotez, szybką reakcję na rynkowe zmiany oraz dogłębną analizę jakości posiadanych danych, które są absolutnym fundamentem każdego modelu.

Dla branży e-commerce, która często zderza się z sufitem drogich kampanii performance’owych, MMM oferuje cenne spojrzenie na cały lejek sprzedażowy. Pozwala udowodnić i wyliczyć wartość inwestycji w działania wizerunkowe, pokazując, że długofalowe budowanie marki to konieczność. Zanim jednak zainwestujemy w zasięgi, niezbędne jest zadbanie o programy lojalnościowe i retencję, aby nowo pozyskany ruch faktycznie przekładał się na powtarzalny zysk, a nie jednorazowe, drogie konwersje.

The post Marketing Mix Modeling w e-commerce i nie tylko – Karol Dulęba – Date with Data Talks first appeared on Conversion.

Czego dowiesz się z tego wywiadu:

Ewolucja technologiczna: od korporacji do zwinnych środowisk

Wyzwania logistyczne w e-commerce a rozwój marketingu

Dlaczego projekty technologiczne upadają i czym jest efekt „kalafiora”

Zastosowanie agentów AI w zwinnym rozwoju produktu

Podsumowanie: Główne wnioski z rozmowy

Ewolucja technologiczna: od korporacji do zwinnych środowisk

Początki kariery z twardą technologią i pierwsze kroki w e-commerce

Mariusz Michalczuk: Cześć, witam Cię w kolejnym odcinku podcastu z serii Date with Data Talks, czyli podcastu od praktyków danych do praktyków wykorzystania danych. Dzisiaj moim gościem jest Daniel Kierdal. Dzisiaj będziemy więcej mówili o stronie danych internetowych i technologii. Masz ogromne doświadczenie we wdrażaniu narzędzi. Pracowałeś w dużych firmach, a obecnie rozwijasz swój startup. Opowiedz o swoim doświadczeniu i o tym, jak technologia zmieniała się na przestrzeni lat, zwłaszcza w ujęciu biznesowym.

Daniel Kierdal: Cześć. Zajmowałem się technologią od początku kariery. Na starcie to była twarda technologia. Zaczynałem w niewielkiej firmie Optimus, a potem trafiłem do IBM, gdzie zajmowałem się hardwarem, serwerami napędzającymi centra danych. Wtedy to były jeszcze silosowe, potężne systemy skalowane pionowo. Następnie poszedłem w kierunku oprogramowania, pozostając w warstwie niskopoziomowej technologii. Z IBM przeszedłem do Adobe. To był moment, w którym uznałem, że odchodzę od czystej technologii na rzecz marketingu i biznesu. Zmiana i rewolucja w sposobie zbierania i wykorzystywania danych online były niezwykle odkrywcze. Potem trafiłem do SAP, do działu martechowego, a ostatecznie poszedłem na swoje. Odpalam już trzeci startup i wszystkie w jakiś sposób krążą wokół danych, ponieważ to one są prawdziwym paliwem.

Mariusz Michalczuk: Nasze ścieżki po raz pierwszy przecięły się właśnie w Adobe, przy rozwiązaniu Adobe Analytics, które było jednym z pierwszych enterprise’owych narzędzi do analizy danych. Powiedz, jak zmieniało się samo podejście do wdrożeń na przestrzeni tych lat? Jak to wyglądało kiedyś, gdy dane trzymało się na serwerach, a nie w chmurze?

Daniel Kierdal: Rewolucja była kosmiczna. Gdy zajmowałem się serwerami z DB2, były to czasy projektów wyłącznie dla firm enterprise, bo tylko one inwestowały w taki sprzęt. Hurtownie danych budowano wtedy przez 2-3 lata do pierwszego uruchomienia. Planowano cały model danych, źródła, transformacje – wszystko metodyką waterfall od A do Z. Dopiero po trzech latach pojawiał się pierwszy raport. W dzisiejszych czasach to nieakceptowalne, nie tylko ze względu na czas. Świat zmienia się na tyle szybko, że po pół roku zaplanowane dane są już często niepotrzebne albo stanowią tylko ułamek tego, czego biznes naprawdę wymaga do podejmowania decyzji.

Przejście do zwinnego zarządzania projektami

Mariusz Michalczuk: Zakładam, że firmy decydujące się na wdrożenie musiały być niesamowicie cierpliwe i gotowe na długie oczekiwanie. Dziś, szczególnie w świecie startupów, oczekuje się namacalnych efektów już po pierwszych iteracjach.

Daniel Kierdal: Zgadza się. Zmieniło się to na iterowanie i zwinne metodyki wytwarzania. Po drodze wiele projektów waterfallowych upadło, ponieważ świat zmieniał się za szybko. Wymagały ciągłych zmian i modyfikacji, na które brakowało czasu. Istnieją spektakularne przykłady na rynku, gdzie duży detalista po kilku latach i wyrzuceniu w błoto pół miliarda euro, zrezygnował z wdrożenia systemu. Zmieniło się też pokolenie. Nawet w korporacjach ludzie nie chcą już czekać. Wszyscy oczekują efektów „tu i teraz”. Mamy kawałek kodu, testujemy go, sprawdzamy, co możemy wyciągnąć, a następnie dokładamy kolejne źródło danych i budujemy kolejny krok. To jedyne słuszne podejście.

Wyzwania logistyczne w e-commerce a rozwój marketingu

Budowa systemu OMS na styku e-commerce i magazynu

Mariusz Michalczuk: Bardzo ciekawe jest to połączenie, w którym szybkie pochłanianie informacji przez użytkowników wpływa bezpośrednio na funkcjonowanie biznesu. Przejdźmy do Twojej drogi. Pracowałeś w ogromnych organizacjach, a nagle wpadłeś na pomysł zbudowania systemu AMS i wszedłeś w świat zwinnych startupów. Skąd ten pomysł? Wyjście ze strefy komfortu korporacji do startupu to duży krok.

Daniel Kierdal: To była inna strefa komfortu, a właściwie jej brak. Często mówi się o genialnych pomysłach, które rodzą się w głowie za jednym zamachem, ale u mnie zadziałał przypadek i obserwacja. Dojrzewałem do pójścia na swoje. Rozmawiałem z wieloletnim kolegą o stworzeniu czegoś własnego i nagle pojawił się znajomy klient, który poprosił o zintegrowanie systemu WMS z platformą e-commerce. Wcześniej zajmowałem się digital marketingiem i widziałem, jak ogromnym problemem dla biznesów online jest proces logistyczny.

Sprzedaż online to składanie obietnicy. Sklep robi reklamę, opisuje historię produktu, pokazuje piękne zdjęcia i wciąga klientów do lejka. Ale moment konwersji to czas, gdy ktoś mówi „sprawdzam”. Fulfillment, czyli zrealizowanie zamówienia, to spełnienie tej obietnicy. To absolutnie kluczowe, bo od pierwszego doświadczenia zaczynasz budować lojalność. W online zwrot z inwestycji w pozyskanie klienta pojawia się najczęściej dopiero przy jego trzecim zamówieniu.

Mariusz Michalczuk: Zgadzam się. Koszty mediów i pozyskania klienta rosną. Coraz częściej trzeba dopłacić do pierwszej transakcji, by później zacząć na kliencie zarabiać.

Daniel Kierdal: Średnio zaczynamy zarabiać dopiero przy około 2.5 koszyka. Jeśli kończymy relację na pierwszym zakupie, dopłacamy do biznesu. Firmy inwestowały ogromne środki w narzędzia marketingowe wspierające pozyskiwanie klienta, ale technologia do fulfillmentu była sto lat z tyłu. E-commerce rósł, a stare systemy zarządzania magazynem (WMS), projektowane dekady temu do obsługi palet, nie dawały rady z wysyłką pojedynczych skarpetek czy smartfonów, z doborem kuriera, kodami rabatowymi czy formularzami zwrotu.

Rozwiązywanie powtarzalnych problemów branży

Mariusz Michalczuk: Problemem był fakt, że logistyka blokowała działania biznesowe i marketingowe? Do kogo kierowałeś swoje rozwiązanie – bardziej do logistyki, czy do marketingu?

Daniel Kierdal: Główne rozwiązanie adresowaliśmy do logistyki, a dokładnie do firm 3PL. To było świetne podejście, bo zadowalało obie strony. Operatorowi logistycznemu dawaliśmy spójny proces i niższe koszty obsługi błędów. Z kolei operator mógł pójść do swoich klientów i zaoferować im natychmiastowe podłączenie nowych kanałów sprzedaży. System łączył te światy, godząc ludzi, którzy wcześniej stali po dwóch stronach barykady.

Dlaczego projekty technologiczne upadają i czym jest efekt „kalafiora”

Znaczenie spójnej architektury i umiejętności mówienia „nie”

Mariusz Michalczuk: Wspominałeś o gigantycznych projektach, które po prostu upadają. Czy można wskazać punkt wspólny, przez który projekty technologiczne tak często ponoszą porażkę?

Daniel Kierdal: Bardzo często umierają dlatego, że firmy nie słuchają klientów w sposób usystematyzowany. Zdarza się też, że roadmapą rządzi jeden, największy klient. Jeśli dostosujesz cały produkt do jednego dużego gracza, to przestanie on pasować do reszty rynku, a ty zamiast tworzyć skalowalny produkt, staniesz się wykonawcą jednostkowego projektu. Drugim problemem jest uleganie tym, którzy najgłośniej krzyczą, z pominięciem dbałości o architekturę systemu.

Miałem klienta, który przyznał się, że jego wielki system powstał bez zarządzania architekturą 20 lat temu. Budowali tzw. monolit. Z biegiem lat dorabiali kolejne funkcje. Taki system przyjmuje „architekturę kalafiora”. Chcesz zmienić jeden mały komponent w środku, a okazuje się, że musisz rozgrzebać wszystko. Odmawiałem im wdrażania kolejnych nakładek, jeśli wymagało to budowania obejść. Tłumaczyłem, że za 10 lat obudzą się w tym samym punkcie. Spojrzenie długoterminowe i budowa fundamentów są kluczowe.

Mariusz Michalczuk: Umiejętność spojrzenia kilka kroków do przodu i odmawiania funkcji, które zaburzą architekturę, brzmi jak absolutnie krytyczna kompetencja w IT.

Daniel Kierdal: To połączenie twardego doświadczenia i umiejętności miękkich. Wymaga zrozumienia technologii oraz empatii, by wejść w buty klienta i wyobrazić sobie, z jakimi problemami zderzy się za rok czy dwa. Sam tego obecnie uczę innych.

Zastosowanie agentów AI w zwinnym rozwoju produktu

Problem taniego kodu i pułapki w szybkim projektowaniu

Mariusz Michalczuk: Dotknijmy tematu AI. Opowiadałeś mi o wdrożeniach i doradzaniu przy sztucznej inteligencji. Jak aktualnie z nią pracujesz? Świat idzie w stronę automatyzacji, ale widzę, że ty podchodzisz do tego niesamowicie praktycznie.

Daniel Kierdal: Teraz sztuczną inteligencją zajmują się prawie wszyscy. Podczas przeglądania projektów widzę, że hasło „AI” jest na każdym slajdzie. Uważam wręcz, że wstawianie AI na siłę staje się powoli minusem w oczach inwestorów. Narzędzie ma rozwiązywać konkretny problem procesu, a to, że wspiera je sztuczna inteligencja, to tylko narzędzie do celu.

Wraz z zespołem stworzyliśmy platformę AgenticForce. Nasz founder słusznie zauważył, że tworzenie oprogramowania stało się tak tanie, że zniknął naturalny „kaganiec” finansowy, który powstrzymywał nas przed produkcją zbędnych funkcjonalności. W firmach pojawiło się zjawisko „CEO Driven Development” – szef w weekend koduje prowizoryczną funkcję przy wsparciu narzędzi generatywnych i nakazuje zespołowi wdrożenie jej na produkcję. Ponieważ kod jest tani, funkcje tworzy się masowo. Problem w tym, że każda nowa funkcja wymaga utrzymania, integracji i zasobów, a system powoli znów zamienia się we wspomnianego „kalafiora”.

Wingman jako wsparcie Product Managera

Mariusz Michalczuk: Umiejętność mówienia „nie” przy rozwoju oprogramowania staje się więc ważniejsza niż mówienie „tak”.

Daniel Kierdal: Dokładnie. Dzisiaj Product Manager otrzymuje informacje z dziesiątek źródeł: systemów zgłoszeń, formularzy, social mediów i czatów. Próba znalezienia priorytetów w tym szumie jest trudna. Dlatego zbudowaliśmy Jacka Wingmana – agenta AI, który staje się asystentem zarządzającego produktem. Analizuje ogromne zbiory nieustrukturyzowanych danych, układa wątki i priorytetyzuje zadania tak, by menedżer miał twarde argumenty, by odrzucić spontaniczne pomysły CEO na rzecz faktycznie rentownych zmian.

Co więcej, Wingman zamyka pętlę komunikacyjną. Jeśli system na podstawie zgłoszeń 1200 użytkowników stworzy i dowiezie funkcjonalność, potrafi automatycznie wrócić do tych osób z informacją zwrotną. Pokazujemy im, że ich głos ma znaczenie i realnie wpłynął na produkt. Platforma od początku jest zaprojektowana wokół sztucznej inteligencji, dzięki czemu agenci mogą się między sobą komunikować i uzupełniać swoje role – mamy agentów od produktu, marketingu, a nawet operacji, którzy współpracują na specjalnych kanałach.

Podsumowanie: Główne wnioski z rozmowy

Najważniejsze lekcje dla menedżerów i specjalistów e-commerce

Rozmowa z Danielem Kierdalem uwidacznia, jak bardzo przyspieszyły cykle tworzenia technologii internetowych. To, co kiedyś planowano w wieloletnich projektach wodospadowych (waterfall), dzisiaj weryfikuje się w szybkich, zwinnych iteracjach. Szczególnie wyraźnie widać to na styku e-commerce i logistyki, gdzie doskonały marketing często trafiał w barierę niewydolnych, przestarzałych systemów magazynowych, obniżając szansę na opłacalność biznesu i budowę bazy lojalnych klientów.

Dzisiejszy rozwój technologii oparty o sztuczną inteligencję i tanie metody wytwarzania oprogramowania niesie jednak nowe zagrożenia. W obliczu masowego przypływu innowacji i „vibekodowania”, kluczową kompetencją organizacji staje się asertywność oraz zarządzanie twardymi danymi. Implementacja nowych funkcji bez kontroli architektury prowadzi do długu technologicznego, niszcząc elastyczność systemu na lata.

Rozwiązaniem tych problemów są wyspecjalizowani asystenci cyfrowi i agenci AI. Dzięki analizie nieustrukturyzowanych informacji od klientów oraz łączeniu ich z danymi o zachowaniach użytkowników w produkcie, menedżerowie mogą podejmować decyzje w oparciu o konkrety. Rozmowa dobitnie pokazuje, że oswajanie nowinek technologicznych, przy zachowaniu zdroworozsądkowego filtra analitycznego, stanowi obecnie jedyną drogę do osiągnięcia stabilnej przewagi konkurencyjnej na rynku.

The post Jak wdrażać technologię w e-commerce – Daniel Kierdal – Date with Data Talks first appeared on Conversion.

Czego dowiesz się z tego wywiadu:

Rola architekta rozwiązań reklamowych w Google

Dlaczego fundamenty danych są kluczowe dla algorytmów

Wyzwania technologiczne i prawne przy bidowaniu do wartości

Data Governance i utrzymanie jakości danych

Przyszłość analityki w erze sztucznej inteligencji

Rola architekta rozwiązań reklamowych w Google

Współpraca z największymi reklamodawcami i wyzwania technologiczne

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 Karolina Wrzask. Cześć Karolina.

Karolina Wrzask: Cześć, dziękuję za zaproszenie.

Mariusz Michalczuk: Bardzo miło, że dołączyłaś. Chciałbym zacząć od tego, żebyś opowiedziała o swojej pracy. Pracujesz jako Advertising Solution Architect Google, bardzo skomplikowana nazwa. Powiedz mi, czym się zajmujesz, jakie problemy mają klienci, którzy do ciebie się zgłaszają i z jakimi firmami pracujesz.

Karolina Wrzask: Zgadza się, jestem architektem rozwiązań reklamowych. Gdybym miała przetłumaczyć na język polski to stanowisko, to jestem po prostu technicznym konsultantem, czyli zajmuję się doradztwem w zakresie wdrożeń narzędzi Google, ponieważ reprezentuję tego dostawcę. Pracuję z klientami w obszarze wdrożenia tych narzędzi, integracji, pozyskiwania danych i aktywacji danych. Tak najprościej bym to ujęła.

Mariusz Michalczuk: Czyli wszystko, co trzeba zrobić najpierw, żeby z tych danych korzystać. Z jakimi wyzwaniami zgłaszają się klienci? Robisz to z ramienia Google, do którego przychodzą pewnie największe firmy. Ciekawe, z jakimi wyzwaniami takie organizacje przychodzą.

Karolina Wrzask: Zacznę od kontekstu. Pracuję obecnie z największymi reklamodawcami w obszarze środkowo-wschodniej Europy, co sprawia, że moja perspektywa może być trochę wypaczona dużymi firmami i dużymi zespołami. Na szczęście współpracujemy też z firmami, które bardzo dynamicznie rosną, szybko pojawiają się na horyzoncie dużych reklamodawców, ale są jeszcze młodzi, dynamiczni i nieobciążeni historią, tym długiem technologicznym.

Mariusz Michalczuk: I pewnie przez to też bardziej zwinni, jak startupy.

Karolina Wrzask: Tak. Tam czasami są luki fundamentalne, które na szczęście daje się szybko zasypać. Pracuję z dużymi reklamodawcami, ale często to my wychodzimy z inicjatywą do nich. Środowisko techniczne i narzędzia zmieniają się bardzo szybko. Sam Google dostarcza coraz to nowe rozwiązania i musimy przyspieszyć adopcję, żeby umożliwić reklamodawcom pełne korzystanie z tych funkcjonalności.

Dlaczego fundamenty danych są kluczowe dla algorytmów

Adopcja nowych rozwiązań a jakość danych

Mariusz Michalczuk: Po to, żeby wydatki reklamowe były bardziej efektywne i docierały szybciej do właściwych użytkowników.

Karolina Wrzask: Podam Ci przykład adopcji kampanii typu Demand Gen. To obszar, którym się nie zajmuję, więc błagam, nie pytaj mnie o więcej, ale wiem, że żeby nasz zespół mógł skutecznie pracować z reklamodawcą, musimy z nim odrobić pracę w zakresie Data Strength, czyli fundamentów tagowania i integracji danych.

Mariusz Michalczuk: Żeby algorytmy mogły działać, trzeba zapewnić dobre dane. Jakiego rodzaju to są algorytmy i co dzięki nim się dzieje, żeby trafić do odpowiednich użytkowników?

Karolina Wrzask: Zdecydowanie. Dane, na których opiera się Demand Gen, to te fundamentalne: poprawna konwersja, jej atrybucja do źródła kampanii, ale też dane użytkowników. Mamy dane, które zaobserwujesz bezpośrednio – kliknięcie w reklamę, wejście na stronę, konwersja. Są takie konwersje czy zdarzenia, których nie możemy bezpośrednio połączyć z interakcją użytkownika z reklamą. Tam wchodzą rozwiązania łączące te interakcje na podstawie danych, które dostarcza użytkownik, jak adres e-mail czy numer telefonu.

Mamy też dane modelowane, gdzie nie mamy identyfikatora, ale posiadamy informacje o zdarzeniu oraz szereg metadanych zebranych tagami. Pozwalają one odtworzyć i zaraportować wizyty oraz konwersje użytkowników najbardziej trafnie, jak to możliwe na podstawie dostępnych sygnałów.

Wyzwania technologiczne i prawne przy bidowaniu do wartości

Bariery w przekazywaniu danych o marży i zyskach

Mariusz Michalczuk: W pracy z klientami często przekazujemy dane nie tylko z frontendu. To rzeczy bardziej wewnątrzfirmowe, np. marże na produktach. Rozumiem, że w waszym zakresie jest wsparcie tego, żeby wnieść kampanię na wyższy poziom, by bidować na podstawie wartości biznesowej.

Karolina Wrzask: Zastanawiam się, ile żargonu używać, muszę znaleźć złoty środek.

Mariusz Michalczuk: Trudno go znaleźć.

Karolina Wrzask: Niektórych rzeczy nie da się uniknąć. Jeśli mówimy o bidowaniu do wartości biznesowej, to dotknąłeś tematu, w którym adopcja mocno przyspieszyła. Rozmawialiśmy o bidowaniu do wartości lata temu, ale dopiero teraz to wszystko zaczyna się dziać. Zastanawiałam się nad tym i to efekt wielu czynników. Po pierwsze, pojawiło się dużo nowych formatów reklamowych wykorzystujących algorytmy bardziej niż precyzyjne ustawienia specjalistów. Już nie celujemy w konkretne słowo kluczowe, tylko w zestawy słów, intencje użytkownika i wartości biznesowe.

Reklamodawcy byli wcześniej sceptyczni, ufali swoim zdolnościom manualnym. Wraz z formatami pojawiły się jednak nowe sposoby ich walidacji: eksperymenty, testy inkrementalności, które udowodniły wartość kampanii i oszczędność pracy. Klienci zaczęli migrować i poświęcać uwagę fundamentom. Przez lata edukowaliśmy rynek, że jakość danych jest kluczowa. Teraz widzimy, że reklamodawcy to adoptują.

Mariusz Michalczuk: Rynek musi do wszystkiego dorosnąć, ale zmieniają się też okoliczności.

Karolina Wrzask: W zeszłym roku, pomijając wymogi zarządzania ciasteczkami, pojawił się Digital Market Act, który wpłynął na to, jak zbieramy i przetwarzamy dane. Popchnęło to falę wdrożeń Consent Mode. Świadomość klientów się zwiększa. Skoro mamy część ruchu, którego nie widzimy, musimy zasypać tę dziurę sygnałami do modelowania. Zwiększa się akceptacja na wykorzystanie danych modelowanych, co rodzi otwartość na tagowanie serwerowe. Chcemy lepszych danych biznesowych o marży czy wartości klienta, ale nikt nie chce ich udostępniać w samej przeglądarce.

\

Mariusz Michalczuk: Mamy wyzwanie w przekazywaniu danych o kosztach i marży, bo lepiej bidować na zysk niż na przychód. U Was jest trochę łatwiej, bo przychodzicie jako Google i rozmawiacie z właścicielami biznesowymi. Często mamy problem, żeby te dane uzyskać od controllingu. Jak to robicie?

Karolina Wrzask: To zależy. Branża e-commerce zaczęła bidować do wartości transakcji lata temu. Tam jest wysoki próg wejścia do wartości biznesowej, np. marży. Inne branże, np. finansowa czy tradingowa, czasem nie chcą ujawniać informacji lub przekazywać ich platformom partnerskim. Rozmowy bywają trudne. Wynika to z pozyskania danych – musimy ustalić technicznie, gdzie informacje są dostępne i czy są w czasie rzeczywistym. Druga bariera to dział prawny. Dyskusje potrafią trwać latami, żeby uzyskać zgodę na przetwarzanie.

Mariusz Michalczuk: Mieliśmy klientów, u których takie dyskusje trwały dosłownie cztery lata. Wrócili po tym czasie.

Karolina Wrzask: My jesteśmy aktywni i konsekwentni. Naciskamy na produkty, takie jak Enhanced Conversions, które bezpośrednio wpływają na wolumen konwersji. Mamy narzędzia zachęcające do testów i odpowiednie struktury, by rozmawiać na szczeblu C-level. Jeśli dotrzesz do odpowiednich stakeholderów, temat daje się rozwikłać. Zespół prawny musi zrozumieć mechanizmy, dlatego pomagają nam nasze zespoły prawne i handlowe zaopatrzone w odpowiednią dokumentację.

Mariusz Michalczuk: Wspomniałaś, że przekazywanie danych przez serwer musi dziać się w czasie rzeczywistym. Są branże, jak RTV, gdzie trudno policzyć ostateczną marżę natychmiast ze względu na zachęty od producentów. Są mechanizmy, by po czasie doładować tę wartość biznesową reklamy?

Karolina Wrzask: Przekażę bardzo ważną rzecz. Jeśli chcemy wysyłać dane do platformy reklamowej przez kontener serwerowy (sGTM), to powinno się to dziać w czasie rzeczywistym. Mamy tag w przeglądarce, trafia do serwera i tam dane uzupełniamy, zaciągając je z bazy (np. Firestore) lub z modelu. Klienci czasem błędnie używali Measurement Protocol do zasilania tagów z przeglądarki. Nie jest to oficjalnie wspierane, utrudnia debugowanie i psuje modelowanie.

Data Governance i utrzymanie jakości danych

Od zbierania wszystkiego do świadomego zarządzania informacją

Mariusz Michalczuk: Cokolwiek robimy z wewnętrznymi danymi, zapominamy o Measurement Protocol?

Karolina Wrzask: Trzeba zdawać sobie sprawę, że Measurement Protocol to narzędzie do wysyłania offline’owych zdarzeń do serwera Analyticsa. Nie służy do odpalania tagów przeznaczonych dla frontendu. Jego konstrukcja jest zbyt uboga. Mamy teraz narzędzie w otwartej becie, czyli Conversions with Multiple Data Sources. To hybryda dla Google Ads. Możesz mierzyć konwersję z przeglądarki, a po czasie uzupełnić i zaktualizować jej wartość z danych offline.

Mariusz Michalczuk: Takie uczenie ze wzmocnieniem?

Karolina Wrzask: Tak. Możesz dosłać też dodatkowe dane użytkowników. Architektura stała się złożona. Klienci przychodzą, bo potrzebują wsparcia w nawigowaniu po nowych betach i modyfikacji starych setupów. To jest właśnie moja rola.

Mariusz Michalczuk: Ty jesteś mentorem z ramienia Google, ale ciekawi mnie, kto jest po drugiej stronie u dużego klienta. Kto steruje przepływem pracy i operacjami technologicznymi? Opiekun martechu?

Karolina Wrzask: Zwykle jest. To zależy od wieku i dojrzałości organizacji. Reprezentując dostawcę rozwiązań reklamowych, współpracuję najczęściej z zespołami performance’owymi. Dawniej analityka operowała głównie w obrębie Google Analytics. Teraz z jednej strony architektura pozwala na zaawansowane modelowanie, co odejmuje pracę manualną, a z drugiej drzewo decyzyjne i integracje rozrosły się niesamowicie.

Mariusz Michalczuk: Wymusza to współpracę między działami: performance, IT, produkt.

Karolina Wrzask: Dokładnie. Zespoły performance włączają IT i działy analityczne (inżynieria danych). Wyłaniają wspólną delegację, która współpracuje ze mną w celu prawidłowego zasilenia platformy.

Mariusz Michalczuk: Performance bardzo zbliżył się do technologii.

Karolina Wrzask: Niesamowicie. Specjaliści performance zajmują się dziś tagowaniem, serwerami, Google Tag Gateway i integracją z IT. Kiedyś musieliśmy marketerów błagać o inwestycję w dane, a teraz sami inicjują te procesy wewnątrz organizacji. Narzędzia wręcz wymagają poprawnych danych wejściowych, aby skutecznie działać.

Mariusz Michalczuk: Mam refleksję, że analityka internetowa – to małe zbieranie danych – została zauważona przez „wielką analitykę” firmową (CRM, BI). Zrozumiano, że są to wzajemnie uzupełniające się ekosystemy, dające przewagę algorytmom sztucznej inteligencji, do których wszyscy mamy taki sam dostęp.

Karolina Wrzask: Zgadzam się. Rzeczy, o których latami mówiliśmy na konferencjach i ewangelizowaliśmy rynek, dzieją się właśnie dzisiaj.

Mariusz Michalczuk: Jak to wygląda w regionie CEE pod względem dojrzałości technologicznej? Mamy się w Polsce czego wstydzić w porównaniu do innych rynków?

Karolina Wrzask: Absolutnie nie. Mamy wspaniałych specjalistów wyznaczających standardy. Dojrzałość zależy od branży. Świetnie radzi sobie branża tradingowa, bo dane to ich podstawowy biznes. E-commerce z kolei szybko zaadoptował podstawowe rozwiązania lata temu, ale potem wpadł w stagnację skupiając się na raportowaniu. Inne branże nadrobiły braki, a teraz e-commerce musi zrobić kolejny przeskok technologiczny, by odzyskać przewagę konkurencyjną. Zatrudniają ekspertów i testują nowe rozwiązania, chociaż często hamuje ich bezwładność organizacyjna.

Mariusz Michalczuk: Słyszałem stwierdzenie, że e-commerce to dziś biznes bardziej technologiczny niż handlowy.

Karolina Wrzask: Chciałabym to tak widzieć, ale chyba jeszcze nie do końca. Moje obserwacje dotyczą konkretnego obszaru. Widzę jednak ogromny rozwój chociażby środowisk cloudowych wśród tych firm, więc zdecydowanie jest w tym stwierdzeniu sporo prawdy.

Mariusz Michalczuk: Chciałbym dopytać o jakość. Tych danych zbieramy mnóstwo, trzeba je jakoś utrzymać. Gdzie w tym wszystkim jest Data Governance?

Karolina Wrzask: Ciepło mi się na serduszku zrobiło, jak to powiedziałeś. W tym roku będę zawodowo pełnoletnia i pierwszy raz w ciągu ostatniego półrocza klienci dwukrotnie poprosili mnie o konsultację z zakresu Data Governance w marketingu. Zawsze o tym marzyliśmy jako analitycy. Miałam przypadek klienta, który miał w Analyticsie mnóstwo danych produkujących chaos. Nikt z tego nie korzystał. Zaangażowaliśmy liderów, IT, marketing i analityków. Proces trwał tygodniami, przygotowałam im odpowiednią dokumentację utrzymania jakości. Zaczynamy patrzeć na to odpowiedzialnie.

Mariusz Michalczuk: Marketerzy często mają podejście „zbierajmy wszystko, co się da”. Znalazłem twoją prezentację z Super Weeka z hasłem „We don’t need all your data”. Jak to obecnie wygląda w praktyce?

Karolina Wrzask: Teraz ciężko byłoby mi to obronić, bo przecież prosimy o zaszyfrowane dane użytkowników czy dane sesyjne do modelowania. Z jednej strony są uwarunkowania prawne – musimy wiedzieć, po co zbieramy konkretną daną, na co mamy zgodę. Z drugiej strony, posiadanie ogromnych baz w BigQuery kosztuje, chociaż tabele z GA4 można odpowiednio spłaszczać, by zoptymalizować procesy i ograniczyć rachunki. Kluczem jest wyznaczenie właściciela danych w organizacji (Data Ownera). To on decyduje, jakie dane są potrzebne, na jak długo i jak nimi zarządzać.

Mariusz Michalczuk: Słyszałem, że w jednej z firm zatrudniono Data Stewarda.

Karolina Wrzask: Data Steward to standardowa rola we frameworku Data Governance. Jeśli firma ma osobę decyzyjną odpowiedzialną za te zasoby, to już jest połowa sukcesu.

Przyszłość analityki w erze sztucznej inteligencji

Jak AI zmieni pracę analityków i marketerów

Mariusz Michalczuk: Na koniec muszę zapytać o sztuczną inteligencję. Z mojej perspektywy AI w 95% zastąpi człowieka w samej analizie, jeśli dane będą dobrze przygotowane. Natomiast dużo trudniej będzie zastąpić kogoś w samym procesie zbierania, wdrażania i rozmów w organizacji o potrzebach biznesowych. Czy ta myśl idzie w złym kierunku? Jak to widzicie w Google?

Karolina Wrzask: Wykorzystanie AI dynamicznie rośnie. Doszłam do wniosku, że jeśli za dwa lata moja obecna rola techniczna będzie nadal potrzebna w tym samym kształcie, to coś poszło nie tak. Ja wkraczam na wczesnym etapie adopcji rozwiązań (np. przy Google Tag Gateway), gdzie boty często halucynują lub mieszają pojęcia techniczne, i trzeba rozwikłać wątpliwości klienta. Tam, gdzie na razie nie ma wystarczającej dokumentacji, pomoc ekspercka zostaje. Jeśli technologia jest dojrzała, nie ma sensu tego robić manualnie.

Mariusz Michalczuk: Wiedza jest już dostępna, a asystenci AI skutecznie ją przekazują.

Karolina Wrzask: Tak. Korzystam z agentów z dostępem do wewnętrznej dokumentacji, co przyspiesza moją pracę niesamowicie. Narzędzia są wdrażane kilkoma kliknięciami z poziomu interfejsu. Automaty zrobią wiele rzeczy szybciej. Jednak wiedza domenowa wciąż będzie krytyczna – trzeba umieć napisać dobry prompt, sprawdzić odpowiedź i połączyć kropki. AI nas nie zastąpi, ale zmieni specyfikę naszej pracy. Pamiętajmy, że kiedyś praca juniorska polegała na przepisywaniu dokumentów na maszynie, dziś ta sama zasada dotyczy ręcznego wpisywania słów kluczowych czy wstawiania skryptów.

Mariusz Michalczuk: Nie bójmy się słowa dinozaur.

Karolina Wrzask: Jak zaczynałam, pisałam słowa kluczowe do kampanii ręcznie. Teraz technologia pędzi. Skłoniło mnie to do zajęcia się obszarem Data Governance. Jeśli boty skonfigurują kampanie i tagi, człowiek przyda się tam, gdzie potrzeba komunikacji z innymi ludźmi, budowania zaufania, rozwiązywania relacji i strategicznego myślenia. Będziesz potrzebował dziesięciu agentów AI, ale nadal potrzebujesz jednego człowieka, który ma nad tym pieczę.

Mariusz Michalczuk: Co byś poradziła osobom pracującym w digital marketingu i analityce, aby rozwijały swoje kompetencje?

Karolina Wrzask: Umiejętności miękkie są świetne, ale by zbudować relację i autorytet, musisz mieć kompetencje techniczne. Rozumienie technologii, inżynierii danych, funkcjonowania algorytmów na poziomie matematycznym jest bazą do wyciągania wniosków i kwestionowania wyników. Ważna jest też ostrożność względem informacji. Kiedyś dostałam z czata piękną instrukcję konfiguracji z polem, które nie istnieje w platformie reklamowej. Zostaje z nami ciekawość oraz umiejętność łączenia kropek.

Mariusz Michalczuk: To czyni ten świat bardzo interesującym.

Karolina Wrzask: Bardzo. Mówiło się, że wynalazki AGD dadzą ludziom więcej czasu na odpoczynek. Wyszło tak, że pierzemy częściej, pracujemy tyle samo, a nadwyżki inwestujemy w wychowanie, rozwój i powiększanie zamożności. Tak samo będzie ze sztuczną inteligencją. Zaoszczędzimy czas na klikaniu, a wymyślimy nowe wartościowe usługi i poszerzymy nasze pole manewru.

Mariusz Michalczuk: Cenna myśl na sam koniec. Życzę nam wszystkim refleksji i krytycznego myślenia. Dzięki wielkie, Karolina.

Karolina Wrzask: Wzajemnie. Dziękuję bardzo za rozmowę.

Podsumowanie: Główne wnioski z rozmowy

Najważniejsze lekcje dla analityków i marketerów

Rozmowa z Karoliną Wrzask uświadamia, w jakim tempie rozwija się technologiczne zaplecze nowoczesnego marketingu cyfrowego. Klienci, nawet najwięksi, mierzą się dziś z implementacją rozwiązań bazujących na zaawansowanym modelowaniu, do czego niezbędne są perfekcyjnie skonstruowane fundamenty. Dbanie o właściwą jakość przekazywanych sygnałów oraz atrybucji to obecnie warunek konieczny dla działania nowoczesnych systemów takich jak Google Ads.

Kluczowym wnioskiem jest również obserwowany renesans podejścia do Data Governance. Firmy coraz częściej zdają sobie sprawę, że samo zbieranie każdego możliwego punktu danych generuje chaos informacyjny oraz generuje koszty. Wyznaczenie odpowiedniego Data Ownera (oraz ról wspierających takich jak Data Steward) staje się naturalnym krokiem w procesie panowania nad danymi i wykorzystywania ich w sposób zgodny z prawem oraz oczekiwaniami biznesowymi.

Zwieńczeniem dyskusji było spojrzenie w przyszłość ukształtowaną przez sztuczną inteligencję. Wbrew pesymistycznym prognozom, automatyzacja takich procesów jak tagowanie czy wprowadzanie kampanii nie eliminuje potrzeby posiadania specjalistów. Odciąża ona jednak analityków z powtarzalnych zadań operacyjnych, wymagając w zamian mocnych umiejętności krytycznego myślenia, głębokiej weryfikacji otrzymywanych sugestii systemowych oraz wiedzy umożliwiającej budowanie przewag konkurencyjnych na znacznie wyższym szczeblu decyzyjnym.

The post Perfromance marketing nie może istnieć bez technologii – Karolina Wrzask – Date with Data Talks first appeared on Conversion.

Branża: Platforma medyczna
Klient: House-Med S.A. (Kraków, Polska)
Strona: www.upacjenta.pl

Punkt wyjścia

W dojrzałym marketingu dane nie mogą być „w przybliżeniu poprawne”. Muszą być wystarczająco precyzyjne, by dało się na nich oprzeć decyzje dotyczące budżetu, efektywności kanałów i wzrostu.

Właśnie z takim wyzwaniem zmierzył się upacjenta.pl – dynamicznie rozwijający się serwis z obszaru medycznego i e-commerce, działający w środowisku, w którym kluczowe znaczenie mają zarówno jakość pomiaru, jak i kontrola nad prywatnością danych.

Dotychczasowy model śledzenia opierał się na klasycznym podejściu client-side. W praktyce oznaczało to rosnącą podatność na blokowanie przez przeglądarki, adblocki i mechanizmy ochrony prywatności.

Efekt był prosty: część danych nie docierała do narzędzi analitycznych, a część traciła swoją wartość przez błędy atrybucji i niespójność sesji.

Dlatego celem projektu nie było wyłącznie wdrożenie nowej technologii, ale przede wszystkim przywrócenie wiarygodności danych i zbudowanie pomiaru gotowego na współczesne realia digitalu.

Wyzwania

Przed wdrożeniem zidentyfikowaliśmy kilka problemów, które bezpośrednio wpływały na jakość analityki i skuteczność działań marketingowych.

Znacząca część zdarzeń była blokowana po stronie przeglądarki, co ograniczało widoczność konwersji w GA4. Jednocześnie aż 22% sesji trafiało do kategorii (not set), co istotnie utrudniało ocenę, które kanały marketingowe realnie generują wartość.

Dodatkowym problemem było zrywanie sesji i zaburzone łączenie ścieżek użytkownika – m.in. na styku zgód CMP, architektury SPA oraz działania zewnętrznych narzędzi. W efekcie raportowanie nie zawsze odzwierciedlało rzeczywiste zachowanie użytkowników.

W środowisku medycznym równie ważny był aspekt compliance. Klient potrzebował większej kontroli nad tym, jakie dane opuszczają jego ekosystem i w jakiej formie trafiają do zewnętrznych platform.

Nasze podejście

Zaprojektowaliśmy i wdrożyliśmy architekturę server-side Google Tag Manager, która przejęła kluczowe elementy pomiaru, atrybucji i kontroli danych.

Zakres prac objął:

• migrację tagów Google Ads do kontenera serwerowego,
• uruchomienie modelu hybrydowego dla Meta i TikToka: pixel + Conversion API z pełną deduplikacją zdarzeń,
• przygotowanie infrastruktury pod przyszłą optymalizację kampanii w oparciu o marżę, a nie wyłącznie przychód.

To podejście pozwoliło nie tylko uszczelnić pomiar, ale też zbudować architekturę, która daje klientowi większą niezależność od ograniczeń przeglądarek i platform.

Projekt był realizowany w elastycznym modelu współpracy, dopasowanym do organizacji i potrzeb klienta. Część działań była realizowana po naszej stronie, a część po stronie upacjenta.pl.

To pokazuje, że potrafimy prowadzić wdrożenia zarówno kompleksowo, jak i w modelu partnerskim, ściśle współpracując z zespołem klienta.

Efekty

Analiza danych z okresu testowego pokazała wyraźną poprawę jakości pomiaru i atrybucji.

Odzyskane transakcje

W modelu server-side raportowanie transakcji było wyższe o od 1% do 14% dziennie względem wcześniejszego modelu client-side.

Naprawiona atrybucja

Udział ruchu Google / organic wzrósł z 46% do 61%, co pokazało, że wcześniejszy model nie odzwierciedlał w pełni rzeczywistego źródła wizyt.

Stabilniejsze sesje

Liczba raportowanych sesji spadła o 2–4%, co było pozytywnym sygnałem – oznaczało lepsze łączenie hitów w ramach jednej wizyty i eliminację sztucznych resetów sesji.

Czystszy model pomiarowy

Odsetek sesji bez zdarzenia session_start spadł do 0,2–0,5%, co potwierdziło poprawę w obszarze session stitching i spójności danych.

Co ten projekt zmienił biznesowo?

Największą wartością tego wdrożenia nie była sama zmiana technologii. Kluczowe było to, że upacjenta.pl odzyskało większą kontrolę, większą precyzję i większe zaufanie do danych.

Dzięki temu:

• raportowanie sprzedaży lepiej odzwierciedla rzeczywistość,
• atrybucja daje solidniejszą podstawę do decyzji mediowych,
• systemy reklamowe mogą uczyć się na pełniejszych danych konwersyjnych,
• klient ma większą kontrolę nad prywatnością i zakresem przekazywanych informacji,
• architektura analityczna jest gotowa na dalszy rozwój.

W praktyce oznacza to nie tylko lepszy pomiar „tu i teraz”, ale również gotowość do bardziej zaawansowanych scenariuszy optymalizacji i aktywacji danych.

Fundament pod kolejne etapy rozwoju

Wdrożenie server-side GTM stworzyło bazę pod dalsze inicjatywy z obszaru data-driven growth.

Ta architektura otwiera drogę do:

• optymalizacji kampanii w oparciu o marżę,
• personalizacji doświadczenia użytkownika w czasie rzeczywistym,
• budowy modeli predykcyjnych, takich jak pLTV.

To właśnie dlatego patrzymy na server-side tracking nie jak na pojedyncze wdrożenie techniczne, ale jak na element infrastruktury wzrostu.

Podsumowanie

Ten projekt pokazał, że problemy z jakością danych bardzo często nie wynikają z braku ruchu czy słabszych kampanii, ale z ograniczeń samego modelu pomiarowego.

W przypadku upacjenta.pl przejście na server-side GTM pozwoliło odzyskać część utraconych danych sprzedażowych, uporządkować atrybucję i zbudować znacznie bardziej odporną architekturę analityczną.

Bo kiedy dane stają się dokładniejsze, marketing może działać pewniej. A kiedy pomiar zaczyna nadążać za biznesem, łatwiej skalować to, co naprawdę działa.

The post uPacjenta.pl – Jak uPacjenta.pl odzyskało utracone dane sprzedażowe dzięki Server-side GTM? first appeared on Conversion.

Wprowadzenie do DataOps
Praca na surowych danych a czas i koszty analizy
Złożoność danych online i etapy ich przetwarzania
Model danych jako sprawdzone rozwiązanie
Podsumowanie

Wprowadzenie do DataOps

W tym wpisie opisuję, jak działa DataOps w praktyce. Przedstawiam różnice pomiędzy analizami opartymi na danych przygotowanych według zasad DataOps i sprawdzonych pod względem jakości, a analizami wykonywanymi na surowych danych pobieranych bezpośrednio z narzędzi analitycznych. W artykule zostaną omówione kluczowe aspekty złożoności danych online, które są dostępne w codziennej pracy analityków. Przedstawione zostaną różnice między pracą na danych surowych a przetworzonych, na przykładzie naszego modelu danych. Zostanie również pokazane, do czego może prowadzić bagatelizowanie problemu nieustrukturyzowanych danych.

Praca na surowych danych a czas i koszty analizy

Wyobraźmy sobie sytuację, w której analityk otrzymuje proste z pozoru zadanie: ile ruchu pochodziło w marcu z poszczególnych źródeł? Jeśli korzysta z hurtowni danych, takiej jak Google BigQuery, musi sięgnąć do ogromnych, nieprzetworzonych zbiorów. Praca na takich danych, bez wcześniejszego uporządkowania i przetworzenia, może wymagać nawet 179 linii kodu, aby uzyskać odpowiedź na tak podstawowe pytanie.

Złożoność danych online sprawia, że brak odpowiedniej ich struktury i przetwarzania nie tylko utrudnia codzienną pracę, ale także prowadzi do błędów i nieefektywności. Bagatelizowanie tego problemu może przekładać się na czasochłonne analizy oraz opóźnienia w podejmowaniu decyzji biznesowych.

Odpowiednie zarządzanie danymi, ich ustrukturyzowanie i przetwarzanie są kluczowe, aby sprawnie odpowiadać na pytania biznesowe i efektywnie wykorzystywać potencjał dostępnych narzędzi analitycznych. Poniżej przykład typowego zapytania, które pozwala odpowiedzieć na konkretne pytanie analityczne. Składa się ono ze 179 linii kodu. Wynik działania tego zapytania pojawia się po jego uruchomieniu.

Takie zapytanie można jednak przetworzyć w znacznie prostszy sposób, wykorzystując wcześniej przeprocesowane dane. Wystarczy wtedy dwanaście lub dziewięć linii kodu. Po odtworzeniu tego procesu widać, że odpowiedź pojawia się znacznie szybciej. Dodatkowo, liczba przetwarzanych danych jest dużo niższa: dwadzieścia megabajtów zamiast sześciu gigabajtów w pierwszym przypadku. Oprócz szybkości działania, przetwarzana jest znacznie mniejsza ilość danych, co wpływa na koszt analizy. Wyniki pozostają takie same, jednak czas ich uzyskania jest znacznie dłuższy. Zapytanie zostało wcześniej przygotowane, jednak w praktyce za każdym razem konieczne będzie jego wykonanie. Kluczowym problemem nie są kompetencje analityka ani to, czy potrafi napisać 179 linii kodu. Główne wyzwania to czas potrzebny na przygotowanie zapytania SQL, ryzyko popełnienia błędów oraz koszt analizy w Google BigQuery.

Złożoność danych online i etapy ich przetwarzania

W przypadku analizy danych surowych, szczególnie z GA4 w Google BigQuery, dane są zorganizowane w zagnieżdżonej strukturze JSON. Po otwarciu konkretnej tabeli w BigQuery okazuje się, że pojedynczy wiersz, oznaczony np. ID eventu, zawiera kilkanaście lub kilkadziesiąt zagnieżdżonych wartości, które za każdym razem wymagają rozpakowania. Warto zwrócić uwagę, jak złożona jest analiza takich danych online. W pierwszych 179 linijkach kodu SQL uwzględnionych jest co najmniej sześć czynników, które należy wziąć pod uwagę, analizując surowy eksport danych z GA4 do Google BigQuery. Pierwszym krokiem jest zbudowanie sesji na podstawie eventów. W pliku zagnieżdżonym widoczny jest pojedynczy event, jednak aby przedstawić ruch, konieczne jest odtworzenie sesji z tych eventów. Przykładowe zapytanie pokazuje, ile eventów składa się na jedną sesję – na przykład dla jednego Session ID może być to nawet 1643 eventy. Taki zbiór danych trzeba odpowiednio przetworzyć, rozpakowując informacje na potrzeby dalszej analizy. Przed przygotowaniem podziału źródeł ruchu na poszczególne kanały, należy przekształcić tabelę z eventowej na sesyjną. Dane z miesiąca w Google BigQuery przetwarzamy na podstawie kilku milionów rekordów. Analiza obejmująca cały rok, w zależności od sezonowości, zwykle oznacza proporcjonalnie większą liczbę danych. To kolejny powód, by korzystać z wstępnie przetworzonych danych, które pozwalają znacząco obniżyć koszty pracy z Google BigQuery. Szczegółowo opisałem ten temat w osobnym wpisie, do którego link znajduje się w opisie.

Pierwszym krokiem jest więc wypłaszczenie danych. Kolejnym elementem jest naprawa ruchu direct. GA4 często klasyfikuje sesje jako direct, nawet jeśli w linku występują inne parametry, takie jak UTM czy GetSleet. Na przygotowanym przykładzie zapytania widać, że w url-u pojawia się „get-lead”, co oznacza ruch z kampanii ads. Jednak po wyciągnięciu source i medium, te pola pozostają puste. Kolejnym krokiem jest naprawa tych danych, które trafiają do systemu. Zarówno interfejs GA4, jak i surowe dane w Google BigQuery, często nie są poprawnie przetworzone.

Trzecim elementem jest wykluczenie bramek płatności. Użytkownik wracający z bramki płatności do serwisu nie powinien mieć tego ruchu przypisanego do bramki płatności. W takiej sytuacji odpowiednia logika powinna pobrać źródło ruchu z poprzedniego eventu, który miał miejsce przed przekierowaniem do zewnętrznej bramki.

Piątym krokiem jest grupowanie kanałów, a ostatnim – prezentacja wyników analizy. W przypadku każdego serwisu mogą pojawić się dodatkowe, specyficzne warunki brzegowe. W tym przykładzie sześć kroków i 179 linii kodu pokazuje, jak złożony potrafi być ten proces. Analizując dane w Google Analytics 4 i BigQuery, należy zwrócić uwagę na warunki brzegowe związane z integracją tych narzędzi. Różnice między danymi w interfejsie GA4 a surowymi danymi w BigQuery często wynikają z błędów w przypisywaniu źródeł ruchu. Przykładem jest nieprawidłowe przepisywanie ruchu z Google do Direct, co prowadzi do zaniżenia metryk, takich jak ROAS z Google Ads.

Błędy w przypisywaniu parametrów i atrybucji

Podobny problem dotyczy nieprawidłowego przypisywania parametrów, na przykład FBC Lead. Jeśli ruch z Facebooka zostanie potraktowany jako Direct, ROAS oraz META-AC również będą zaniżone. Problemy pojawiają się także przy nieprawidłowym tagowaniu kampanii UTM. Brak poprawnego przypisania źródła i medium sprawia, że ruch z danej kampanii nie pojawia się w raportach.

Warto pamiętać o tych aspektach podczas analizy danych, aby uzyskiwać wiarygodne wyniki i lepiej oceniać skuteczność prowadzonych działań marketingowych. Jednym z istotnych elementów jest bramka płatności. Transakcje są często przypisywane do bramek płatności po powrocie użytkownika z zewnętrznej strony płatności. W takim przypadku kampanie marketingowe generujące ten ruch tracą na znaczeniu w raportach. Istnieje wiele podobnych przypadków, jednak to jedne z najczęściej obserwowanych sytuacji.

Model danych jako sprawdzone rozwiązanie

Różnica między analizą surowych danych a korzystaniem z ustalonego modelu danych polega na tym, że nie trzeba każdorazowo pamiętać o wszystkich niestandardowych przypadkach. W naszym modelu danych rozwijamy i aktualizujemy te rozwiązania na bieżąco. Model powstał na bazie półtorarocznych prac i obejmuje około 95% przypadków. Przekłada się to bezpośrednio na analizę – czas odpowiedzi na proste biznesowe pytanie to 179 linii kodu w klasycznym podejściu, podczas gdy przy wykorzystaniu naszego modelu danych wystarczy jedynie 9 linii. Ryzyko popełnienia błędu jest wysokie, gdy za każdym razem kod trzeba pisać od nowa. Przy zastosowaniu modelu danych ryzyko to spada. Logika modelu została wypracowana i przetestowana na około 30 klientach, dzięki czemu jest centralizowana i sprawdzona w praktyce. W danych surowych źródła ruchu wymagają ręcznego poprawiania i uwzględniania różnych edge case’ów. Model danych natomiast narzuca gotowe, skorygowane standardy. Przy samodzielnym grupowaniu ruchu do kanałów konieczne jest tworzenie wielu dodatkowych reguł, na przykład z użyciem instrukcji if then lub case, w zależności od źródła ruchu. Model danych zapewnia jedno źródło prawdy, które można rozszerzać, gdy pojawiają się nowe źródła ruchu.

Atrybucję w danych surowych trzeba konfigurować ręcznie, dostępny jest tam tylko jeden model. W modelu danych dostępne są co najmniej trzy gotowe modele atrybucji, które można od razu wykorzystać lub dostosować do własnych potrzeb.

Identyfikacja użytkownika w danych surowych opiera się głównie na ciasteczkach przeglądarki. Model danych umożliwia unifikację użytkownika pomiędzy różnymi urządzeniami z wykorzystaniem algorytmu Unified ID. Koszt analizy surowych danych, jak w przypadku 6 GB danych miesięcznie, jest bardzo wysoki w porównaniu do minimalnych kosztów analizy 20 MB danych po wstępnym przetworzeniu. Model danych zapewnia efektywność kosztową, co jest kluczowe w podejściu DataOps.

Nasz model danych nie tylko naprawia źródła ruchu i atrybucje, ale także agreguje dane do jednego Single Source of Truth. Optymalizujemy dane pod kątem późniejszego wykorzystania, aby nie przekroczyć budżetu w Google BigQuery. System monitoruje i alarmuje w przypadku nieprawidłowości, co odzwierciedla koncepcję DataOps.

O modelu danych i DataOps można przeczytać więcej w osobnych wpisach na naszym blogu. Wkrótce pojawi się również artykuł poświęcony koncepcji GDock. Punkt szósty to analiza z wykorzystaniem różnych data produktów. Przykładem takiego rozwiązania jest AI Overview, który został omówiony w jednym z wcześniejszych wpisów na blogu. Warto zapoznać się z pełnym opisem modelu danych, gdzie szczegółowo przedstawiono tę koncepcję. Nie trzeba koniecznie korzystać z naszego modelu danych, choć oczywiście go rekomendujemy.

Podsumowanie

Podsumowując, DataOps, którego kwintesencją jest nasz model danych, stanowi sposób na efektywną analitykę. Zamiast poświęcać czas na zbieranie i porządkowanie danych, można skupić się na analizie, wyciąganiu wniosków i formułowaniu rekomendacji – czyli na tych elementach analityki, które mają największą wartość dla biznesu. Wartość analityki pojawia się na etapie wyciągania wniosków i formułowania rekomendacji. Automatyzacja zbierania danych pozwala uniknąć konieczności każdorazowego pozyskiwania surowych danych, co zmniejsza ryzyko dla biznesu. Automatyczne gromadzenie danych zwiększa bezpieczeństwo i efektywność procesów analitycznych.

The post Jedna analiza w BigQuery: 179 vs. 9 linii kodu. Różnica? DataOps. first appeared on Conversion.

Zrozumienie danych z Google Search Console
DataOps i automatyzacja pobierania danych
Analiza nożyc AI Overviews i scoring ryzyka
Rekomendacje i działania naprawcze
Podsumowanie

Zrozumienie danych z Google Search Console

Pierwszym krokiem w analizie danych dotyczących AI Overviews jest zrozumienie, jakie informacje są dostępne. Dane te pochodzą z Google Search Console. W Google Search Console kluczowe informacje znajdują się w zakładce „wyniki wyszukiwania”. Opierają się one na zapytaniach, w których pojawiamy się w wynikach wyszukiwania, liczbie kliknięć oraz liczbie wyświetleń. Na tej podstawie można przeprowadzić analizę.

Dane można wyeksportować z Google Search Console, a następnie, korzystając z Google Spreadsheets i narzędzi takich jak LLM (np. Gemini), przeprowadzić szczegółową analizę. Ograniczeniem jest dostępność jedynie 1000 wierszy do eksportu oraz fakt, że dane dostępne są tylko dla wybranego zakresu czasowego. Nie ma możliwości analizowania linii trendu dla dłuższych okresów. Aby ułatwić analizę, warto wyeksportować plik CSV i wgrać go do Google BigQuery. Analiza prowadzona dla klientów opiera się na autorskim modelu danych, który automatycznie importuje wszystkie dane do centralnej hurtowni w Google BigQuery. Więcej informacji o modelu danych znajduje się w opisie.

Pierwszym krokiem analizy jest zebranie wszystkich danych w jednym miejscu. Dostępny jest eksport z Google Search Console, który można następnie analizować w Google Spreadsheet lub zaimportować do BigQuery.

DataOps i automatyzacja pobierania danych

W Conversion od około półtora roku stosujemy w strategii podejście DataOps, zakładające maksymalną automatyzację danych i minimalizację czasu poświęcanego na ich zbieranie. Więcej o DataOps można przeczytać w dedykowanym wpisie na ten temat. W przypadku naszego rozwiązania i modelu danych konektor jest już skonfigurowany, ale można go również ustawić samodzielnie. Funkcjonalność ta nosi nazwę bulk data export, czyli masowy eksport danych. Jedną z największych zalet tego eksportu jest dostęp do pełnej listy wszystkich zapytań, na które pojawiamy się w wynikach wyszukiwania Google. Dane są dostępne w ciągu 48 godzin od konfiguracji, a eksport obejmuje dane dzienne. Funkcja ta jest darmowa, a jedynym kosztem pozostaje utrzymanie Google BigQuery.

Jeśli koszty utrzymania Google BigQuery są wysokie i stanowią barierę przed przekazywaniem kolejnych danych, warto zapoznać się z naszym poradnikiem dotyczącym optymalizacji kosztów w Google BigQuery. W przypadku naszego modelu danych możliwe jest nawet trzystukrotne zmniejszenie kosztów, co potwierdzają nasze realizacje. Po skonfigurowaniu eksportu z Google Search Console do Google BigQuery dane są wysyłane od momentu uruchomienia integracji, czyli od dnia konfiguracji. Aby uzyskać pełny zakres danych, należy pobrać dane historyczne za pomocą API. Warto zrobić to jak najszybciej, szczególnie w kontekście analizy AI Overviews, ponieważ API umożliwia dostęp do danych maksymalnie z ostatnich 16 miesięcy.

Proces pobierania danych warto zautomatyzować, na przykład przy użyciu Pythona, który codziennie pobierze dane przez API i połączy je z danymi już pobranymi przez eksport. Dzięki temu wszystkie dane, zarówno bieżące, jak i historyczne, będą dostępne do analizy trendów.

Analiza nożyc AI Overviews i scoring ryzyka

Ostatnim krokiem w gromadzeniu danych w hurtowni danych jest podłączenie Gemini, języka LLM, za pośrednictwem Vertex AI. Pozwala to na wykorzystanie możliwości Google BigQuery w kompleksowej analizie danych. Po zgromadzeniu wszystkich danych można przejść do pierwszej analizy i identyfikacji kluczowych elementów. Analiza nożyc AI Overviews polega na zestawieniu zagregowanych danych. W jednym wierszu przedstawiane są wyświetlenia, a w drugim – click-through rate (CTR). Analizujemy dane zarówno sprzed, jak i po wprowadzeniu AI Overviews. Różnica w CTR przed i po wdrożeniu określa wielkość tzw. nożyc AI Overviews.

Na przykładzie jednej z naszych analiz dane prezentowane są w formie tabelarycznej. Pokazujemy, jak zmieniły się wyświetlenia, kliknięcia i CTR po wprowadzeniu AI Overviews. Obliczone nożyce AI Overviews wskazują, że utraconych zostało niemal 800 tysięcy wizyt. Ta estymacja powstała na podstawie różnicy w CTR-ach przed i po wdrożeniu AI Overviews, pomnożonej przez aktualną liczbę wyświetleń w tej sekcji.

Nożyce w naszym frameworku są liczone tylko dla słów kluczowych o wysokim lub średnim poziomie ryzyka związanego z AI Overviews.

W analizie słów kluczowych może pojawić się także tzw. paradoks CTR. Polega on na tym, że zapytania znajdujące się na wysokich pozycjach mają niższy CTR. Wynika to z faktu, że pierwsze pozycje są przysłaniane przez sekcję AI Overview podsumowującą odpowiedź w wyszukiwarce. Identyfikacja tego paradoksu jest istotna, ponieważ wykorzystuje się go w scoringu do oceny zagrożenia ze strony AI Overviews. Drugim krokiem analizy było wstępne policzenie na dużych liczbach nożyc AI Overviews.

Intencja i kategorie zapytań

Trzeci krok polega na określeniu dla poszczególnych zapytań, wyeksportowanych z Google Search Console, dwóch wymiarów. Pierwszym z nich jest intencja, oznaczona jako No Simple, No Do, Website Visiting Person Query. Te wartości oznaczają, że jeśli pojawiamy się w wynikach wyszukiwania Google na dane zapytanie, No Simple dotyczy sytuacji, gdy użytkownik szuka bardzo konkretnej odpowiedzi, na przykład: „ile lat ma prezydent”. No to zapytanie wymagające bardziej rozbudowanej odpowiedzi, jak na przykład: „jak działa silnik hybrydowy”. Du odnosi się do sytuacji, gdy użytkownik chce wykonać jakąś akcję. Przykładowym zapytaniem może być kalkulator rat kredytu hipotecznego. Użytkownik, który chce dostać się na konkretną podstronę, wpisuje frazy takie jak „mBank Logowanie”, aby przejść bezpośrednio do strony logowania. Visiting Person Query to zapytania odnoszące się do lokalizacji w świecie rzeczywistym, na przykład „bankomat Ursynów”.

To pierwszy wymiar, któremu za pomocą Gemini lub innego LLM-a nadajemy kontekst zapytań pojawiających się w serwisie. Warto dodać, że intencja użytkownika pochodzi z raportu wykorzystywanego przez quality raterów – to 160-stronicowy podręcznik z wytycznymi. Dokument zawiera wytyczne dla osób oceniających jakość propozycji wyświetlanych przez algorytmy Google w odpowiedzi na zapytania. Jest to swoisty przewodnik, który pokazuje, jak Google rozumie intencje wpisywanych fraz. Intencje te mają charakter uniwersalny, ale można je dostosować do specyfiki własnego biznesu. Przykładowo, portal informacyjny będzie odpowiadał głównie na zapytania typu informational, serwis e-commerce na transactional, a lokalny biznes na zapytania związane z wizytą w fizycznej lokalizacji (in person query). To pierwszy wymiar analizy zapytań, które można zaimportować z Google Search Console i skategoryzować według odpowiadającej im intencji. Drugi wymiar to kategoria tematyczna, czyli określenie, czego dotyczy dane słowo kluczowe. Segmentacja według kategorii tematycznych pozwala zredukować setki tysięcy zapytań do maksymalnie kilkunastu kluczowych grup. Każdy serwis wymaga indywidualnego podejścia do tej segmentacji. Przykładowo, dla sklepu z elektroniką, RTV i AGD, kategorie zapytań mogą obejmować: specyfikację i parametry (np. iPhone 15 pojemność baterii), poradniki zakupowe (np. jaki telewizor do PS5), rankingi i porównania, opinie i recenzje, instrukcje obsługi, ceny, promocje i inne.

Narzędzia, takie jak Gemini, pomagają przypisać wszystkie zapytania do odpowiednich kategorii na podstawie wyników wyszukiwania. Po zakończeniu tego etapu kolejnym krokiem analizy jest ocena scoringu ryzyka związanego z AI Overviews.

Scoring ryzyka

Dla każdego słowa kluczowego wyeksportowanego z Google Search Console algorytm przypisuje odpowiedni scoring ryzyka. Scoring opiera się na czterech parametrach. Pierwszym z nich jest intencja, która ma wagę czterdziestu procent. Najwyższy scoring otrzymuje No Simple, co oznacza największe zagrożenie, oraz No i kolejne, w zależności od poziomu narażenia. Kolejnym parametrem jest aktualny CTR. Im niższy CTR w danym okresie, tym większe ryzyko obecności w IA Overview. W takich przypadkach pojawiają się tzw. zero klik wizyty, czyli sytuacje, w których użytkownicy otrzymują odpowiedź jeszcze przed kliknięciem w wynik wyszukiwania. Scoring uwzględnia paradoks pozycji i ma wartość dwudziestoprocentową. Następnie analizowane jest, jak bardzo trend załamał się przed pojawieniem się AI Overviews i po jego wprowadzeniu. Na tej podstawie każde słowo, które następnie agregowane jest do kategorii, otrzymuje scoring określający ryzyko spadku ruchu w związku z AOW. Wynik powyżej 7 oznacza wysokie ryzyko, między 4 a 6 i 9 – średnie ryzyko, natomiast poniżej 4 – niskie ryzyko.

Nożyce A Overfuse są liczone tylko dla słów kluczowych zakwalifikowanych jako medium i high. W ten sposób można pokazać, jaki wolumen ruchu jest tracony w związku z obecnością AOV. Po przejściu przez cztery poprzednie kroki – centralizacji danych, obliczeniu współczynników na zagregowanych danych, przypisaniu intencji i kategorii – cały proces zostaje zakończony. Do każdego zapytania dodaliśmy scoring ryzyka EA Overviews. Następnie przechodzimy do analizy tych danych. Na ekranie można zobaczyć, jaki procent wszystkich zapytań, na które się pojawiamy, rzeczywiście znajduje się w kategorii dużego, średniego lub małego ryzyka.

Rekomendacje i działania naprawcze

W przedstawionym przykładzie ponad 60% całego ruchu jest zagrożone przez AI Overviews w kategoriach Medium i High. Oznacza to 788 tysięcy kliknięć, czyli potencjalnych wizyt w serwisie, które tracimy właśnie z powodu AI Overviews.

Analizując dane, schodzimy do poziomu konkretnych kategorii słów kluczowych, aby sprawdzić, w których obszarach jesteśmy najbardziej narażeni. Możemy również przeprowadzić szczegółową analizę na poziomie poszczególnych zapytań, aby zobaczyć, jak sytuacja wygląda w naszym przypadku. Na podstawie tych danych można przygotować rekomendacje wynikające z przeprowadzonej analizy. Aby chronić skuteczne słowa kluczowe i sprawdzić możliwość odzyskania innych, szczególnie narażonych na ryzyko związane z AI Overview, warto rozważyć działania niezwiązane z wynikami wyszukiwania. Gdy targetujemy obszary, w których AI Overviews ukrywa nasze wyniki wyszukiwania, można przetestować alternatywne rozwiązania poza wynikami organicznymi. Przykładem jest stworzenie dedykowanego newslettera związanego z określonym aspektem biznesu, który dotychczas był pochłaniany przez AI Overviews.

Warto również rozważyć działania, które mogą zastąpić ruch z SEO generowany do tej pory przez Overviews. Kluczowe jest mierzenie każdej hipotezy, strategii oraz każdej zmiany w treściach i pozycjonowaniu SEO. Dzięki temu, że dane zostaną zebrane i odpowiednio policzone, można wyciągać wnioski i optymalizować działania.

Automatyzacja jest kolejnym krokiem w procesie DataOps. Zamiast jednorazowego pobierania i analizy danych, warto wdrożyć zautomatyzowane rozwiązania. Przykładem są alerty, które informują o istotnych zmianach w danych. Gdy dana kategoria słów kluczowych nagle traci na znaczeniu, na przykład w związku z AI Overview lub innymi czynnikami, analiza danych pozwala szybko zidentyfikować zmianę. Automatyzacja jest niezbędna do obserwowania trendów, zwłaszcza podczas testowania hipotez w ramach strategii contentowej lub SEO. Wszystkie wyniki można zwizualizować w Lookerze, aby osoby odpowiedzialne za content i SEO miały stały podgląd na zmiany.

W Conversion realizujemy te procesy w ramach modelu danych. Jest to jeden z naszych data produktów. Model danych naprawia dane, co ma szczególne znaczenie w przypadku GA4, gdzie często pojawiają się problemy z poprawną atrybucją i jakością informacji. Model danych agreguje wszystkie informacje w jednym miejscu, tworząc single source of truth. Optymalizuje dane, szczególnie z GA4 w kontekście Google BigQuery. W jednym z wcześniejszych wpisów pokazaliśmy, jak o 288 razy zmniejszyliśmy koszt obsługi raportów GA4 za pośrednictwem Lookera, wykorzystując eksport surowych danych z GA4.

Model monitoruje dane i w razie potrzeby wysyła alerty. Analizuje również dane za pomocą data produktów, takich jak analiza nożyc AI Overviews.

Podsumowanie

Proces analizy, o którym mowa, na początku wymaga zebrania wszystkich danych, jednak po wdrożeniu warto go zautomatyzować i na bieżąco śledzić wyniki. Pozwala to obserwować dane dotyczące wyników w organicznych wyszukiwaniach Google, wizualizować je na dashboardzie i ustawiać alerty na najważniejsze słowa kluczowe. Dzięki temu raportowanie efektów testów związanych z SEO lub strategią kontentową staje się prostsze.

Cały proces można zautomatyzować, konfigurując eksport z Google Search Console do Google BigQuery. Warto też skorzystać z naszego modelu danych, który już od pierwszego dnia wdrożenia umożliwia automatyczne i poprawne gromadzenie wszystkich potrzebnych informacji. W przypadku pytań dotyczących analizy lub modelu danych, zapraszamy do kontaktu.

The post Jak AI Overviews wpływa na ruch organiczny z SEO? Konkretna analiza. first appeared on Conversion.

Czego dowiesz się z tego wywiadu:

Czym jest strategia danych i po co jej potrzebujemy?

Sygnały ostrzegawcze: kiedy firma potrzebuje strategii?

Dlaczego same dashboardy nie rozwiązują problemów?

Drzewo KPI i walka z silosowością organizacji

Od danych do decyzji: 3 kroki do wdrożenia

Czym jest strategia danych i po co jej potrzebujemy?

Sens zbierania informacji w dobie nadmiaru danych

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 Daniel, który w Conversion zajmuje się strategią danych dla naszych klientów. Czyli co to znaczy, czym się zajmujesz, co robisz na co dzień?

Daniel Połeć: Cześć Mariusz. Strategia danych jest o osiąganiu celów biznesowych i o rozwiązywaniu problemów, a konkretnie o tym, w jaki sposób dane online mogą nam pomóc. Czyli w tym, żeby ten nasz cel osiągnąć, zmierzyć się z problemem lub go rozwiązać.

Mariusz Michalczuk: Tych danych jest tak dużo, że pojawia się pytanie: po co jeszcze do tego strategia? Mamy tak dużo informacji, że wydaje się wręcz niemożliwe, by nie pomagały w rozwiązywaniu problemów fizycznych.

Daniel Połeć: Już nie ma gdzie dolać, bo ta szklanka jest pełna, prawda? Strategia danych to jest ta szklanka. Właśnie dlatego, że tych danych jest tak dużo, w tym morzu można utonąć. Jeżeli my nie wiemy, DO CZEGO te dane będą nam potrzebne, do czego chcemy ich użyć, jaką rolę pełnią w podejmowaniu decyzji, skazujemy się na skrajności. Albo te dane totalnie zignorujemy i w ogóle ich nie będziemy mieli, albo pójdziemy w drugą stronę: będziemy mieli tak duży chaos i szum informacyjny, że nie będziemy w stanie z nich skorzystać. Ta pierwsza sytuacja jest rzadsza. Natomiast ta druga, gdzie toniemy w danych i nie wiemy, co jest ważne, więc nie patrzymy na nic, jest bardzo częsta – od małych po duże organizacje.

Wspólny język i definicje jako fundament

Mariusz Michalczuk: Czyli można powiedzieć, że wszyscy mają dane, ale mało kto wie, jak z nich korzystać?

Daniel Połeć: Wiedzą ci, którzy mają jakąś strategię. Może być spisana, oficjalna lub tylko z tyłu głowy – to jest okej, jeżeli działa. Jeżeli jej w ogóle nie mamy, nie jesteśmy w stanie z tych danych skorzystać. Co z tego, że mamy super samochód na podjeździe, skoro nie potrafimy nim jeździć.

Mariusz Michalczuk: Strategia to szumne słowo. Odmienia się je przez przypadki w całej organizacji, od zarządu przez marketing. Jak opowiedziałbyś bardziej namacalnie, czym ta strategia w kontekście danych jest? Co w niej się znajduje i jak jest widoczna w organizacji?

Daniel Połeć: Poza tym, że bywa odmieniana przez wszystkie przypadki, wydaje się wielkim i mądrym pojęciem. Zwykło się uważać, że trzeba mieć ogromny segregator ze strategią danych. Zupełnie nie. Wszystko zależy od etapu rozwoju organizacji. Na najprostszym poziomie: bardzo ważnym elementem strategii danych są definicje. Jak rozumiemy konkretną metrykę jako organizacja. Spotkaliśmy się kiedyś z metryką „udział w rynku”. Brzmi mądrze, prawda? Tylko okazało się, że u klienta nikt do końca nie wiedział, skąd te dane się biorą i jak ten udział jest liczony. Ktoś to wyliczał na podstawie starych zasad, ale nikt na to nie patrzył. Niewiele to dawało.

Musimy ustalić definicję metryk. Czym innym jest zakup dla marketingu (złożenie zamówienia), czym innym dla logistyki, a czym innym dla zarządu, który patrzy na zysk i koryguje wynik o zwroty. Nie istnieje jedna idealna definicja. Mamy trzy różne metryki i patrząc na raport, musimy wiedzieć, na którą z nich patrzymy, ponieważ to poprowadzi nas do konkretnych decyzji. Jeżeli rozmawiamy ze sobą przez pryzmat raportów, musimy rozumieć się nawzajem. To jak obietnica „fajnych wakacji” – dla każdego oznacza to co innego. Drugim bardzo ważnym elementem strategii jest odpowiedź na pytanie: do czego te dane nam w ogóle służą? To najważniejsza rzecz z naszej rozmowy. W tej układance nie chodzi o dane, chodzi o decyzje.

Sygnały ostrzegawcze: kiedy firma potrzebuje strategii?

Rozjazdy w systemach i utrata zaufania do liczb

Mariusz Michalczuk: Chciałbym Cię zapytać, bo wymieniłeś te elementy: definicje i cel gromadzenia danych. W jakich przypadkach klienci do nas przychodzą? Co jest impulsem, że zaczynamy rozmawiać o strategii danych?

Daniel Połeć: Warto rozróżnić motywacje świadome i nieświadome. Częstą świadomą motywacją jest to, że klienci obserwują rozjazdy w danych i po prostu przestają im ufać.

Mariusz Michalczuk: W ogóle przestają patrzeć na te dane.

Daniel Połeć: Na przykład. To częsta sytuacja: w reklamach Meta mają przychodu milion złotych, a w Google Analytics dla źródła Meta system pokazuje siedemset tysięcy. Na co mają patrzeć? Różnica to trzysta tysięcy, trzydzieści procent.

Mariusz Michalczuk: A na końcu okazuje się, że w CRM masz dwa razy mniej niż suma wszystkich systemów reklamowych.

Daniel text: Zdecydowanie tak. Wtedy pojawia się frustracja. Skoro w CRM są realne pieniądze najbliższe stanowi konta, to po co patrzeć na resztę? Klienci przychodzą, chcąc ujednolicić te źródła, aby móc podejmować decyzje. Niestety, ujednolicenia do jednej idealnej liczby zrobić się nie da. Obecny stan przypomina sytuację z zegarkami: jak masz jeden zegarek, wiesz, która godzina. Jak masz dwa – przestajesz być pewny.

\

Dlaczego same dashboardy nie rozwiązują problemów?

Nie chodzi o to, by liczby się zgadzały, ale by wspierały decyzje

Mariusz Michalczuk: Klienci nie wiedzą, komu ufać. Każdy system reklamowy gra do swojej bramki, by pokazywać jak najwięcej przypisanej wartości. To oczywiste.

Daniel Połeć: Klienci proszą o „czary-mary”, żeby liczby się zgadzały. Oczywiście poprawne wdrożenie i pokrycie danych między analityką a CRM to podstawa. Zawsze najpierw dbamy o jakość danych. Nie dążmy jednak do tego, by liczby z różnych platform zawsze były identyczne. Zastanówmy się, w jakiej sytuacji skorzystamy z liczby raportowanej przez Metę, a w jakiej z Google Analytics. To jest nieświadoma motywacja – przychodzą po ujednolicenie, a my musimy dać im strategię używania tych danych z różnych perspektyw.

Mariusz Michalczuk: Rozbieżności były, są i będą. Załóżmy jednak firmę świadomą. Czy takie organizacje od razu przychodzą po strategię danych?

Daniel Połeć: Jest mało sytuacji, gdzie ktoś przychodzi bezpośrednio po strategię danych. Najczęściej zgłaszają objawy braku strategii. Czasami to firmy pragnące rozwoju. Mówią: chcielibyśmy podejmować lepsze decyzje, być bardziej data-driven. Nie dajemy im od razu paczki pięciu raportów do wdrożenia. Zaczynamy skupiać się na ich celach i problemach, układając proces wokół biznesu.

Raport jako narzędzie bez kontekstu biznesowego

Mariusz Michalczuk: Powiedzmy, że mamy definicje, wszystko jest zwizualizowane. Czy to już jak za dotknięciem czarodziejskiej różdżki wszystko rozwiązuje? Mam raport, więc jestem data-driven?

Daniel Połeć: Nie wystarczy. Raport czy dashboard to rodzaj produktu, który sam w sobie niczego nie rozwiązuje. Jak kupujesz młotek, to nie znaczy, że obrazy same zawisną na ścianach. Musisz go użyć. Łączymy się w bólu z analitykami: często tworzą dashboardy, z których później w firmie nikt nie korzysta lub robi to niewłaściwie. Powód? Raport nie prowadzi bezpośrednio do celu. Czy jeżeli kupię podnośnik samochodowy, to stanę się mechanikiem?

Mariusz Michalczuk: Dlaczego te raporty nie pomagają? Czego brakuje?

Daniel Połeć: Clue sytuacji tkwi w biznesie. Robiąc wywiad z klientem, pytamy o model biznesowy, konkurentów, wartości firmy. Klienci bywają zdziwieni, bo przecież „przyszli po dane”. Pytamy o cele na dany kwartał i wyzwania. Tylko dzięki temu potrafimy dopasować rozwiązanie. Dashboard nieosadzony w kontekście biznesowym i niewspierający konkretnej decyzji – sam z siebie nic nie zrobi.

Drzewo KPI i walka z silosowością organizacji

Zrozumienie dekompozycji wskaźników

Mariusz Michalczuk: Wydaje się, że wszystko musi zaczynać się od poziomu zarządczego. Lider ma ogromne zadanie: doprowadzić do powstania raportów i zatroszczyć się o proces decyzyjny.

Daniel Połeć: Cały czas mówimy o dashboardach, a przecież narzędziem do podjęcia decyzji może być alert. Są metryki jak ciśnienie w oponach – nie sprawdzasz tego codziennie. Jeśli wartość spadnie poniżej pewnego progu, dostajesz powiadomienie i musisz zareagować. To zdejmuje problem z głowy i pozwala skupić się na jeździe. W niektórych procesach automatyczny alert jest znacznie lepszym rozwiązaniem niż kolejny wykres.

Mariusz Michalczuk: Mamy stałe raportowanie, mamy alerty. Czasami też zlecamy analizę naszemu analitykowi. Moje obserwacje są takie: te analizy często kończą się suchym raportem, w którym brakuje rekomendacji i wyciągnięcia wniosków. Z czego to wynika?

Daniel Połeć: Jak myślisz, dlaczego brakuje tam rekomendacji?

Mariusz Michalczuk: Myślę, że problemem jest czas. Na 100 jednostek czasu, analityk spędza 85 na gromadzeniu, integracji i wyjaśnianiu rozbieżności. Na samą kwintesencję, czyli wyciągnięcie wniosków, zostaje 15 procent czasu.

Daniel Połeć: Zgadzam się, ten proces bywa czasochłonny. Jednak większym problemem jest brak kontekstu biznesowego. Gdybyś dał mi dostęp do Google Analytics i poprosił o ciekawe wnioski bez znajomości modelu biznesowego naszej firmy, nie wiedziałbym, do czego przypiąć te dane. Zauważyłbym wzrosty i spadki, ale nie umiałbym postawić celnej rekomendacji. Kontekst musimy ustalić na samym początku analizy. To jak prośba do żony o zaplanowanie „fajnych wakacji” bez podania kryteriów. Przyniesie oferty nad morzem, a ty wolałeś góry.

Pytanie nie brzmi: co powinniśmy mierzyć? Pytanie brzmi: co jako organizacja chcemy osiągnąć? Dopiero mając cel, dobieramy dane, które nam w tym pomogą. To kolosalna różnica w podejściu i klamra spinająca to, dlaczego zawsze zaczynamy od biznesu.

Metodologia działania „step down”

Mariusz Michalczuk: Zdarza się, że raport pokazuje świetne wyniki, a na końcu CFO mówi, że pieniądze na koncie się nie zgadzają. Dlaczego firmy patrzą na liczby, ale nie wiedzą, co faktycznie działa?

Daniel Połeć: Opisałeś idealny objaw silosowości. W naszym dziale wszystko świeci na zielono, a w ujęciu finansowym firma traci. Dochodzi do tego dlatego, że nie mamy drzewa KPI (KPI tree). Zaczynamy od dochodu (przychód minus koszty). Schodzimy w dół analizując, jak liczba kliknięć reklam wpływa na kolejne szczeble, aż po sam dochód. Jeśli wyłączymy opłacalne reklamy, w krótkiej perspektywie zaoszczędzimy koszty, ale z czasem zabraknie ruchu i przychodów. Widząc te powiązania na mapie metryk, skutecznie burzymy silosy.

Mariusz Michalczuk: To przypomina mapę biznesu opartą na tablicy rozdzielczej w samochodzie.

Daniel Połeć: Świetne porównanie. Gdy zapali się kontrolka check engine, wiemy, że musimy zareagować, podpiąć komputer i sprawdzić detale. Nie musimy wrzucać wszystkich najdrobniejszych wskaźników na główny ekran, bo powstanie szum. Wybieramy metryki priorytetowe. Co ważne, inicjatywa musi wyjść z góry – od zarządu, przez dyrektorów, do specjalistów. Nawet jeśli obecnie brakuje nam danych do wyliczenia idealnej metryki korygującej zwroty w marketingu, zaplanujmy ją, ale pracujmy na tym, co już mamy.

Od danych do decyzji: 3 kroki do wdrożenia

Jak pracować z dashboardami na co dzień?

Mariusz Michalczuk: Tablica rozdzielcza w aucie sugeruje wizytę u mechanika, ale dashboard nie mówi „skręć w lewo”. Jakie pytania powinniśmy zadawać do danych, żeby prowadziły do działania?

Daniel Połeć: Należy zadawać pytanie „dlaczego?”. O czym świadczy dany wzrost lub spadek? Odpowiedź znajdziemy dzięki drzewu KPI. Obserwujemy powiązania. Content manager piszący artykuły na bloga widzi, jak ilość i tematyka tekstów wpływają na jakość ruchu i konwersję w całej firmie. Dashboard główny pokaże mu, że dowieziono mniej ruchu. Wtedy ten specjalista otwiera swój lokalny kokpit, przeprowadza dekompozycję i analizuje wskaźniki szczebel niżej w Google Search Console.

Mariusz Michalczuk: Trochę jak pilot samolotu – ma checklistę i kolejne kroki w przypadku awarii.

Daniel Połeć: Pilot wie, co robić, bazując na doświadczeniu. Content manager z dobrym frameworkiem analizy również wie, czy musi zmienić tematykę tekstów, czy publikować częściej. Narzędzie daje sygnał (trigger) do działania. To dlatego każde stanowisko potrzebuje nieco innych danych. Nie ma rozwiązań uniwersalnych dla wszystkich.

Podsumowanie: Analityka przyspieszająca decyzje

Mariusz Michalczuk: Słowo „decyzja” przewija się tu stale. Zatem dobra analityka powinna prowadzić do decyzji, a nie zatrzymywać się na informacji z dashboardu?

Daniel Połeć: Analityka to fundament procesu decyzyjnego. Zabezpiecza przed chaosem i zgadywaniem. W zeszłym roku, gdy weszły powiadomienia AI w Google, wielu firmom spadł ruch. Przez brak dekompozycji i panikę ratowano się zwiększaniem budżetów w płatnych reklamach. Ruch wrócił, ale kosztem przepalonego budżetu, bo problem leżał gdzie indziej. Dane pozwalają robić właściwe kroki w odpowiednim czasie. Inaczej nie jesteśmy data-driven, lecz dashboard-driven.

Mariusz Michalczuk: Jakie są konkretne kroki dla słuchaczy, żeby faktycznie przejść od danych do decyzji?

Daniel Połeć: Krok pierwszy: Zdefiniowanie celów i problemów. Co nas blokuje w pracy z danymi? Czasami barierą jest czas tracony na ręczne eksportowanie Exceli. Zdiagnozujmy to.
Krok drugi: Ustalenie definicji metryk na poziomie całej firmy. Zbudowanie wspólnego słownika i przypisanie ownerów do konkretnych wskaźników (kogoś, kto odpowiada za daną decyzję).
Krok trzeci: Powiązanie tych metryk w drzewo KPI (KPI tree). Adaptacja tej zmiany uodporni organizację na podejmowanie chaotycznych ruchów.

Mariusz Michalczuk: Potwierdzeniem sukcesu będzie moment, w którym wyprzedzimy dział finansowy i będziemy dokładnie wiedzieli o ewentualnym spadku, zanim zapisze się on w bilansie bankowym. Stajemy się wywiadem biznesowym.

Daniel Połeć: Dokładnie. Poprzez działające drzewo KPI burzymy silosy i widzimy pełen obraz sytuacji na bieżąco.

Mariusz Michalczuk: Mega dzięki. Turbo inspirujące i bardzo konkretne. Do zobaczenia.

Daniel Połeć: Było mi bardzo miło. Do zobaczenia.

The post Czym jest strategia danych – Daniel Połeć – Date with Data Talks first appeared on Conversion.

Wdrożenie podejścia DataOps – jak ograniczyć wydatki?
Z czego wynikają koszty Google BigQuery?
Dlaczego raporty z domyślnego eksportu GA4 są drogie?
Jak obniżyć koszty analizy danych?
Efekty wdrożenia optymalizacji
Podsumowanie

Wdrożenie podejścia DataOps – jak ograniczyć wydatki?

Istnieje jednak skuteczne rozwiązanie. Wdrożenie podejścia DataOps oraz dedykowanego modelu danych pozwala znacząco ograniczyć te wydatki – nawet kilkusetkrotnie. Koszt korzystania z Google BigQuery to jedna z kluczowych kwestii, które warto uwzględnić podczas planowania infrastruktury analitycznej. Eksport danych z GA4 oraz obsługa raportów GA4 za pośrednictwem Google BigQuery mogą znacząco wpłynąć na wysokość wydatków związanych z analizą danych. W tym wpisie opisuję, z czego wynika koszt Google BigQuery, dlaczego eksport danych z GA4 i tworzenie raportów przez BigQuery potrafi generować wysokie koszty oraz jak skutecznie je obniżyć.

Z perspektywy biznesowej zrozumienie struktury kosztów Google BigQuery pozwala lepiej zarządzać wydatkami na utrzymanie infrastruktury analitycznej. W pierwszej części artykułu wyjaśniam, jakie czynniki mają wpływ na wysokość kosztów. W drugiej części przedstawiam praktyczne wskazówki, które pozwalają zoptymalizować wydatki związane z obsługą raportów w Google BigQuery.

Z czego wynikają koszty Google BigQuery?

Koszt Google BigQuery wynika przede wszystkim z ilości danych przetwarzanych podczas zapytań oraz przechowywania danych. Szczegółowe omówienie tych aspektów znajduje się poniżej. Koszty korzystania z Google BigQuery składają się z dwóch elementów: opłat za przechowywanie danych oraz opłat za wykonywanie obliczeń na tych danych. Na stronie z cennikiem można znaleźć informacje o dostępnych bezpłatnych limitach, jednak są one niewielkie. Wysokość opłat zależy od regionu, w którym dane są przechowywane, a także od ilości i zakresu przetwarzanych danych. Zazwyczaj koszt korzystania z BigQuery jest niski.

Dlaczego raporty z domyślnego eksportu GA4 są drogie?

Pojawia się jednak pytanie, dlaczego mimo niskich kosztów BigQuery, rachunki za wykorzystanie danych z Google Analytics 4 w raportach Looker Studio mogą być wysokie, zwłaszcza gdy Looker Studio jest połączone z Google BigQuery. Wynika to ze sposobu, w jaki zbudowane jest Google BigQuery. Dane są zorganizowane w strukturze zagnieżdżonych wartości, które trafiają do BigQuery na podstawie tzw. schematów danych. Struktury JSON różnią się od relacyjnych baz danych tym, że wszystkie informacje zapisane są w jednym wierszu, często w postaci zagnieżdżonej. W relacyjnych bazach danych dane są podzielone na oddzielne tabele, na przykład: zdarzenia, sesje, transakcje, produkty. Łączenie tych informacji następuje dopiero podczas tworzenia zapytania, gdzie dane z różnych tabel są łączone na podstawie relacji między nimi. Klucze umożliwiają powiązanie tabel, przykładowo: tabela z użytkownikami pozwala powiązać konkretnego użytkownika z transakcjami i sprawdzić, co kupił w danej transakcji. W kontekście analizy produktów, tablica z użytkownikami posiada klucz ID transakcji. Transakcje zawierają klucze ID produktów, dzięki czemu można pobierać szczegóły dotyczące tych produktów. W Google BigQuery wszystkie dane znajdują się w jednym wierszu. Szukając konkretnej informacji, należy przejść przez wszystkie kolumny danego wiersza, a nie tylko wybraną kolumnę.

 
Korzystając z domyślnego eksportu Google Analytics 4 do BigQuery, każdą kolumnę pliku JSON trzeba przeszukać, aby znaleźć konkretną informację, na przykład Page Location lub Transaction ID. Taka nieustrukturyzowana tabela, po podłączeniu narzędzi wizualizacyjnych czy narzędzi klasy BI, takich jak Looker Studio czy Power BI, wymaga każdorazowego rozpakowania dużego wiersza podczas zmiany zakresu dat, segmentacji czy filtrowania. Narzędzie musi za każdym razem przetworzyć tysiące rekordów, aby dotrzeć do szczegółowych informacji. Wraz ze wzrostem liczby użytkowników korzystających z tych narzędzi każda zmiana, segmentacja czy analiza raportu powoduje ponowne przetwarzanie i przerzucanie tysięcy danych.

Jak obniżyć koszty analizy danych?

Jak obniżyć koszty analizy danych? Poniżej przedstawiamy, jak podchodzimy do tego w Conversion na podstawie naszego modelu danych.

Nasz model danych został szczegółowo opisany na stronie, a poniżej opisujemy najważniejsze kroki, które pozwalają efektywnie obniżać koszty analiz.

Wypłaszczanie tabel

Pierwszym etapem jest wypłaszczanie tabel, czyli tworzenie dedykowanych tabel według określonego schematu. Powstają między innymi tabela sesyjna, transakcyjna, produktowa oraz z użytkownikami.

Tworzenie tabel w sposób inkrementalny

Drugim krokiem jest tworzenie tych tabel w sposób inkrementalny. Zamiast codziennie przeliczać i generować tabele od nowa, dodajemy jedynie wartości inkrementalne, czyli dane przyrostowe. Zamiast przetwarzać całą historię danych od 2023 roku, przetwarzamy tylko dane z poprzedniego dnia i dopisujemy je do gotowej, wypłaszczonej tabeli.

Partycjonowanie i klasteryzacja

Kolejnym elementem jest partycjonowanie i klasteryzacja. W naszym przypadku partycją jest data, a klastrem – nazwa eventów. Dzięki takiej organizacji tabel, podczas wyszukiwania wyników z Black Friday, Google BigQuery nie analizuje wszystkich danych, na przykład z lipca, tylko od razu sięga do odpowiedniego segmentu, w którym znajdują się potrzebne dane.

Unified ID i system DataOps

Czwarty element wykorzystywany w naszym modelu danych to Unified ID. Unified ID umożliwia łączenie różnych urządzeń przypisanych do jednego użytkownika w jeden wiersz danych, jeśli użytkownik został rozpoznany. Dzięki temu, podczas analizy danych, nie trzeba płacić za każdy rekord dotyczący trzech czy czterech urządzeń tego samego użytkownika. W praktyce Google BigQuery, korzystając z funkcji lub algorytmu Unified ID, traktuje różne urządzenia jako jednego użytkownika przypisanego do jednego Unified ID. Mniejsza liczba wierszy do przetworzenia oznacza niższy koszt analizy danych. DataOps stanowi kluczowy element strategii konwersyjnej, której Conversion przestrzega od półtora roku. W tej koncepcji analityka przypomina fabrykę. System analityczny działa jak linia produkcyjna, której celem jest generowanie wartościowych insightów biznesowych. Kluczowa staje się wydajność – nie ma potrzeby każdorazowej pracy z nieustrukturyzowanymi danymi.

Efekty wdrożenia optymalizacji

Efekty wdrożenia DataOps są znaczące. Koszty analizy danych można obniżyć nawet 300-krotnie. Na poniższym przykładzie raportu widać rezultaty, jakie osiągnęliśmy dla klienta po wdrożeniu nowego modelu danych. Poniżej znajdują się założenia raportu. Analizując przypadek klienta, sprawdziliśmy dzienny oraz roczny wolumen danych eksportowanych z GA4 i wyliczyliśmy koszt ich przechowywania. Przeprowadziliśmy symulację dwóch podejść. Pozostając przy surowych danych z GA4, do analizy potrzebowaliśmy 3,17 GB. Natomiast w przypadku tabeli raportowej, wykorzystywanej do kluczowych raportów biznesowych, było to jedynie 11 MB.

Dla wybranych zakresów danych, przy symulacji pięciu zapytań dziennie, roczny koszt analizy surowych danych wyniósł 74 dolary. Z kolei przy analizie opartej na tabelach stworzonych według naszego modelu danych, koszt spadł do 0,25 dolara. Koszty utrzymania Google BigQuery przy rocznej symulacji okazały się ponad 300 razy niższe przy zastosowaniu zoptymalizowanego modelu danych. To jedna z kluczowych korzyści wynikających z wdrożenia naszego modelu danych. Model danych optymalizuje koszty Google BigQuery oraz naprawia dane pod względem atrybucji i źródeł ruchu. W GA4 występują błędy dotyczące tych zagadnień, dlatego agregacja wszystkich danych w jednym miejscu tworzy jedno, wiarygodne źródło prawdy. Model ten optymalizuje również koszt utrzymania systemu raportowania opartego na Google BigQuery. Dodatkowo, monitoruje dane, a w przypadku wykrycia nieprawidłowości w danych serwisu, automatycznie informuje o tym, na przykład za pomocą wiadomości na Slacku.

Model danych zawiera data-produkty, czyli produkty analityczne prezentujące wpływ działań na konkretne KPI oraz dostarczające insajtów dotyczących ich poprawy.

Podsumowanie

Częstym błędem w firmach jest podłączanie Looker Studio bezpośrednio do surowych danych z eksportu GA4 do Google BigQuery. Gdy coraz więcej osób zaczyna korzystać z tych raportów, koszty Google BigQuery gwałtownie rosną. Można tego uniknąć, wypłaszczając tabele, tworząc je w sposób inkrementalny, stosując klastrowanie i partycjonowanie, a także korzystając z Unified ID. Wszystkie opisane kroki można wykonać samodzielnie lub skorzystać z naszego modelu danych. W przypadku pytań zachęcam do kontaktu.

The post Jak obniżyć koszt BigQuery? Wszystko przez eksport GA4! first appeared on Conversion.

Co znajdziesz w tym artykule?
Co to jest Big Data?
Jakie cechy definiują wielkie zbiory danych? Model 5V
Jakie rodzaje danych składają się na Big Data?
Jakie technologie i narzędzia służą do przetwarzania Big Data?
Gdzie znajduje zastosowanie analityka Big Data?
Jakie korzyści przynosi firmom wykorzystanie Big Data?
Jakie wyzwania dotyczą bezpieczeństwa i prywatności danych?
Kim jest Data Scientist i jaką rolę odgrywa w procesie analizy?

Co to jest Big Data?

Big Data to termin opisujący duże zbiory danych. A właściwie tak duże, tak zróżnicowane i tak szybko zmieniające się, że tradycyjne narzędzia przestają wystarczać. Bywają też przez to określane jako wielkie zbiory danych lub po prostu gigadane. Ich skala i złożoność (complexity) przekraczają możliwości arkuszy kalkulacyjnych czy klasycznych baz danych.

W praktyce chodzi jednak nie tylko o sam rozmiar. Big Data to również sposób, w jaki odbywa się przetwarzanie informacji, ich porządkowanie i analiza danych – po to, by wykrywać wzorce, przewidywać zjawiska i podejmować trafniejsze decyzje. To właśnie dlatego temat stał się tak ważny dla biznesu, technologii i innych obszarów, w których liczy się szybka reakcja na zmiany.

Co ważne, dane napływają z wielu różnych źródeł jednocześnie. Mogą pochodzić z mediów społecznościowych, urządzeń Internetu Rzeczy (IoT), aplikacji mobilnych, systemów sprzedażowych czy z innych zasobów, takich jak np. logi systemowe. W efekcie Big Data jest dziś jednym z fundamentów tego, co nazywamy transformacją cyfrową – ponieważ pozwala przekładać ogromne strumienie danych na wiedzę, a następnie na konkretne działania.

Jakie cechy definiują wielkie zbiory danych? Model 5V

Najczęściej wielkie zbiory danych opisuje się współcześnie przez model 5V, który rozwinął wcześniejszy model 3V (skupiający się głównie na skali, szybkości i różnorodności danych – volume, velocity, variety). W niektórych opracowaniach można spotkać model 4V, który do klasycznego 3V dodaje veracity, czyli wiarygodność/jakość danych.

Czasem pojawia się też pojęcie zmienności (variability), które opisuje niestabilność danych i zmieniający się kontekst ich interpretacji. To jednak model 5V pozostaje dziś najczęściej używanym sposobem porządkowania tematu. Obejmuje on pięć kluczowych cech Big Data:

Volume (wolumen)

Inaczej: ilość danych. W praktyce nie mówimy już o megabajtach czy gigabajtach, ale o zasobach liczonych w terabajtach, petabajtach, a czasem nawet w eksabajtach i zettabajtach. To właśnie wolumen danych w Big Data sprawia, że tradycyjne narzędzia szybko przestają być wystarczające.

Velocity (prędkość)

Tempo, w jakim dane są generowane, przesyłane i analizowane. Prędkość ma ogromne znaczenie w Big Data, bo wiele informacji napływa niemal w czasie rzeczywistym – z aplikacji, systemów transakcyjnych, czujników czy platform cyfrowych. W takich warunkach liczy się nie tylko sam dostęp do danych, ale też zdolność do szybkiej reakcji.

Variety (różnorodność)

Big Data to nie jeden format i nie jeden typ informacji. Różnorodność oznacza, że w jednym środowisku mogą pojawiać się jednocześnie liczby, tekst, obrazy, nagrania wideo, logi, dane lokalizacyjne czy dane sensoryczne. Ta “mieszanka” mocno zwiększa stopień trudności analizy.

Veracity (wiarygodność)

Dane muszą być sensowne. Wiarygodność odnosi się do jakości, rzetelności i spójności przetwarzanych informacji. Jeśli dane są błędne, niepełne albo przypadkowe, nawet najlepsza analiza może prowadzić do złych wniosków. Dlatego tak ważna jest ich weryfikacja.

Value (wartość)

Ostatecznie najbardziej liczy się to, czy dane da się przełożyć na decyzje, oszczędności, lepsze prognozy albo przewagę konkurencyjną. Wartość pokazuje, że Big Data nie jest sztuką dla sztuki. Dane mają sens dopiero wtedy, gdy wspierają konkretne cele biznesowe lub operacyjne.

Jakie rodzaje danych składają się na Big Data?

Od formy danych zależy zarówno sposób ich przechowywania, jak i późniejsze przetwarzanie oraz analiza. Big Data obejmuje trzy główne typy informacji:

Dane ustrukturyzowane

Nazywane też danymi strukturalnymi. Mają uporządkowaną formę. Łatwo zapisać je w tabelach, kolumnach i rekordach, dlatego dobrze pasują do relacyjnych baz SQL czy nawet do Excela. Przykładem mogą być dane transakcyjne, listy klientów, stany magazynowe albo wyniki sprzedaży.

Dane nieustrukturyzowane

Znacznie większym wyzwaniem są dane nieustrukturyzowane (niestrukturalne). Nie mają one sztywnego schematu, więc trudniej je zamknąć w klasycznej tabeli. To między innymi teksty, obrazy, nagrania audio, wideo, wiadomości e-mail, posty z mediów społecznościowych czy logi systemowe. Często przyjmuje się, że właśnie ten typ stanowi większość zasobów Big Data – nawet około 80%. Również z tego powodu tak duże znaczenie mają obecnie analiza tekstu i analiza wideo.

Dane częściowo ustrukturyzowane

Pomiędzy nimi znajdują się dane częściowo ustrukturyzowane (półstrukturalne). Mają pewną wewnętrzną organizację, ale nie na tyle sztywną, by traktować je jak klasyczne dane tabelaryczne. Dobrym przykładem są pliki JSON, XML, logi aplikacyjne czy dane z formularzy online.

Dane strumieniowe i sensoryczne

We współczesnych systemach coraz większą rolę odgrywają też dane strumieniowe i dane sensoryczne. To właśnie one sprawiają, że Big Data jest dziś tak dynamiczne i tak mocno związane z analizą zdarzeń “tu i teraz”.

• Dane strumieniowe napływają w sposób ciągły, często w czasie rzeczywistym, np. z aplikacji, platform płatniczych czy systemów monitoringu.
• Dane sensoryczne natomiast pochodzą z czujników, urządzeń IoT, maszyn przemysłowych albo urządzeń wearable.

Jakie technologie i narzędzia służą do przetwarzania Big Data?

Samo zgromadzenie danych to dopiero początek. Żeby Big Data miało wartość, potrzebne są jeszcze odpowiednie technologie, które poradzą sobie z dużą skalą, różnorodnością formatów i szybkim napływem informacji. W praktyce oznacza to przetwarzanie rozproszone, elastyczne magazynowanie danych i narzędzia, które pozwalają analizować je szybciej niż klasyczne systemy.

Apache Hadoop i Apache Spark

Jednym z fundamentów Big Data pozostaje ekosystem Apache Hadoop. To zestaw narzędzi zaprojektowanych do pracy na dużych zbiorach danych w wielu maszynach jednocześnie. Ważną rolę odgrywa HDFS (Hadoop Distributed File System), czyli system plików rozkładający dane pomiędzy różne węzły klastra, oraz MapReduce, model obliczeń, który dzieli zadania na mniejsze części i przetwarza je równolegle.

Obok Hadoop bardzo ważny jest dziś również Apache Spark. W przeciwieństwie do klasycznego MapReduce stawia on mocniej na przetwarzanie w pamięci (in-memory), dzięki czemu wiele operacji wykonuje się szybciej. To szczególnie istotne w projektach, gdzie liczy się analiza interaktywna, praca na strumieniach danych albo uczenie modeli analitycznych.

NoSQL i obsługa danych nieustrukturyzowanych

Niestety, nie wszystko da się wygodnie zapisać w tabelach. Z pomocą przychodzi tutaj NoSQL, czyli podejście inne niż klasyczne relacyjne bazy danych. Bazy danych NoSQL dobrze radzą sobie z danymi nieustrukturyzowanymi i półstrukturalnymi, a także z bardzo dużą skalą zapisu i odczytu.

Do najczęściej przywoływanych przykładów należą MongoDB i Cassandra. MongoDB jest popularny przy pracy z dokumentami i elastycznym schematem danych, a Cassandra sprawdza się tam, gdzie liczy się wysoka dostępność i rozproszenie danych pomiędzy wieloma serwerami. Klasyczny SQL wciąż pozostaje ważny, ale w Big Data często działa obok narzędzi NoSQL, a nie zamiast nich.

Jeziora danych i hurtownie danych

W kontekście przechowywania danych często pojawiają się dwa pojęcia: jezioro danych (data lake) oraz hurtownia danych.

Hurtownia danych to ustrukturyzowane repozytorium, w którym dane są najpierw oczyszczane, transformowane i organizowane według z góry określonego schematu, a dopiero potem trafiają do systemu. Dobrze sprawdzają się w sytuacjach, gdzie pytania analityczne są z grubsza znane z góry (np. raporty sprzedażowe, finansowe, operacyjne). Dane są gotowe do użycia od razu po załadowaniu, ale elastyczność jest ograniczona.

Jezioro danych działa odwrotnie. Dane trafiają do systemu w surowej postaci – ustrukturyzowane, częściowo ustrukturyzowane i nieustrukturyzowane – bez narzuconego z góry schematu. Nakłada się go dopiero w momencie odczytu, zależnie od tego, do czego dane mają służyć. To zapewnia dużą elastyczność, ale wymaga większej dojrzałości analitycznej po stronie użytkownika. Co to znaczy? Bez dobrego zarządzania jezioro danych szybko zamienia się w tzw. bagno danych – zbiór plików, z którego nie da się już wydobyć niczego sensownego.

Chmura, integracja i automatyzacja analizy, machine learning

Coraz więcej środowisk Big Data działa dziś w modelu chmury obliczeniowej (cloud computing). Zapewnia ona skalowalność, której firmy potrzebują dziś tak bardzo przy rosnących wolumenach danych. Nie trzeba też od razu budować własnej infrastruktury – można dowolnie zwiększać moc obliczeniową i przestrzeń dysku.

Duże znaczenie mają wreszcie narzędzia do przesyłania i przygotowywania danych. Kafka jest często wykorzystywana do obsługi strumieni danych, a procesy ETL i ELT pomagają przenosić, porządkować i przekształcać dane pomiędzy systemami.

W warstwie analitycznej nadal królują Python i SQL, bo pozwalają zarówno przygotowywać dane, jak i budować modele analityczne. Coraz częściej dochodzi do tego także sztuczna inteligencja i uczenie maszynowe, które automatyzują wykrywanie wzorców i przyspieszają analizę.

Gdzie znajduje zastosowanie analityka Big Data?

Analityka Big Data znajduje zastosowanie wszędzie tam, gdzie dane napływają szybko, w dużej skali i z wielu źródeł jednocześnie. Dotyczy to dzisiaj już nie tylko biznesu cyfrowego.

Medycyna i ochrona zdrowia

W sektorze zdrowia Big Data wspiera diagnostykę medyczną, analizę wyników badań i ocenę ryzyka chorób. Duże znaczenie ma też analiza genomu, która pozwala lepiej rozumieć zależności genetyczne i dobierać bardziej precyzyjne terapie. Do tego dochodzą wearables, czyli urządzenia monitorujące aktywność, tętno czy sen, które dostarczają danych niemal w czasie rzeczywistym.

Finanse i bankowość

W finansach analityka danych pomaga w wykrywaniu oszustw, ocenie ryzyka i monitorowaniu nietypowych zachowań transakcyjnych. Jest też wykorzystywana w obszarach takich jak HFT (High-Frequency Trading), gdzie liczy się błyskawiczne przetwarzanie informacji i reakcja na zmiany rynkowe.

Logistyka, inteligentne miasta i fabryki

W transporcie Big Data wspiera planowanie dostaw, zarządzanie flotą i optymalizację procesów operacyjnych.

Na tej samej zasadzie działa koncepcja Smart City, w której dane z kamer, czujników, sygnalizacji i systemów miejskich pomagają lepiej zarządzać ruchem, energią czy bezpieczeństwem w miastach.

W tzw. obszarze Przemysłu 4.0 analityka Big Data wspiera automatyzację i nadzór nad produkcją. W praktyce oznacza to inteligentne fabryki, w których maszyny, sensory i systemy raportują dane bez przerwy, dzięki czemu możliwa jest konserwacja predykcyjna (przewidywanie awarii, zanim faktycznie do nich dojdzie).

Marketing i e-commerce

W marketingu i handlu internetowym Big Data napędza personalizację oferty, rekomendacje produktów i segmentację klientów. To właśnie na tej logice działają systemy rekomendacji znane z takich platform jak Netflix czy Spotify.

Jakie korzyści przynosi firmom wykorzystanie Big Data?

Najważniejsza korzyść z Big Data polega na tym, że firmy mogą podejmować decyzje na podstawie faktów i twardych danych, a nie intuicji (podejście data-driven). Zapewniają to narzędzia z obszaru Business Intelligence, a także czytelna wizualizacja danych i dashboardy, które porządkują najważniejsze wskaźniki. To przekłada się na szybsze reakcje, lepsze planowanie i większą kontrolę nad kosztami, a więc także na realną oszczędność czasu.

Równie ważne jest lepsze zrozumienie klientów. Analiza behawioralna pozwala sprawdzać, jak użytkownicy podejmują decyzje, a analiza churn pomaga wychwycić sygnały odejścia. Łatwiej stworzyć spersonalizowane oferty i produkty. Z kolei analiza predykcyjna, modele predykcyjne, analiza trendów i prognozowanie trendów wspierają planowanie przyszłości – od sprzedaży po zarządzanie ryzykiem.

Jakie wyzwania dotyczą bezpieczeństwa i prywatności danych?

W Big Data wyzwaniem nie jest tylko ilość informacji, ale też ich legalne, bezpieczne i etyczne wykorzystanie. Dokładniej rzecz biorąc:

Rosną wymagania związane z RODO (GDPR). Unia Europejska nakłada ścisłe zasady dotyczące tego, jak firmy zbierają, przechowują i wykorzystują dane użytkowników. Chodzi tu nie tylko o ochronę danych osobowych, ale też o prywatność danych, zgodność celu przetwarzania i przejrzystość wobec osób, których dane dotyczą.

Co do zasady, im większy zbiór danych, tym mniejsza jego odporność na incydenty z obszaru cyberbezpieczeństwa, więc zapewnienie odpowiedniego poziomu zabezpieczeń stanowi osobne wyzwanie.

Istotna pozostaje kwestia jakości danych i ich wiarygodności, bo błędne lub niepełne informacje prowadzą do błędnych analiz i złych decyzji.

Dochodzi do tego wreszcie etyka: nawet jeśli dane można przetwarzać formalnie zgodnie z prawem, to czy sposób, w jaki je wykorzystujemy, jest uczciwy i proporcjonalny wobec użytkownika?

Kim jest Data Scientist i jaką rolę odgrywa w procesie analizy?

Data Scientist to zawód, który łączy statystykę, programowanie i rozumienie biznesu, żeby zamieniać dane w użyteczne wnioski. Taka osoba zajmuje się m.in. eksploracją danych (data mining), szukaniem zależności, budowaniem modeli opartych o uczenie maszynowe (machine learning) oraz wykorzystywaniem rozwiązań z obszaru sztucznej inteligencji (AI). W praktyce właśnie na tym polega nauka o danych (data science): nie tylko na zbieraniu informacji, ale też na ich interpretacji, modelowaniu i przekładaniu wyników na decyzje.

W codziennej pracy Data Scientist korzysta z narzędzi takich jak Python, język R i SQL, a wyniki prezentuje często przez Tableau lub Power BI. Jego zadaniem jest zrozumieć dany problem i zaproponować model, który pomoże przewidywać zjawiska albo lepiej wspierać biznes.

Warto odróżnić tę rolę od innych specjalizacji z dziedziny danych. Analityk danych (data analyst) zwykle skupia się bardziej na raportowaniu, dashboardach i interpretacji bieżących wyników, a inżynier danych (data engineer) odpowiada przede wszystkim za infrastrukturę, przepływ danych i przygotowanie środowiska do analizy. Data Scientist stoi trochę pomiędzy nimi. Korzysta z gotowych danych, ale idzie też o krok dalej – buduje modele i szuka odpowiedzi na bardziej złożone pytania.

The post Big Data – co to jest i dlaczego ma dziś tak duże znaczenie? first appeared on Conversion.