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.

Branża: Odzież / e-commerce
Klient: Reserved / LPP S.A.
Strona: www.reserved.com

Punkt wyjścia

Reserved to flagowa marka LPP S.A. i jeden z największych polskich brandów odzieżowych. Sklep internetowy Reserved.com działał w środowisku dużej organizacji, w której rozwój e-commerce obejmował wiele marek, rynków i równoległych projektów.

Po stronie klienta priorytetem był szybki rozwój sprzedaży internetowej. Oznaczało to jednak duże obciążenie zespołów developerskich, UX-owych i e-commerce. W takiej sytuacji trudno było znaleźć przestrzeń na systematyczną optymalizację już istniejącego sklepu, mimo że nawet niewielkie usprawnienia mogły mieć istotne przełożenie na przychody.

Celem współpracy było szybkie wprowadzenie zmian, które mogły zwiększyć przychody, bez angażowania IT po stronie klienta i bez dodatkowych inwestycji w marketing.

Wyzwania

Najważniejszym wyzwaniem było pogodzenie tempa rozwoju dużej organizacji z potrzebą bieżącej optymalizacji istniejącego sklepu internetowego.

LPP rozwijało sprzedaż online wielu marek i na wielu rynkach. Większość zasobów była skierowana na duże projekty: nowe strony, wersje mobilne, aplikacje i ekspansję e-commerce. W praktyce oznaczało to, że testowanie drobniejszych zmian optymalizacyjnych mogło łatwo utknąć w kolejce IT.

Projekt musiał więc odpowiedzieć na kilka problemów jednocześnie:

• jak szybko testować zmiany w istniejącym sklepie,
• jak ograniczyć zależność od zespołu developerskiego,
• jak zweryfikować, które elementy komunikacji realnie wpływają na decyzje zakupowe,
• jak poprawić współczynnik konwersji bez zwiększania wydatków marketingowych,
• jak wyciągnąć wnioski możliwe do wykorzystania także w innych sklepach LPP.

Istotne było również to, że klient nie chciał wdrażać zmian „na intuicję”. Każda rekomendacja miała wynikać z danych i zostać sprawdzona w testach A/B lub testach wielowymiarowych.

Nasze podejście

Projekt został przeprowadzony w modelu optymalizacji e-commerce opartym na danych, szybkim projektowaniu, kodowaniu zmian po stronie Conversion i testach A/B.

Pojedynczy cykl optymalizacyjny trwał około 4 tygodni. Samo zakodowanie zmian zajmowało około tygodnia i odbywało się po stronie Conversion. Po stronie Reserved konieczne było jedynie wpięcie pojedynczej linijki skryptu. Dzięki temu testy mogły być uruchamiane bez ingerencji w kod źródłowy sklepu i bez obciążania działu IT.

Prace rozpoczęto od zebrania i analizy danych. Conversion przeprowadziło analizy ilościowe, jakościowe oraz badania użyteczności. Na tej podstawie powstały dziesiątki rekomendacji, które następnie zostały ocenione i spriorytetyzowane.

Najwyżej znalazły się zmiany o największym potencjale wpływu na współczynnik konwersji oraz relatywnie niskiej czasochłonności wdrożenia.

Hipotezy testowe

Pierwszy obszar testów dotyczył komunikacji USP, czyli odpowiedzi na pytanie użytkownika: dlaczego powinien kupić właśnie w Reserved, a nie u konkurencji.

Hipoteza 1: komunikacja USP na stronie głównej, kategorii i karcie produktu

 
Pierwsza hipoteza zakładała, że dodanie komunikacji USP na stronie głównej, stronie kategorii oraz karcie produktu podkreśli atuty Reserved i przekona większy odsetek użytkowników do zakupu.

Przed zmianą tylko strona kategorii zawierała częściową komunikację USP. Nie było jej na stronie głównej ani na kartach produktu.

W wersji testowej narracja została rozciągnięta przez kilka kluczowych punktów ścieżki zakupowej:

• na stronie głównej dodano elementy USP u góry strony,
• po najechaniu na element użytkownik otrzymywał dodatkowe informacje,
• na stronie kategorii USP pokazano na pierwszym kafelku,
• na karcie produktu powtórzono komunikaty pod przyciskiem CTA,
• przy produktach droższych niż 150 zł dodano informację o darmowej dostawie kurierem.

Hipoteza 2: komunikacja USP w koszyku

 
Druga hipoteza dotyczyła koszyka. Zakładano, że zmiana komunikacji USP w tym miejscu zwiększy odsetek użytkowników przechodzących do kolejnego kroku checkoutu.

Przed zmianą komunikaty w koszyku nie podkreślały wystarczająco jasno dwóch ważnych benefitów: darmowej dostawy do sklepów oraz darmowej dostawy kurierem dla zamówień powyżej 150 zł. Dodatkowo komunikaty były przedstawione hasłowo, bez wyjaśnienia.

W wersji testowej zmieniono komunikację po prawej stronie koszyka. Gdy wartość zamówienia przekraczała 150 zł, pojawiała się dodatkowa informacja o darmowej dostawie. Wszystkie wersje przygotowano dla desktopu, tabletu i mobile.

Iteracja po pierwszym teście

Pierwszy test nie przyniósł oczekiwanego wzrostu współczynnika konwersji. Średnia wartość zamówienia wzrosła o 2,19%, ale żadna z testowanych wersji nie dała istotnej statystycznie zmiany konwersji.

Ten wynik stał się podstawą do dalszej analizy. Zespół Conversion sprawdził, dlaczego zmiany nie zadziałały zgodnie z hipotezą. Analiza pokazała, że na współczynnik konwersji negatywnie wpływał zwiększony współczynnik odrzuceń na stronie głównej oraz stronach kategorii.

To oznaczało, że część zmian wdrożonych na tych stronach mogła przeszkadzać użytkownikom zamiast pomagać im w decyzji zakupowej.

Na potrzeby kolejnego testu przygotowano nowe warianty, zbudowane z różnych kombinacji wcześniejszych zmian. W części wersji usunięto zmiany ze strony głównej i kategorii, pozostawiając komunikację na karcie produktu oraz w koszyku.

Efekty

Drugi test przyniósł oczekiwany rezultat. Zwycięska wersja zawierała wyłącznie zmiany na karcie produktu oraz w koszyku. To właśnie ta kombinacja wygenerowała 4,6% wzrost współczynnika konwersji.

Projekt przyniósł kilka konkretnych efektów:

• 4,6% wzrost współczynnika konwersji,
• wzrost średniej wartości zamówienia o 2,19% w pierwszym teście,
• brak konieczności angażowania IT po stronie klienta,
• szybkie zakodowanie zmian po stronie Conversion,
• przetestowanie hipotez w dwóch cyklach w ciągu 8 tygodni,
• możliwość dalszego serwowania zwycięskiej wersji użytkownikom bez kodowania zmian „na sztywno” przez IT,
• wiedza możliwa do wykorzystania w innych sklepach LPP oraz w nowych projektach e-commerce.

Wyniki pokazały też, że nie każda komunikacja USP działa tak samo na każdym etapie ścieżki. Komunikaty na karcie produktu i w koszyku pomagały użytkownikom w podjęciu decyzji. Natomiast komunikacja na stronie głównej i stronie kategorii w testowanej formie bardziej przeszkadzała niż wspierała zakup.

Wnioski

Projekt pokazał, że warto komunikować użytkownikom powody, dla których powinni kupić właśnie w danym sklepie, ale sposób i miejsce tej komunikacji mają kluczowe znaczenie.

Najważniejsze wnioski:

• komunikacja USP powinna być konkretna i rozwinięta, a nie wyłącznie hasłowa,
• darmowa dostawa powinna być podkreślana przy produktach, które faktycznie do niej kwalifikują,
• karta produktu i koszyk są miejscami, w których komunikaty zakupowe mogą bezpośrednio wspierać decyzję,
• zmiany na stronie głównej i kategorii wymagają szczególnej ostrożności, bo mogą wpływać na współczynnik odrzuceń,
• nawet pozornie niewielkie zmiany komunikacyjne mogą istotnie wpłynąć na konwersję,
• testy A/B pozwalają uniknąć wdrażania zmian, które wyglądają dobrze, ale nie poprawiają wyników.

Opinia Reserved na temat przeprowadzonego projektu

Podsumowanie

Case study Reserved pokazuje, że optymalizacja konwersji w dużej organizacji nie musi wymagać długiego procesu wdrożeniowego ani angażowania zespołu IT. Dzięki Conversion możliwe było szybkie zaprojektowanie, zakodowanie i przetestowanie zmian, a następnie wykorzystanie zwycięskiej wersji bez konieczności trwałej ingerencji w kod sklepu.

Najważniejszy efekt to 4,6% wzrost współczynnika konwersji osiągnięty dzięki precyzyjnemu testowaniu komunikacji USP na karcie produktu i w koszyku.

The post Reserved – Jak pracuje nad optymalizacją współczynnika konwersji? 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.

Branża: Porównywarka cenowa
Klient: Ringier Axel Springer Polska sp. z o.o. (Warszawa, Polska)
Strona: www.skapiec.pl

Punkt wyjścia

Skąpiec.pl to jedna z największych porównywarek cenowych na polskim rynku. Serwis prezentuje miliony ofert i produktów, a miesięcznie odwiedza go blisko 4 miliony użytkowników. Przy takiej skali działania jakość danych oraz sprawność wdrażania nowych kodów śledzących miały bezpośredni wpływ na efektywność działań marketingowych i analitycznych.

Przed rozpoczęciem współpracy każda zmiana w kodzie strony wymagała zaangażowania działu IT. Nawet proste wdrożenia, takie jak śledzenie kliknięcia w przycisk, uruchomienie ankiety czy dodanie nowego kodu remarketingowego, trafiały do kolejki ticketów i mogły czekać na realizację tygodniami.

Celem współpracy było zwiększenie efektywności zbierania i analizy danych poprzez wdrożenie Google Tag Managera oraz uporządkowanie całego procesu zarządzania tagami.

Wyzwania

Najważniejszym wyzwaniem było odciążenie działu IT i umożliwienie szybszego wdrażania zmian analitycznych oraz marketingowych. Dotychczasowy model pracy powodował opóźnienia, a zespoły marketingowe i analityczne były w dużej mierze zależne od dostępności webmasterów.

Projekt był dodatkowo złożony ze względu na skalę serwisu. Skąpiec.pl posiadał już zaawansowaną konfigurację Google Analytics, rozbudowany system śledzenia oraz dużą liczbę kont i profili GA. Konieczne było więc nie tylko przeniesienie istniejących skryptów do Google Tag Managera, ale także uporządkowanie całego procesu zbierania danych.

Kluczowe wyzwania obejmowały:

• migrację rozbudowanej instalacji Google Analytics do Google Tag Managera,
• stworzenie skalowalnej warstwy danych (DataLayer),
• uporządkowanie wielu kont, profili i śledzonych elementów,
• zapewnienie wysokiej jakości i kompletności danych,
• ograniczenie zależności marketingu i analityki od działu IT,
• zachowanie ciągłości pomiaru w trakcie migracji.

Istotne było również zaprojektowanie rozwiązania przyszłościowego — takiego, które pozwoli w dowolnym momencie rozwijać śledzenie o nowe zdarzenia, skrypty i potrzeby biznesowe.

Nasze podejście

Prace rozpoczęliśmy od szczegółowego mapowania dotychczasowej konfiguracji Google Analytics. Zespół Conversion przeanalizował konta, profile oraz wszystkie elementy śledzone na stronie. Celem nie było samo przeniesienie istniejących kodów, ale ocena, które dane są naprawdę potrzebne i jak można wykorzystać je do tworzenia użytecznych analiz oraz rekomendacji.

Następnie przygotowaliśmy specyfikację DataLayer, czyli warstwy danych stanowiącej podstawę poprawnego wdrożenia Google Tag Managera. Gotowa specyfikacja została przekazana do zespołu IT Skąpiec.pl, który wdrożył ją w kodzie strony.

Kolejnym krokiem było stworzenie mechanizmów DataLayer.push, czyli sygnałów informujących GTM, że na stronie wydarzyła się konkretna akcja — np. kliknięcie przycisku lub przewinięcie strony. Dzięki wykorzystaniu zaawansowanych kodów JavaScript większość tych zmian została wdrożona bez angażowania IT po stronie Skąpiec.pl.

Aby ograniczyć ryzyko błędów, wdrożenie przeprowadzono etapowo. Conversion uruchomiło bliźniaczą instalację Google Analytics przez Google Tag Managera, opartą na osobnych kontach. Pozwoliło to porównać dane zbierane przez stare kody z danymi zbieranymi przez nową konfigurację GTM. Dzięki temu udało się zidentyfikować i poprawić błędy jeszcze przed finalnym przepięciem.

Ostateczne wdrożenie polegało na jednoczesnym wyłączeniu starych kodów przez IT i uruchomieniu nowych przez analityków Conversion. Proces był monitorowany w czasie rzeczywistym i trwał jeden dzień.

Efekty

Wdrożenie Google Tag Managera przyniosło Skąpiec.pl konkretne efekty organizacyjne, techniczne i analityczne:

• proces wdrożenia i migracji kodów trwał 6 tygodni,
• zaimplementowano 118 tagów, 96 makr i 38 reguł,
• przeniesiono m.in. skrypty Google Analytics, tagi Gemius Audience, remarketingowe AdWords oraz ankiety Qualaroo,
• odciążono dział IT,
• usprawniono pracę działu marketingu,
• przyspieszono wdrażanie nowych kodów i skryptów,
• poprawiono szybkość działania serwisu dzięki asynchronicznemu ładowaniu tagów,
• zapewniono wysoką jakość i kompletność danych,
• otwarto nowe możliwości analiz.

Szczególnie istotny był efekt praktyczny po szkoleniu zespołu. Już tydzień po wdrożeniu zespół Skąpiec.pl, przy niewielkim wsparciu Conversion, samodzielnie wdrożył kody remarketingowe nowej sieci reklamowej. Zmiana została uruchomiona następnego dnia od zgłoszenia z marketingu — podczas gdy wcześniej podobny proces przez IT trwałby ponad tydzień.

Opinia firmy Skąpiec.pl o zespole Conversion

Podsumowanie

Projekt dla serwisu Skąpiec.pl pokazuje, jak wdrożenie Google Tag Managera może uporządkować proces zbierania danych, odciążyć dział IT i zwiększyć efektywność działań marketingowych. Dzięki dobrze zaprojektowanemu DataLayerowi oraz skalowalnej konfiguracji GTM organizacja zyskała większą niezależność, szybsze wdrożenia i nowe możliwości analityczne.

The post Skąpiec.pl – Jak Skąpiec.pl usprawnił zbieranie danych dzięki Google Tag Managerowi? 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: Odzież sportowa
Klient: 4F (OTCF S.A)
Strona: www.4f.com.pl

Punkt wyjścia

4F to marka odzieży sportowej należąca do OTCF, działająca na wielu rynkach i rozwijająca sprzedaż online. Wraz z rozwojem sklepu internetowego pojawiła się potrzeba systematycznej optymalizacji konwersji oraz szybkiego testowania zmian wpływających na wyniki biznesowe.

Problemem okazały się ograniczone zasoby deweloperskie oraz duża liczba równoległych projektów, które utrudniały sprawne wdrażanie i testowanie nowych rozwiązań. W efekcie wiele pomysłów na rozwój sklepu nie mogło być realizowanych w oczekiwanym tempie.

Wyzwania

Najważniejsze wyzwania obejmowały:

• ograniczone możliwości szybkiego wdrażania zmian ze względu na obciążenie zespołu IT,
• brak możliwości sprawnego testowania hipotez optymalizacyjnych,
• konieczność poprawy współczynnika konwersji bez zwiększania budżetów marketingowych,
• potrzeba wsparcia eksperckiego w zakresie optymalizacji UX i decyzji zakupowych,
• konieczność działania w środowisku dużej organizacji, gdzie procesy są bardziej złożone.

Dodatkowym wyzwaniem było znalezienie obszaru o największym potencjale wzrostu – wbrew typowym przypadkom nie była to ścieżka zakupowa, lecz karta produktu.

Nasze podejście

Współpracę oparto na procesie, który umożliwia szybkie testowanie i wdrażanie zmian bez angażowania IT.

Każdy sprint optymalizacyjny obejmował:

• analizy ilościowe i jakościowe,
• przygotowanie rekomendacji i hipotez,
• projektowanie makiet i grafik,
• kodowanie zmian,
• testy A/B,
• analizę wyników.

Cały proces zamykał się w cyklu około 5 tygodni.

Wszystko zaczyna się od danych

Pierwszym etapem były analizy ilościowe i jakościowe, które pozwoliły zrozumieć zachowania użytkowników oraz zidentyfikować kluczowe problemy w procesie zakupowym. Wbrew typowym scenariuszom okazało się, że użytkownicy dobrze radzą sobie na etapie finalizacji zamówienia.

Problem pojawiał się wcześniej, zbyt mały odsetek użytkowników dodawał produkty do koszyka, co wskazywało na potencjał optymalizacji na poziomie karty produktu.

Hipotezy i testy

Na podstawie analiz przygotowano zestaw hipotez, które zostały przetestowane w ramach pierwszego sprintu.

Hipoteza główna

Zwiększenie przejrzystości karty produktu miało zwiększyć liczbę użytkowników przechodzących do koszyka. W wersji wyjściowej kluczowe informacje (cena, wybór rozmiaru, CTA) były rozproszone i trudne do przetworzenia. W wersji testowej zostały one uporządkowane i wizualnie wyróżnione, co poprawiło czytelność strony.

Hipotezy poboczne

Aby lepiej zrozumieć wpływ poszczególnych elementów, przygotowano również zestaw hipotez szczegółowych:

• Opinie o produkcie – sprawdzono, czy ich obecność i umiejscowienie wpływa na decyzje zakupowe użytkowników,
• Komunikacja promocji – testowano, czy pokazanie procentowej obniżki ceny zwiększy konwersję,
• Informacje o dostępności i dostawie – analizowano wpływ dodatkowych komunikatów (np. infoboksy, dostawa do sklepu),
• Elementy informacyjne na karcie produktu – weryfikowano, czy uproszczenie widoku (np. usunięcie zbędnych informacji) poprawi przejrzystość i konwersję.

Zmiany były wdrażane w różnych wariantach i testowane w ramach eksperymentów A/B, co pozwoliło precyzyjnie ocenić wpływ każdego elementu na zachowanie użytkowników.

Dzięki wykorzystaniu technologii Swiftswap cały proces kodowania trwał zaledwie kilka dni i nie wymagał angażowania zespołu IT po stronie klienta.

Efekty

Wdrożone działania przyniosły wymierne rezultaty:

• 8% wzrost współczynnika konwersji w jednym sprincie,
• skrócenie czasu wdrożeń do około 5 tygodni (od analizy do wyników),
• brak konieczności angażowania zespołu IT po stronie klienta,
• możliwość szybkiego testowania i iteracji kolejnych hipotez.

Dodatkowo uzyskano wiedzę na temat wpływu poszczególnych elementów UX na decyzje użytkowników – część hipotez została odrzucona, co pozwoliło uniknąć błędnych wdrożeń w przyszłości.

Podsumowanie

Case study 4F pokazuje, że optymalizacja konwersji w dużych organizacjach nie musi być blokowana przez ograniczenia IT. Dzięki pracy na danych, szybkim sprintom i odpowiedniej technologii możliwe jest systematyczne zwiększanie konwersji oraz przychodów bez zwiększania budżetów marketingowych.

The post 4F – 8% wzrost współczynnika konwersji w 5 tygodni 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.

Branża: E-commerce
Klient: Limango Polska (Wrocław, Polska)
Strona: www.limango.pl

Punkt wyjścia

Limango to internetowy klub zakupowy oraz outlet dla kobiet i młodych rodzin, oferujący produkty renomowanych marek nawet do 80% taniej. Dynamiczny rozwój biznesu oraz rosnąca liczba źródeł danych sprawiły, że kluczowe stało się uporządkowanie analityki i dostosowanie jej do potrzeb organizacji.

Celem współpracy była budowa analityki internetowej poprzez rozwój w trzech obszarach: narzędzi, procesów oraz kompetencji zespołu, tak aby dane mogły realnie wspierać decyzje biznesowe.

Wyzwania

Budowa analityki w Limango obejmowała pięć kluczowych obszarów, które bezpośrednio wpływały na jakość danych, tempo wdrożeń oraz zdolność organizacji do podejmowania decyzji w oparciu o dane.

1. Poprawność danych

 
Podstawą analiz są poprawne dane – bez nich nie jest możliwe wyciąganie trafnych wniosków. W Limango konieczne było przeprowadzenie kompleksowego audytu danych obejmującego cały proces zakupowy – od logowania, przez złożenie zamówienia, aż po jego realizację i dane finansowe.

Wymagało to współpracy wielu działów (IT, marketing, sourcing, logistyka, księgowość) oraz rewizji rozwiązań technologicznych i definicji danych. Już na tym etapie identyfikowano problemy, które później stały się impulsem do optymalizacji konwersji.

2. Niezależność analityki od IT

 
Każda zmiana w obszarze analityki wymagała zaangażowania działu IT. Nawet drobne wdrożenia trafiały do kolejki developmentu, co powodowało opóźnienia i brak elastyczności.

IT stawało się wąskim gardłem procesu, a utrzymanie kodów trackingowych w dynamicznym środowisku było coraz trudniejsze. Konieczne było uniezależnienie analityki od IT i przeniesienie części odpowiedzialności do zespołu analitycznego.

3. Usprawnienie procesu wdrożeń

 
Szybki rozwój firmy wymagał uporządkowania procesu wdrażania zmian. Projekty trafiające do IT nie zawsze były odpowiednio zdefiniowane i priorytetyzowane.

Wprowadzono rolę analityka biznesowego jako „filtra” pomysłów – osoby odpowiedzialnej za ocenę wpływu projektów na KPI oraz ich złożoności. Celem było zapewnienie, że każdy projekt jest zgodny z podejściem SMART i posiada jasno określone mierniki sukcesu.

4. Mierzenie efektów działań

 
Organizacja potrzebowała sposobu na rzetelne mierzenie efektów działań marketingowych i produktowych. Wyzwanie polegało na dostarczeniu danych w sposób użyteczny dla różnych interesariuszy – od zarządu po zespoły operacyjne – bez przeciążania ich nadmiarem informacji.

Konieczne było połączenie danych z Google Analytics z danymi sprzedażowymi oraz stworzenie dashboardów umożliwiających samodzielną analizę.

5. Spójność danych w środowisku wielodomenowym

 
Rozwój biznesu (m.in. uruchomienie outlet.limango.pl) wprowadził dodatkową złożoność analityczną. Brak śledzenia między domenami powodował utratę ciągłości danych oraz błędną atrybucję źródeł ruchu.

Konieczne było wdrożenie rozwiązań pozwalających analizować cały biznes jako jeden ekosystem, przy jednoczesnym zachowaniu możliwości analizy poszczególnych części.

Nasze podejście

Współpracę rozpoczęto od audytu obecnego stanu analityki oraz oceny dojrzałości organizacji przy użyciu modelu WAMM. Następnie przeprowadzono warsztaty KPI, które pozwoliły zdefiniować kluczowe wskaźniki biznesowe oraz przypisać odpowiedzialności w organizacji.

Równolegle wdrożono działania w trzech obszarach:

• narzędzia: audyt i konfiguracja Google Analytics oraz wdrożenie Google Tag Managera wraz z DataLayer,
• procesy: zaprojektowanie procesu ciągłej analizy danych (zbieranie danych → hipotezy → rekomendacje → wdrożenia),
• ludzie: wsparcie w budowie zespołu analitycznego oraz rozwój kompetencji w organizacji.

Dodatkowo wdrożono rozwiązania takie jak dashboardy managerskie, integracja danych z CRM oraz śledzenie międzydomenowe, które pozwoliły mierzyć biznes jako całość.

Efekty

Wdrożone działania przyniosły wymierne rezultaty:

• nawet 50% wzrost współczynnika konwersji w wybranych obszarach (np. dzięki optymalizacji porzuconych zamówień),
• zapewnienie wysokiej jakości, poprawności i kompletności danych,
• stworzenie samodzielnego działu analityki w organizacji,
• uniezależnienie analityki od działu IT dzięki wdrożeniu Google Tag Managera,
• usprawnienie procesów wdrożeniowych i generowanie oszczędności,
• uruchomienie ciągłego procesu mierzenia sukcesu dzięki dashboardom i integracji danych,
• możliwość reagowania na zmiany w biznesie dzięki pełnemu śledzeniu między domenami.

Opinia Limango na temat przeprowadzonego projektu

CEO Limango, Martin Solarski, podkreśla, że współpraca z Conversion nie tylko rozwinęła analitykę internetową, ale też zapoczątkowała zmiany w trzech kluczowych obszarach: narzędziach, procesach i ludziach.

Podsumowanie

Case study Limango pokazuje, że skuteczna analityka internetowa to połączenie narzędzi, procesów i kompetencji zespołu.

Dzięki uporządkowaniu danych, wdrożeniu odpowiednich rozwiązań oraz budowie kultury analitycznej organizacja może podejmować decyzje biznesowe w oparciu o wiarygodne dane i systematycznie zwiększać wyniki.

The post Limango – 50% wzrost współczynnika konwersji dzięki pracy na danych 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.