Wolniejsza strona internetowa nie zawsze oznacza jeden, łatwy do wskazania problem. Czasami opóźnienie pojawia się na początku ładowania, czasami podczas budowania zawartości, a czasami dopiero wtedy, gdy przeglądarka pobiera ostatnie elementy. Jeśli wszystkie te etapy sprowadzimy do jednej liczby, zobaczymy, że strona działa wolniej, ale nie dowiemy się, gdzie należy szukać przyczyny.

Przed takim wyzwaniem stanęło TME.

Globalny e-commerce, w którym wydajność ma znaczenie

TME jest jednym z największych globalnych dystrybutorów komponentów elektronicznych, elektrotechnicznych, automatyki przemysłowej i wyposażenia warsztatowego. Firma oferuje ponad 1,5 miliona produktów i obsługuje ponad 300 tysięcy klientów ze 150 krajów. Każdego dnia jej centra logistyczne wysyłają około 7 tysięcy paczek. (TME.eu)

Przy takiej skali sklep internetowy nie jest jedynie katalogiem produktów. To jedno z najważniejszych narzędzi sprzedaży, z którego korzystają klienci działający na różnych rynkach, urządzeniach i połączeniach internetowych.

Dlatego kiedy TME zauważyło dłuższy czas ładowania strony w jednym z regionów, zespół chciał dokładnie sprawdzić, co się dzieje. Standardowe narzędzia wykorzystywane przez deweloperów pomagały analizować techniczne działanie serwisu, ale brakowało szerszego obrazu.

TME potrzebowało danych, które pozwoliłyby nie tylko sprawdzić szybkość strony, lecz także połączyć ją z informacjami o użytkownikach i ich zachowaniach.

Jedna metryka mówiła, że jest problem. Nie mówiła jednak, gdzie

TME mierzyło już czas ładowania strony za pomocą jednej niestandardowej metryki. Pokazywała ona ogólny wynik, ale nie pozwalała zobaczyć, co działo się na poszczególnych etapach.

Można to porównać do pomiaru czasu podróży samochodem. Informacja, że przejazd zajął 60 minut, pozwala stwierdzić, że trwał dłużej niż zwykle. Nie pokazuje jednak, czy przyczyną był korek na początku trasy, roboty drogowe w połowie drogi czy problem ze znalezieniem miejsca parkingowego na końcu.

Podobnie działa ładowanie strony internetowej. Przeglądarka wykonuje po kolei wiele czynności: rozpoczyna pobieranie strony, odczytuje jej strukturę, przygotowuje zawartość do wyświetlenia i ładuje pozostałe zasoby. Dopiero obserwacja tych etapów osobno pozwala lepiej zrozumieć, gdzie pojawia się opóźnienie.

Google Analytics 4 nie jest narzędziem przeznaczonym do technicznego monitorowania wydajności serwisu. W standardowej konfiguracji nie zapisuje szczegółowych czasów poszczególnych etapów ładowania. Może jednak przechowywać takie informacje, jeśli zostaną one wcześniej odpowiednio zebrane i przesłane.

To właśnie postanowiliśmy wykorzystać.

Najważniejsza część projektu wydarzyła się przed wdrożeniem

Sama implementacja nie była skomplikowana. Najwięcej pracy wymagało ustalenie, które informacje będą naprawdę przydatne zespołowi TME.

Nie chodziło o zbieranie jak największej liczby parametrów. Więcej danych nie zawsze oznacza więcej wiedzy. Źle dobrane wskaźniki mogłyby stworzyć rozbudowany raport, który wygląda profesjonalnie, ale nie pomaga podejmować żadnych decyzji.

Przeanalizowaliśmy więc dostępne dane techniczne i wybraliśmy momenty ładowania strony, które najlepiej opisywały kolejne etapy tego procesu. Wśród nich znalazły się informacje dotyczące przetwarzania DOM, czyli struktury, którą przeglądarka tworzy na podstawie kodu strony, aby wiedzieć, jakie elementy i w jakiej kolejności powinna wyświetlić.

Przeglądarka rejestruje takie czasy automatycznie. Naszym zadaniem było odczytanie właściwych wartości i przekazanie ich dalej w formie zrozumiałej dla narzędzi analitycznych.

Od przeglądarki do czytelnego dashboardu

Nowe parametry wdrożyliśmy za pomocą Google Tag Managera. Dzięki temu nie było konieczne wprowadzanie zmian bezpośrednio w kodzie sklepu.

Google Tag Manager odczytywał informacje o kolejnych etapach ładowania strony i przesyłał je jako parametry zdarzeń do Google Analytics 4, króre zbierało i przechowywało te dane. Na podstawie tych parametrów TME utworzyło własne metryki w GA4, a następnie zbudowało dashboard w Data Studio (daw. Looker Studio).

Cały przepływ wyglądał następująco:

Google Tag Manager odczytywał i przekazywał dane do GA4 → Google Analytics 4 je zbierał i przechowywał → Data Studio przedstawiał je w czytelnej formie.

Dashboard trafił do zespołu odpowiedzialnego za wydajność serwisu. Zamiast jednego ogólnego wyniku pracownicy TME mogli teraz obserwować, jak zmieniały się czasy poszczególnych etapów ładowania.

Zamiast jednorazowej diagnozy powstał stały proces

Wcześniej zespół widział jedną metrykę opisującą całkowity czas ładowania strony. Po wdrożeniu zaczął gromadzić dane historyczne, podzielone na kolejne etapy procesu.

Pozwoliło to wprowadzać zmiany stopniowo i po każdej z nich sprawdzać, czy w danych pojawiła się poprawa. Zespół mógł ocenić nie tylko to, czy strona zaczęła ładować się szybciej, lecz także na którym etapie ładowania pojawiła się poprawa.

Dane z Google Analytics 4 dawały jeszcze jedną ważną możliwość: segmentację wyników. Czasy ładowania można było analizować w połączeniu z innymi informacjami dostępnymi w GA4, między innymi danymi o regionie oraz zachowaniach użytkowników.

Dzięki temu wydajność strony przestała być pojedynczym wynikiem technicznym. Stała się elementem szerszej analizy doświadczenia klientów korzystających z TME.eu.

Co zmieniło się z perspektywy biznesu?

W e-commerce wolniejsze działanie serwisu może oznaczać nie tylko gorsze doświadczenie użytkownika, lecz także utracone zamówienia i niższe przychody. Sam pomiar nie rozwiązuje problemu, ale pozwala zespołowi sprawdzić, które działania rzeczywiście przybliżają go do rozwiązania.

Nowy dashboard pozwala TME obserwować zmiany w czasie, porównywać poszczególne etapy ładowania i oceniać rezultaty kolejnych usprawnień.

Klient potwierdził, że zespół regularnie korzysta z przygotowanych danych.

Rezultatem projektu nie był więc jednorazowy raport ani kolejna metryka do obserwowania. Powstał stały proces pomiaru, który pomaga zespołowi odróżnić zmianę przynoszącą poprawę od takiej, która jedynie miała ją przynieść.

Bo w optymalizacji strony nie wystarczy wdrożyć zmianę. Trzeba jeszcze umieć sprawdzić, czy rzeczywiście zadziałała.

The post Od jednej liczby do pełnego obrazu. Jak TME rozbudowało pomiar wydajności serwisu? first appeared on Conversion.

Zapamiętaj: ROI mierzy relację zysku netto do kosztu inwestycji.
ROI = (zysk netto / koszt inwestycji) x 100%. Przykład: koszt 1000 zł, przychód 1500 zł, zysk netto 500 zł, ROI = 50%.

W skrócie

Co to jest ROI?
Zwrot z inwestycji (Return on Investment, ROI) to wskaźnik, który pokazuje relację wypracowanego zysku do poniesionego kosztu – dzięki temu da się sensownie porównywać projekty o różnej skali i budżecie.

Jak obliczyć ROI?
Do obliczeń potrzebne są dwie wartości: zysk netto oraz koszt inwestycji.
ROI = (Zysk Netto / Koszt Inwestycji) x 100%

Jaki jest prosty przykład ROI?
Jeśli inwestycja wynosi 1000 zł, przychód 1500 zł, a zysk netto 500 zł, wtedy ROI = (500 / 1000) x 100% = 50%.

Jak interpretować wynik ROI?
Dodatnia wartość oznacza, że inwestycja zarobiła ponad koszt, a ujemna – że wygenerowała stratę. O opłacalności rozstrzygają też alternatywa dla kapitału, ryzyko oraz to, czy w kalkulacji ujęto pełne koszty (np. roboczogodziny, utrzymanie, prowizje, amortyzację).

ROI vs ROAS – o co chodzi?
ROI odnosi zysk netto do całego kosztu inwestycji, a różnica między ROI a ROAS opisuje podejście, w którym ROAS mierzy zwrot z samych wydatków reklamowych i zwykle nie obejmuje pełnych kosztów operacyjnych.

Czego ROI nie pokazuje?
Klasyczne ROI nie uwzględnia czasu ani profilu ryzyka. Przy dłuższych projektach (np. IT, nieruchomości, modernizacja linii produkcyjnej) trzeba więc rozważyć wskaźniki dyskontowe oraz uwzględnienie wartości pieniądza w czasie.

Co to jest wskaźnik ROI i co dokładnie mierzy?

Zwrot z inwestycji (Return on Investment, ROI) to wskaźnik finansowy, który mierzy relację zysku netto do kosztu inwestycji. Skrót ROI bywa używany w raportach i budżetach bez wyjaśnienia, a jego prostota kusi, żeby porównywać projekty o zupełnie różnej skali.

To działa, o ile identycznie zdefiniowane są koszty i to, co trafia do wyniku jako zysk – w ujęciu zarządczym ROI odpowiada na pytanie, czy opłacalność inwestycji jest wystarczająca z perspektywy dostawców kapitału. Im wyższy wynik, tym większa efektywność inwestycji, rozumiana jako „ile zysku przypada na każdą złotówkę wydaną na projekt”. Mechanizm działa także przy inicjatywach operacyjnych i wzrostowych. Warunek jest jeden: nie mieszać przychodu z marżą i nie pomijać kosztów, bez których wynik by nie powstał.

• Marketing: Rozliczanie budżetów na kampanie online i działania performance.

• IT: Ocena wdrożeń CRM/ERP oraz automatyzacji procesów.

• Nieruchomości: Porównanie wariantów zakupu, remontu i najmu.

Jak obliczyć ROI i jaki wzór zastosować?

ROI liczy się przez zestawienie zysku netto z tym, ile wyniósł koszt inwestycji. Wynik pokazuje, jaki procent „oddaje” projekt względem wydatków. W tej logice zysk netto oznacza przychód pomniejszony o koszty konieczne do jego uzyskania.

Koszt inwestycji powinien obejmować pełne nakłady – nie tylko faktury „na start”, lecz także wdrożenie, licencje, roboczogodziny i utrzymanie, a czasem prowizje czy amortyzację – bo gdy te pozycje rozmywają się po różnych kontach i budżetach, w estymacji znikają, ROI robi się zgrabne, ale opisuje projekt, którego nikt realnie nie finansuje. Złe założenia robią największą krzywdę, nawet gdy sama arytmetyka jest prosta.

Obliczenia najwygodniej prowadzić w Excel albo innym arkuszu kalkulacyjnym, bo w arkuszu łatwo rozdzielić przychody i koszty na wiersze. Później da się zmieniać założenia bez przebudowy modelu, np. przy scenariuszach dla różnych kanałów sprzedaży, a w najprostszych przypadkach wystarczy kalkulator ROI online. Warunek to jasny opis tego, co rozumie przez koszty, a co przez zysk.

Jak interpretować wynik ROI i kiedy inwestycja jest opłacalna?

ROI to procentowa stopa zwrotu, która pokazuje, czy projekt wypracował zwrot z inwestycji ponad poniesiony koszt. Dodatni ROI oznacza zysk, ujemny ROI stratę, a wynik bliski zera wyznacza praktyczny próg rentowności.

W najbardziej uproszczonym ujęciu decyzja jest „tak/nie”: inwestycja jest opłacalna, gdy ROI > 0. W finansach korporacyjnych częściej stosuje się twardsze kryterium: ROI > WACC. Średni ważony koszt kapitału (Weighted Average Cost of Capital, WACC) opisuje minimalną stopę oczekiwaną przez dawców kapitału. To kryterium porządkuje portfel projektów w firmie: dwa pomysły mogą generować podobny zysk operacyjny, a jednocześnie wymagać innego kapitału obrotowego lub finansowania, co finalnie obniża ich rentowność kapitału.

Pytanie „jaki jest dobry ROI?” nie ma jednej odpowiedzi; próg zależy od ryzyka, cyklu branżowego i alternatyw, które można sfinansować w tym samym czasie. W praktyce pomocne są benchmarki branżowe oraz odniesienia rynkowe – historycznie S&P 500 bywa przywoływany jako punkt odniesienia dla rocznej stopy zwrotu. Długoterminowe dane publikuje S&P Dow Jones Indices, a w uproszczeniu często mówi się o poziomie rzędu 10%. Wynik zauważalnie poniżej takiej „poprzeczki” nie musi oznaczać błędu w kalkulacji. Utrudnia jednak obronę tezy o sukcesie finansowym przy ograniczonym kapitale.

Czym różni się ROI od wskaźnika ROAS?

ROI i ROAS opisują różne poziomy decyzji. Pierwszy odpowiada za opłacalność całej inwestycji, drugi za skuteczność samych wydatków reklamowych, a ROAS (Return on Ad Spend, ROAS) jest liczony jako relacja przychodu do kosztu reklamy, bez wchodzenia w marże i koszty „po drodze”. Taki skrót jest wygodny, ale nie przesądza o rentowności.

Różnica staje się widoczna, gdy przychód rośnie, a marża topnieje. ROI uwzględnia zysk netto i pełny zestaw obciążeń: marżę zysku, koszty operacyjne, rabaty, zwroty, obsługę płatności czy logistykę. Dlatego może spaść nawet wtedy, gdy w panelu reklamowym świeci „ładny” ROAS. W marketingu internetowym oba wskaźniki często działają równolegle. W Google Ads ROAS da się odczytać bezpośrednio (wartość konwersji/koszt). ROI zwykle wymaga spięcia danych sprzedażowych i kosztowych z CRM lub ERP.

Jak analizować ROI w marketingu i projektach inwestycyjnych?

ROI nabiera sensu dopiero wtedy, gdy zostaje połączone z konkretnym źródłem wartości: przychodem, oszczędnością kosztu albo mierzalną poprawą produktywności.

W marketingu internetowym punktem startu jest konwersja. Sama sprzedaż bywa jednak niewystarczająca, gdy koszyk jest „rozciągnięty” w czasie. W e-commerce ROI często zestawia się z CPA (Cost Per Acquisition, CPA) oraz LTV (Lifetime Value, LTV).

Kampania może wyglądać słabo w pierwszym miesiącu, a mimo to dowozić marżę w horyzoncie retencji. Do przypisania efektu potrzebne są dane z Google Analytics 4 (GA4) i spójne tagowanie UTM – inaczej koszty z platform reklamowych nie sklejają się z przychodem w tych samych raportach, a model atrybucji oraz okno konwersji potrafią przestawić obraz kanałów w lejku, przez co ROI staje się liczbą „z prezentacji”.

• Projekty IT: ROI wynika z redukcji roboczogodzin, mniejszej liczby błędów i krótszego czasu obsługi; automatyzacja procesów jest policzalna, jeśli istnieje punkt odniesienia z systemów ERP/CRM.

• Szkolenia pracownicze: Zwrot opiera się na wzroście wydajności lub jakości i wymaga wskaźników operacyjnych; znaczenie ma m.in. czas realizacji zlecenia, poziom reklamacji oraz kontrola wpływu rotacji.

• Inwestycje w nieruchomości: Do kalkulacji wchodzi dochód z najmu i koszty utrzymania, a amortyzacja wpływa na wynik podatkowy, więc porównania „na oko” bywają mylące.

• Giełda: ROI jest proste arytmetycznie, ale interpretacja zależy od horyzontu, dywidend i kosztów transakcyjnych, które łatwo pominąć w ręcznych arkuszach.

W praktyce monitoring opiera się o narzędzia analityczne – dashboardy w Looker Studio, raporty w GA4, dane kosztowe z API platform i kontrolę jakości zdarzeń – a w projektach z komponentem społecznym bywa uzupełniany o społeczny zwrot z inwestycji, gdy finansowy efekt nie opisuje pełnej korzyści.

Czy wskaźnik ROI uwzględnia czynnik czasu i ryzyko?

ROI opisuje zwrot z inwestycji jako relację zysku do poniesionego kosztu, ale sam w sobie nie uwzględnia czasu ani ryzyka. To istotne ograniczenie. Taki sam wynik może dotyczyć projektu dwuletniego i dziesięcioletniego, mimo że ich ekonomiczna „waga” jest zupełnie inna.

Wartość pieniądza w czasie sprawia, że ta sama kwota dziś i za kilka lat ma inną siłę nabywczą, a inflacja oraz czynniki makroekonomiczne – stopy procentowe, kursy walut i koszt finansowania – potrafią „zjeść” część nominalnego zysku.

ROI nie dyskontuje przepływów i nie rozróżnia sytuacji, w której zwrot pojawia się szybko, od tej, w której przychodzi późno. Przez to porównania projektów o innym tempie generowania efektów łatwo prowadzą do błędnych wniosków; drugą luką jest ryzyko inwestycyjne, którego wzór nie koryguje o prawdopodobieństwo nieosiągnięcia założeń czy opóźnienia wdrożenia. Bez osobnej analizy w obszarze zarządzania ryzykiem preferowane bywają scenariusze „na papierze”.

• Horyzont czasowy nie jest wbudowany w ROI, więc nie widać, jak długo kapitał pozostaje zamrożony.

• Zannualizowany ROI pomaga porównać różne okresy, bo przelicza wynik na ujęcie roczne, ale nadal nie zastępuje dyskontowania.

• Inflacja i koszty pieniądza nie są automatycznie odjęte, więc nominalny zwrot bywa zawyżony.

• Ryzyko inwestycyjne pozostaje poza wzorem, dlatego potrzebne są osobne założenia i scenariusze.

Jakie alternatywne wskaźniki rentowności warto znać?

Poza ROI w ocenie opłacalności inwestycji często wykorzystuje się wartość bieżącą netto (Net Present Value, NPV), wewnętrzną stopę zwrotu (Internal Rate of Return, IRR) oraz wskaźniki z obszaru analizy finansowej przedsiębiorstwa.

Wartość bieżąca netto porządkuje przepływy pieniężne w czasie, bo uwzględnia wartość pieniądza i koszt kapitału. W praktyce oznacza to dyskontowanie przyszłych wpływów i wydatków do „dzisiaj” – dzięki temu da się porównać projekty o różnych horyzontach oraz profilach przepływów, zamiast sprowadzać je do jednego procentu. IRR opisuje stopę dyskontową, przy której NPV spada do zera, dlatego bywa zestawiana z WACC w decyzjach inwestycyjnych. Okres zwrotu (Payback Period) pokazuje, kiedy inwestycja „oddaje” nakład, ale pomija przepływy po przekroczeniu progu. To potrafi zniekształcić obraz przy projektach o długim ogonie przychodów.

• SROI (Social Return on Investment, SROI) zamienia efekty społeczne na wartość pieniężną, co ułatwia wybór projektów ESG i programów publicznych.

• ROE (Return on Equity, ROE) mierzy efektywność wykorzystania kapitału własnego i szybko ujawnia wpływ struktury finansowania na wynik.

• ROA (Return on Assets, ROA) pokazuje, ile zysku generują aktywa, dlatego dobrze działa w porównaniach firm o podobnym modelu operacyjnym.

Jak skutecznie zwiększyć zwrot z inwestycji?

Podnoszenie ROI sprowadza się do dwóch ruchów: zmniejszenia „tarcia” kosztowego i zwiększenia wyniku biznesowego z tej samej alokacji zasobów. Najszybciej działa optymalizacja kosztów, ale tylko wtedy, gdy usuwa się koszty „szumu” – nadmiar narzędzi, duplikujące się działania i nieużywane licencje – a nie o wycinanie kompetencji krytycznych dla dowiezienia efektu. Rezultat rośnie też wtedy, gdy strategia marketingowa opiera się na mierzalnych hipotezach, a nie na „ładnych kreacjach” – wtedy wpływ kanału, oferty i procesu sprzedaży da się przypisać do wyniku finansowego.

Najczęściej zwrot poprawiają trzy dźwignie, które można prowadzić w cyklu tygodniowym, bez przebudowy całej organizacji.

• Podniesienie konwersji przez testy A/B w landing page, formularzu i sekwencji lead nurturing. Wygrywa wersja, która skraca drogę do decyzji i usuwa pola bez wartości kwalifikacyjnej.

• Automatyzacja z użyciem sztucznej inteligencji (Artificial Intelligence, AI) w obsłudze zapytań, segmentacji i scoringu. Efekt to mniej ręcznych przekazań, wyższa efektywność pracowników i stabilniejsza jakość odpowiedzi.

• Analiza danych i predykcja popytu w planowaniu. Budżet przesuwa się tam, gdzie model wskazuje rosnące prawdopodobieństwo sprzedaży, a alokacja budżetu przestaje być „historyczna”.

Dźwignia finansowa potrafi wzmocnić ROI, bo mniejszy udział kapitału własnego zwiększa stopę zwrotu z tej części. Ceną jest wyższe ryzyko płynności i większa wrażliwość na opóźnienia wpływów. Taka decyzja ma sens dopiero po stress-teście przepływów: jak zachowa się projekt przy spadku marży, wolniejszej sprzedaży i wyższym koszcie finansowania.

Najczęściej zadawane pytania (FAQ)

Co to znaczy ROI?

ROI to zwrot z inwestycji (Return on Investment, ROI) – wskaźnik pokazujący, jaki zysk netto generuje dany wydatek względem jego kosztu. Ułatwia porównywanie opłacalności kampanii, projektu IT albo zakupu aktywa. Wynik podaje się najczęściej w procentach.

Jak obliczyć ROI przykład?

Do obliczeń potrzebne są Zysk Netto i Koszt Inwestycji.
ROI = (Zysk Netto / Koszt Inwestycji) x 100%.
Jeśli inwestycja kosztuje 1000 zł, przynosi 1500 zł przychodu, a zysk netto = 500 zł, to ROI = 50%.

Jaki poziom ROI jest dobry?

Dobry ROI zależy od alternatyw i ryzyka – minimalnym punktem odniesienia bywa koszt kapitału oraz inne dostępne projekty. Dla inwestycji o podobnym profilu ryzyka „lepszy” będzie wynik wyższy przy tych samych zasobach, ale taki, który da się powtórzyć w czasie. Znaczenie ma też spójność założeń o kosztach i marży.

Jaka jest różnica między ROI a ROE?

ROI mierzy zwrot z konkretnej inwestycji lub działania (np. wdrożenia CRM), a ROE (Return on Equity, ROE) opisuje rentowność kapitału własnego całej firmy. ROI odnosi zysk do kosztu inwestycji, natomiast ROE – do kapitału właścicieli. Dlatego te wskaźniki nie są zamienne.

Jak liczymy ROE?

ROE liczy się jako relację zysku netto do kapitału własnego, zwykle w ujęciu rocznym: ROE = (Zysk Netto / Kapitał Własny) x 100%. Jeśli spółka ma 200 000 zł zysku netto i 1 000 000 zł kapitału własnego, to ROE = 20%. W analizie trzeba uważać na jednorazowe zdarzenia w wyniku netto.

Jakie są wskaźniki zwrotu z inwestycji?

Poza ROI często stosuje się ROAS (Return on Ad Spend, ROAS) w reklamie, NPV (Net Present Value, NPV) i IRR (Internal Rate of Return, IRR) w finansach inwestycyjnych oraz okres zwrotu w analizie płynności. Dobór zależy od tego, czy ważniejszy jest czas, ryzyko, czy czysta rentowność. W raportowaniu warto ustalić jeden zestaw KPI i trzymać definicje.

The post Czym jest wskaźnik ROI i jak go poprawnie obliczyć? first appeared on Conversion.

Zapamiętaj: Współczynnik klikalności (Click-Through Rate, CTR) to odsetek kliknięć względem liczby wyświetleń.

W skrócie

Czym jest CTR?
Współczynnik klikalności (Click-Through Rate, CTR) pokazuje, jaki odsetek osób kliknął dany element po tym, jak go zobaczył – najczęściej dotyczy wyników wyszukiwania, reklam, e-maili i postów w social media. To miara reakcji na komunikat.

Jak obliczyć CTR?
Stosuje się wzór: (liczba kliknięć / liczba wyświetleń) × 100%. Jeśli reklama ma 100 kliknięć i 1000 wyświetleń, CTR wynosi 10%.

Dlaczego CTR jest KPI?
W marketingu to KPI, które mówi, czy oferta i komunikat pasują do intencji odbiorcy, a w systemach reklamowych wpływa też na koszty, bo wyższa klikalność zwykle podnosi trafność i może poprawiać wynik jakości. Niski CTR bywa sygnałem słabego dopasowania słów kluczowych, kreacji albo miejsca emisji.

Jaki CTR jest „dobry”?
Nie istnieje jedna liczba sensowna dla każdego kanału i branży, bo inaczej zachowuje się wynik organiczny, reklama w wyszukiwarce i baner display. Najbezpieczniej porównywać CTR w czasie oraz w segmentach: urządzenie, typ kampanii, pozycja, grupa odbiorców.

Jak zwiększyć CTR?
Najczęściej działa doprecyzowanie obietnicy w tytule, spójność komunikatu z landing page oraz testy wariantów kreacji w Google Ads i metadanych w Search Console. Pomagają też rozszerzenia, lepsze dopasowanie zapytań i ograniczenie emisji na placements o niskiej jakości.

Co jeszcze oznacza skrót CTR poza marketingiem?
W finansach w USA CTR to Currency Transaction Report – raport składany dla transakcji gotówkowych przekraczających 10 000 USD (wymóg FinCEN, U.S. Department of the Treasury), a w lotnictwie CTR bywa używane jako Control Zone, czyli kontrolowana strefa przestrzeni powietrznej wokół lotniska.

Co to jest CTR (Click-Through Rate) w marketingu internetowym?

CTR to procentowy stosunek liczby kliknięć do liczby wyświetleń danego komunikatu online.

To parametr podstawowy, bo szybko pokazuje, czy przekaz „łapie” odbiorcę w miejscu emisji. W marketingu internetowym CTR działa jak szybki wskaźnik efektywności. Dotyczy reklam w wyszukiwarce, banerów, wyników organicznych oraz linków w newsletterach.

W SEO opisuje relację między widocznością w SERP a ruchem, który faktycznie trafia na stronę. W kampaniach płatnych mierzy, czy kreacja i oferta potrafią wywołać kliknięcie. W e-mailach liczą się kliknięcia w linki w treści, niezależnie od tego, czy odbiorca ostatecznie kupi.

Interpretacja zawsze wymaga kontekstu – klik w reklamę „Kup teraz” ma inny ciężar niż klik w poradnik, choć oba zdarzenia wyglądają podobnie w raporcie. Najczęściej CTR opisuje atrakcyjność tytułu, opisu i grafiki. Dotyczy też CTA (Call to Action), czyli elementów, które widać przed wejściem na stronę. Gdy wynik siada, źródło problemu zwykle leży w rozjeździe z intencją albo w obietnicy, która nie wnosi konkretu.

Jak obliczyć współczynnik klikalności?

CTR oblicza się, dzieląc liczbę kliknięć przez liczbę wyświetleń, a wynik mnożąc przez 100%.

Wzór: CTR = (liczba kliknięć / liczba wyświetleń) × 100%.

Sam wzór się nie zmienia, ale w praktyce najłatwiej pomylić mianownik. W wyszukiwarce wyświetlenie oznacza pojawienie się wyniku lub reklamy na liście. W kampaniach display wyświetlenia obejmują ekspozycje w sieci reklamowej. Porównania mają sens tylko w ramach tego samego typu raportu i tego samego okresu.

Ręczne liczenie rzadko bywa potrzebne. Narzędzia analityczne liczą CTR automatycznie – m.in. Google Search Console dla wyników organicznych oraz kampanie Google Ads dla reklam, z podziałem na słowa kluczowe, kreacje i urządzenia.

Dlaczego CTR jest ważnym wskaźnikiem efektywności (KPI)?

CTR jest KPI, bo pokazuje, czy ekspozycja reklamy lub wyniku faktycznie zamienia się w ruch. Pozwala rozdzielić problem z zasięgiem od problemu z komunikatem. To szybki sygnał diagnostyczny.

W Google Ads wysoki CTR zwykle wspiera Wynik Jakości, a ten wpływa na Ranking reklamy i finalny koszt kliknięcia (Cost Per Click, CPC) – jeśli system przewiduje wyższą szansę kliknięcia, reklama może dostać lepszą pozycję przy podobnej stawce albo utrzymać miejsce przy niższym koszcie, a budżet rzadziej ucieka w emisje, które nie uruchamiają intencji wejścia.

W SEO CTR z wyników wyszukiwania jest sygnałem zachowania w SERP. Google nie opisuje go jako bezpośredniego czynnika rankingowego, ale niska klikalność często idzie w parze z niedopasowanym tytułem, opisem lub intencją zapytania. W takim układzie poprawa snippetu i optymalizacja SEO pod realne zapytania podnosi jakość wejść, a nie tylko wolumen.

Najbardziej „biznesowy” wymiar CTR widać w rachunku zwrotu z inwestycji (Return on Investment, ROI) – gdy kliknięcia tanieją, a ekspozycja rośnie dzięki lepszej pozycji, ten sam budżet może dostarczyć więcej sesji do lejka sprzedażowego, pod warunkiem że strona dowozi kolejny etap.

Jaki współczynnik klikalności jest uznawany za dobry?

Dobry CTR nie ma jednej wartości, bo zależy od kanału, intencji zapytania i miejsca w SERP. Ten sam wynik potrafi znaczyć coś innego w e-commerce i w SaaS, bo zmienia się konkurencja, układ wyników i udział elementów takich jak mapy, wideo czy boksy produktowe – a to one przejmują uwagę, zanim użytkownik zobaczy klasyczny tytuł i opis.

W SEO duże znaczenie ma typ frazy: frazy brandowe zwykle zbierają kliknięcia łatwiej niż zapytania generyczne, a w ruchu informacyjnym częściej wygrywa precyzja obietnicy i zgodność z intencją. W kampaniach płatnych dochodzi wpływ kreacji, stawek i dopasowań słów kluczowych, dlatego ocenę lepiej prowadzić w segmentach niż na jednym uśrednieniu; wtedy wynik nie miesza różnych intencji i formatów.

Wideo i formaty rich media potrafią przyciągnąć wzrok, ale wynik trzeba czytać razem z celem kampanii, modelem atrybucji i jakością ruchu. Sam „ładny” CTR nie rozwiązuje tematu.

Jak zwiększyć CTR w wynikach wyszukiwania i reklamach?

CTR rośnie wtedy, gdy komunikat w SERP lub reklamie odpowiada na intencję i składa konkretną obietnicę, bez ogólników.

W SEO pierwszą dźwignią jest meta title – powinien zawierać główną frazę i wyróżnik, np. checklistę, cennik albo porównanie, a nie tylko nazwę firmy, a meta description nie podnosi pozycji, lecz potrafi przesunąć decyzję o kliknięciu, gdy streszcza ofertę językiem problemu i ogranicza ryzyko, np. „bez umowy” albo „wdrożenie w 7 dni”.

Widoczność mogą wzmacniać rich snippets – oceny, FAQ, cena, dostępność – pod warunkiem poprawnych danych strukturalnych w Schema.org. Jeśli dane są błędne, Google może je pominąć mimo wdrożenia.

W kampaniach w wyszukiwarce ciężar przesuwa się na nagłówek oraz spójność zapytania z landing page. Zbyt szerokie targetowanie generuje wyświetlenia „obok tematu”, więc CTR spada, a w skrajnych przypadkach rośnie koszt kliknięcia. Przejście na dopasowanie ścisłe dla fraz o wysokiej intencji porządkuje ruch, choć ogranicza skalę.

Znaczenie mają też rozszerzenia reklam – linki do podstron, objaśnienia, promocje – bo zwiększają powierzchnię reklamy i dają dodatkowe powody do kliknięcia, bez zmiany samej stawki.

• Testy A/B nagłówków: Jedna zmienna na raz, np. korzyść kontra liczba kontra branża.

• CTA (Call to Action) dopasowane do etapu: „Sprawdź demo” działa inaczej niż „Poznaj cennik”.

• Personalizacja przekazu w treści reklamy: Branża, rola, lokalizacja, problem operacyjny.

• Kontrola zapytań i wykluczenia: Gdy ruch jest informacyjny, a oferta sprzedażowa.

Jakie są najczęstsze przyczyny niskiego CTR?

Niski CTR zwykle bierze się z rozjazdu między intencją użytkownika a tym, co obiecuje reklama, oraz z błędów w doborze odbiorców. Jeśli kreacja mówi o promocji, a zapytanie dotyczy porównania specyfikacji, spada trafność reklamy i kliknięcie przestaje być naturalnym kolejnym krokiem. Problem pogłębia słabe copy. Nagłówki bez konkretu, obietnice typu „najlepsza jakość” i brak wyróżnika sprawiają, że nawet przy dobrych słowach kluczowych komunikat przegrywa z konkurencją w tej samej aukcji.

W kampaniach displayowych dochodzi ślepota banerowa – odbiorcy filtrują reklamę banerową jak element interfejsu, szczególnie gdy format, layout i animacja wyglądają „jak zawsze”. Znaczenie ma też częstotliwość emisji. Gdy jest wysoka, kreacja szybko się opatrzy i klikalność spada.

W wyszukiwarce częstym źródłem problemu bywa dopasowanie zapytań. Ustawione zbyt szeroko słowa kluczowe, brak kontroli raportu wyszukiwanych haseł i niedopracowane frazy wykluczające potrafią kierować reklamę na ruch, który od początku nie ma zamiaru kupować.

• Niedopasowane intencje wyszukiwania: Reklama sprzedażowa na zapytania informacyjne lub porównawcze.

• Słaba jakość copy: Brak konkretu w nagłówku, niejasna oferta, powtarzalne obietnice bez dowodu.

• Błędne targetowanie: Źle zdefiniowana grupa docelowa, nietrafione segmenty, przypadkowe miejsca emisji.

• Brak fraz wykluczających: Wejścia z zapytań typu „darmowe”, „opinie”, „jak działa”, gdy celem jest lead lub sprzedaż.

Czym różni się CTR od CTOR i współczynnika konwersji?

CTR mierzy reakcję na ekspozycję, Wskaźnik kliknięć do otwarć (Click-To-Open Rate, CTOR) – reakcję po otwarciu wiadomości, a współczynnik konwersji dopiero efekt biznesowy po kliknięciu. Te trzy miary opisują różne etapy lejka. Nie da się ich sensownie podmieniać.

W ujęciu kanałowym CTR odpowiada na pytanie, ile osób kliknęło względem liczby wyświetleń. Dlatego bywa traktowany jako wskaźnik dopasowania komunikatu do odbiorcy. W e-mail marketingu dochodzi etap otwarcia, więc sama klikalność wymaga innej perspektywy. CTOR liczy relację kliknięć do otwarć i rozdziela problem tematu oraz preheadera od problemu oferty. Przy niskich otwarciach potrafi wyglądać dobrze, mimo że CTR pozostaje słaby.

Jeszcze inną informację niesie współczynnik konwersji, bo łączy kliknięcie z akcją na stronie: zakupem, wysłaniem formularza, rezerwacją demo lub pobraniem pliku. Wysoki CTR nie gwarantuje sprzedaży. Blokadą często staje się landing page – zbyt długi formularz, rozjazd obietnicy między kreacją i stroną albo nieczytelne CTA, co podnosi współczynnik odrzuceń i urywa ścieżkę przed konwersją.

Co oznacza skrót CTR w finansach, lotnictwie i innych dziedzinach?

Skrót CTR poza marketingiem opisuje kilka różnych pojęć. Bez kontekstu branżowego łatwo je pomylić.

Finanse: Currency Transaction Report

W bankowości i compliance Currency Transaction Report (CTR) to raport o transakcjach gotówkowych składany przy operacjach gotówkowych przekraczających 10 000 USD w USA – mechanizm wykorzystywany w reżimie przeciwdziałania praniu brudnych pieniędzy, aby instytucje finansowe rejestrowały duże przepływy i udostępniały je organom nadzoru. Raport nie jest „donosem” na klienta. Stanowi ślad audytowy, który pomaga wykrywać strukturyzowanie wpłat i wypłat.

Lotnictwo: Controlled Zone

W lotnictwie Controlled Zone bywa skrótem dla strefy kontrolowanej lotniska, czyli wycinka przestrzeni powietrznej wokół portu, w którym obowiązują określone zasady zgłaszania pozycji i separacji – dzięki temu kontrola ruchu lotniczego porządkuje podejścia, odloty oraz ruch w rejonie kręgu nadlotniskowego.

Inne znaczenia CTR

• Powiat toruński: Wyróżnik „CTR” na polskich tablicach rejestracyjnych.

• Medycyna: Clinical Trials Regulation – skrót używany przy regulacjach dotyczących badań klinicznych w UE.

• Kryptografia: tryb licznikowy (Counter Mode) w szyfrowaniu, znany jako CTR mode, stosowany ze szyframi blokowymi.

Najczęściej zadawane pytania (FAQ)

Co to znaczy CTR?

CTR (Click-Through Rate) to współczynnik klikalności, czyli odsetek wyświetleń, które zakończyły się kliknięciem. W marketingu internetowym opisuje reakcję na reklamę, wynik organiczny, miniaturę wideo albo link w newsletterze. Nie mówi o sprzedaży. Pokazuje, czy komunikat trafił w intencję odbiorcy.

Jak obliczyć wskaźnik CTR?

Wzór jest prosty: CTR = (liczba kliknięć / liczba wyświetleń) × 100%. Jeśli kreacja ma 80 kliknięć i 4000 wyświetleń, CTR wynosi 2%. Do liczenia potrzebne są dwie liczby z tego samego zakresu czasu i tego samego miejsca emisji.

Jaki wynik CTR jest dobry?

Dobry CTR to taki, który rośnie względem wcześniejszego okresu przy niepogorszonych kosztach i jakości ruchu. Porównania mają sens dopiero po rozdzieleniu kanałów i formatów – wynik z kampanii w wyszukiwarce działa inaczej niż display, social czy e-mail, a na poziom wpływa też dopasowanie słów kluczowych, kreacja i pozycja emisji. Ocenia się trend, a nie „jedną właściwą” wartość.

Co to jest strefa CTR?

W lotnictwie CTR oznacza strefę kontrolowaną lotniska (Control Zone), czyli przestrzeń powietrzną wokół portu, w której ruch jest nadzorowany przez kontrolę zbliżania lub wieżę. Wlot i wylot mogą wymagać zgody, utrzymywania łączności radiowej oraz stosowania procedur dla danego lotniska. To znaczenie nie ma związku z marketingiem ani wskaźnikami kampanii.

Jak obliczyć koszt CPM?

CPM (Cost Per Mille) to koszt 1000 wyświetleń: CPM = (koszt kampanii / liczba wyświetleń) × 1000. Przy koszcie 200 zł i 50 000 wyświetleń CPM wynosi 4 zł. CPM mierzy cenę ekspozycji, a nie klikalność, więc nie zastępuje CTR.

The post Co to jest CTR (Click-Through Rate) i jakie ma znaczenie w marketingu oraz innych dziedzinach? first appeared on Conversion.

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

Punkt wyjścia

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Sprawdzaliśmy między innymi:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Co zmieniło się biznesowo?

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

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

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

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

Podsumowanie

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

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

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

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

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

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

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

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

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

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

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

Sytuacja TME.eu

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

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

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

Problem biznesowy

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

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

To utrudniało interpretację customer journey.

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

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

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

Co zrobiliśmy?

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

Sprawdziliśmy między innymi:

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

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

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

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

Technikalia

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

1. Losowość

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

2. Kompaktowość

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

3. Możliwość sortowania po czasie utworzenia

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

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

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

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

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

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

Wyzwania po drodze

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

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

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

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

Co się zmieniło po wdrożeniu?

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

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

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

Nowe dane pomagają trafniej odpowiadać na pytania:

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

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

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

Wartość biznesowa

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

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

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

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

Przykład przed i po

Przed wdrożeniem

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

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

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

Po wdrożeniu

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

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

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

Podsumowanie

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

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

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

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

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

Marketing i analityka – wyzwania

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

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

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

Metodyka KPI Tree – co to jest?

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

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

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

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

4 kroki metodyki KPI Tree

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

Krok 1: Definicja głównych KPI biznesowych

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

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

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

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

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

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

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

Krok 2: Mapowanie Customer Journey i touchpointów

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

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

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

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

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

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

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

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

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

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

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

KPI Tree w praktyce – case study

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

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

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

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

Podsumowanie

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

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

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

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

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

Czym jest DataMate?

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

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

Jak działa DataMate w praktyce?

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

Przykładowe wykorzystanie asystenta

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

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

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

Jak uzyskać dostęp do narzędzia?

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

1. Wejdź na stronę datamate.pl.

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

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

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

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

Podsumowanie

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

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

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

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

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

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

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

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

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

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

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

• Head of Technology
• Digital Marketing Supervisorem

Punkt wyjścia: potrzeba lepszego zrozumienia koszyka

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

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

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

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

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

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

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

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

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

Dlaczego to miało znaczenie?

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

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

Wpływ był wielowymiarowy.

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

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

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

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

Nasze podejście

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

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

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

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

Co zmieniło się po analizie?

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

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

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

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

Punkt wyjścia

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

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

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

Wyzwanie: nowa konwersja, stary problem

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

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

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

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

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

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

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

Po naszej stronie zakres prac obejmował:

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

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

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

Klasyczny model vs. nasze podejście

Klasyczny model:

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

Nasze podejście:

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

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

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

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

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

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

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

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

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

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

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

Czego dowiesz się z tego wywiadu:

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

Proces modelowania i znaczenie jakości danych

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

Zastosowanie MMM: Performance a budowanie marki

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

Podsumowanie: Główne wnioski z rozmowy

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

Wprowadzenie do MMM i optymalizacji budżetów

Mariusz Michalczuk: Cześć, witam Cię w kolejnym odcinku podcastu z serii Date with Data Talks, czyli podcastu od praktyków danych do praktyków wykorzystania danych i vice versa. Dzisiaj moim i Twoim gościem jest Karol Dulęba. Cześć Karol.

Karol Dulęba: Cześć.

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

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

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

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

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

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

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

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

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

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

Proces modelowania i znaczenie jakości danych

Zmienne kontrolowane i czynniki zewnętrzne

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

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

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

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

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

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

Weryfikacja anomalii i sanity check

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

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

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

\

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Karol Dulęba: Dzięki bardzo.

Podsumowanie: Główne wnioski z rozmowy

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

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

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

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

Czego dowiesz się z tego wywiadu:

Ewolucja technologiczna: od korporacji do zwinnych środowisk

Wyzwania logistyczne w e-commerce a rozwój marketingu

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

Zastosowanie agentów AI w zwinnym rozwoju produktu

Podsumowanie: Główne wnioski z rozmowy

Ewolucja technologiczna: od korporacji do zwinnych środowisk

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

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

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

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

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

Przejście do zwinnego zarządzania projektami

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

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

Wyzwania logistyczne w e-commerce a rozwój marketingu

Budowa systemu OMS na styku e-commerce i magazynu

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

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

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

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

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

Rozwiązywanie powtarzalnych problemów branży

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

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

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

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

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

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

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

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

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

Zastosowanie agentów AI w zwinnym rozwoju produktu

Problem taniego kodu i pułapki w szybkim projektowaniu

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

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

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

Wingman jako wsparcie Product Managera

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

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

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

Podsumowanie: Główne wnioski z rozmowy

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

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

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

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

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

Czego dowiesz się z tego wywiadu:

Rola architekta rozwiązań reklamowych w Google

Dlaczego fundamenty danych są kluczowe dla algorytmów

Wyzwania technologiczne i prawne przy bidowaniu do wartości

Data Governance i utrzymanie jakości danych

Przyszłość analityki w erze sztucznej inteligencji

Rola architekta rozwiązań reklamowych w Google

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

Mariusz Michalczuk: Cześć, witam Cię w kolejnym odcinku z serii Date with Data Talks, czyli podcastu od praktyków danych do praktyków wykorzystania danych i vice versa. Dzisiaj moim i Twoim gościem jest Karolina Wrzask. Cześć Karolina.

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

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

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

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

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

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

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

Dlaczego fundamenty danych są kluczowe dla algorytmów

Adopcja nowych rozwiązań a jakość danych

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

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

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

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

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

Wyzwania technologiczne i prawne przy bidowaniu do wartości

Bariery w przekazywaniu danych o marży i zyskach

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

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

Mariusz Michalczuk: Trudno go znaleźć.

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

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

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

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

\

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

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

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

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

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

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

Data Governance i utrzymanie jakości danych

Od zbierania wszystkiego do świadomego zarządzania informacją

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

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

Mariusz Michalczuk: Takie uczenie ze wzmocnieniem?

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Przyszłość analityki w erze sztucznej inteligencji

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

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

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

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

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

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

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

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

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

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

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

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

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

Podsumowanie: Główne wnioski z rozmowy

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

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

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

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

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

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

Punkt wyjścia

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

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

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

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

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

Wyzwania

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

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

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

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

Nasze podejście

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

Zakres prac objął:

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

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

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

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

Efekty

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

Odzyskane transakcje

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

Naprawiona atrybucja

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

Stabilniejsze sesje

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

Czystszy model pomiarowy

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

Co ten projekt zmienił biznesowo?

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

Dzięki temu:

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

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

Fundament pod kolejne etapy rozwoju

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

Ta architektura otwiera drogę do:

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

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

Podsumowanie

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

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

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

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

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

Wprowadzenie do DataOps

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

Praca na surowych danych a czas i koszty analizy

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

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

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

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

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

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

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

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

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

Błędy w przypisywaniu parametrów i atrybucji

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

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

Model danych jako sprawdzone rozwiązanie

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

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

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

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

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

Podsumowanie

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

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

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

Zrozumienie danych z Google Search Console

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

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

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

DataOps i automatyzacja pobierania danych

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

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

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

Analiza nożyc AI Overviews i scoring ryzyka

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

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

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

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

Intencja i kategorie zapytań

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

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

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

Scoring ryzyka

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

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

Rekomendacje i działania naprawcze

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

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

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

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

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

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

Podsumowanie

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

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

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