Nie karm algorytmów śmieciami. Architektura danych zamiast analityki z wtyczki

Analityka zainstalowana i analityka zaprojektowana wyglądają w panelu tak samo, a różnicę między nimi widać dopiero w budżecie mediowym. W tym artykule opiszę cztery mechanizmy, którymi darmowa wtyczka analityczna psuje dane wysyłane do Google Ads i Mety. Pokażę architekturę danych opartą na Google Tag Managerze (GTM), którą stawiam zamiast niej, i zejdę na koniec tam, gdzie kończą się możliwości przeglądarki. Po drodze obalę przekonanie, że wystarczy do tego dobra agencja performance.

Zacznę od sytuacji, którą widziałem w kilku wariantach i która za każdym razem wyglądała tak samo. Właściciel sklepu internetowego patrzy na raport z Google Ads, gdzie ROAS wynosi 1200%, kampanie wyglądają na rentowne, a marketing ma gotowy argument za wyższym budżetem. W tym samym tygodniu księgowość zgłasza, że na rachunku brakuje gotówki. Obie te rzeczy są prawdziwe naraz i nie ma w tym sprzeczności, bo liczby w raporcie opisują zdarzenia, które nigdy się nie wydarzyły.

Algorytmy Google Ads i Mety od miesięcy optymalizują się pod konwersje wygenerowane przez wtyczkę, która liczy każde kliknięcie w przycisk „Kup" jako zakup, bez pytania sklepu, czy transakcja doszła do skutku. Systemy licytacyjne robią wtedy dokładnie to, do czego je zbudowano, czyli podbijają stawki za ludzi, którzy klikają. To, że ci ludzie nie kupują, nie jest dla nich żadną informacją. Nikt im tego nie powiedział.

Najdroższym skutkiem analityki z wtyczki nie jest więc błędny raport w GA4, czyli w Google Analytics 4. Jest nim algorytm uczony na fikcji, który z każdym dniem optymalizacji coraz precyzyjniej trafia w niewłaściwych ludzi, i który przy tym pracuje bez zarzutu, bo robi dokładnie to, o co go poproszono.

Zupa z tagów, czyli skąd biorą się zdublowane konwersje w GA4

Przeprowadziłem audyty kilkudziesięciu kont GA4 i GTM i najczęstszy stan zastany nazywam zupą z tagów. Historia jest za każdym razem ta sama, tylko z inną obsadą, a jej sedno polega na tym, że każda z zaangażowanych osób zrobiła coś rozsądnego i żadna nie wiedziała o pozostałych.

1. Agencja wdrożyła kontener GTM i skonfigurowała w nim tagi konwersji.

2. Właściciel sklepu zainstalował darmową wtyczkę „Google for WooCommerce", bo jest darmowa i nie wygląda groźnie.

3. Deweloper wpisał skrypt gtag.js bezpośrednio w kod strony, bo „konfiguracja analityki" wisiała w zakresie prac przy jej budowie.

4. Ktoś w panelu GA4 włączył Ulepszony pomiar (Enhanced Measurement), bo Google go rekomenduje.

Efekt widać dopiero na poziomie zdarzeń. Klient kupuje jeden produkt, a do GA4 trafiają w tym samym ułamku sekundy trzy niezależne zdarzenia purchase: jedno z kontenera agencji, jedno z wtyczki WooCommerce i jedno z hardkodowanego gtag.js. Klient wypełnia jeden formularz, a analityka rejestruje cztery zdarzenia form_submit, bo do tamtych trzech dokłada się jeszcze Ulepszony pomiar. Raport pokazuje wtedy ROAS 1200%, algorytm dostaje sygnał o potrójnej skuteczności kampanii i zaczyna licytować wyżej za ludzi, których realna wartość jest trzykrotnie niższa, niż pokazuje panel.

W tym miejscu pada zwykle pytanie, które trzeba potraktować poważnie, bo jest sensowne: skoro kampanie prowadzi agencja, dlaczego ona tego nie zgłasza. Agencja performance jest w tym układzie pilotem. Zna aerodynamikę Google Ads, umie czytać raporty, pisać teksty reklam i zarządzać budżetem z dokładnością do złotówki. W kokpicie nie ma jednak inżyniera danych i nie powinno go tam być, bo to nie jest jej samolot. Kiedy wchodzi do nowego klienta i ma szybko uruchomić kampanię, robi jedyną rozsądną rzecz w dostępnym czasie, czyli instaluje wtyczkę, podpina GA4 i startuje. Konwersje się zliczają, kampania działa.

Problem zaczyna się piętro niżej. Media buyer loguje się do panelu, widzi 300 leadów i optymalizuje pod nie kampanię, przesuwając budżety, testując grupy odbiorców i korygując stawki. Robi dokładnie to, za co dostaje wynagrodzenie. Nie wie tylko, że 200 z tych 300 leadów to błędy walidacji formularza, boty i przypadkowe kliknięcia, bo panel Google Ads nie ma jak mu tego pokazać. To jest ślepy pilot: nie prowadzi kampanii źle, prowadzi ją na radarze, który kłamie, a w kokpicie nie ma przyrządu, który zgłosiłby mu tę usterkę. Nie wynika to ze złej pracy agencji, tylko z luki między dwiema rolami, których nikt nie połączył, bo kalibrowanie radaru nigdy nie należało do pilota.

Czwarte źródło z listy zasługuje przy tym na osobną uwagę, bo jako jedyne włącza się jednym kliknięciem w panelu i wygląda na rekomendację producenta. Ulepszony pomiar rejestruje zdarzenie form_submit na poziomie przeglądarki, bez żadnej wiedzy o tym, czy formularz przeszedł walidację, czy użytkownik zobaczył komunikat o błędzie, czy w tle doładował się zewnętrzny skrypt. W jednym z audytowanych kont zliczał kilkadziesiąt wysłanych formularzy dziennie na stronie, na której realnych zapytań było kilka. Przyczyną okazały się ukryte ramki iframe z integracji zewnętrznej, ładujące się przy każdym wejściu. Dlatego w każdym wdrożeniu wyłączam z niego co najmniej śledzenie formularzy, przewijania i wyszukiwania w witrynie. Te trzy zdarzenia konfiguruję ręcznie w GTM, z kontrolą nad tym, kiedy i z jakimi parametrami zostają wysłane.

Dlaczego wtyczka liczy konwersje, które nigdy nie doszły do skutku

Duplikacja to problem konfiguracji i da się ją usunąć w jedno popołudnie. Druga wada wtyczek jest wpisana w ich architekturę i nie usuwa jej żadne ustawienie. Wtyczka analityczna żyje w przeglądarce i widzi wyłącznie to, co widzi przeglądarka, czyli zmianę adresu URL, pojawienie się elementu na stronie albo załadowanie podstrony /thank-you. Nie ma dostępu do backendu sklepu, więc nie wie, czy formularz przeszedł walidację po stronie serwera, czy zamówienie trafiło do bazy i czy płatność się powiodła. Mierzy symptom, czyli „przeglądarka pokazała stronę podziękowania", a nie wynik, czyli „serwer potwierdził transakcję".

Praktyczna konsekwencja jest taka, że konwersja odpala się przy każdym wejściu na adres /order-complete: z pamięci podręcznej, po odświeżeniu strony, przy wizycie bota, przy wejściu testera sklepu na dzień przed startem kampanii. Algorytmy uczą się na tych zdarzeniach równie chętnie jak na prawdziwych zakupach, bo nie mają czym ich odróżnić.

Stąd bierze się reguła, na której stoi każde moje wdrożenie: zdarzenie purchase i generate_lead wyzwala wyłącznie sygnał z backendu, nigdy zmiana adresu ani pojawienie się elementu w drzewie strony. W GTM realizuję to przez nasłuch osobnego zdarzenia w Data Layer, które system sklepu wysyła dopiero po potwierdzeniu transakcji. Przeglądarka potrafi skłamać w dobrej wierze, serwer podaje stan faktyczny.

Z tego samego ograniczenia bierze się druga usterka, tyle że ta jest cicha, więc kosztuje więcej. Duża część wtyczek i amatorskich wdrożeń GTM pobiera dane metodą zwaną DOM scraping, czyli odczytuje je wprost z tekstu wyświetlonego na stronie, po selektorze CSS. Reguła w kontenerze mówi wtedy: weź wartość z elementu o klasie .product-price. Działa to bez zarzutu do dnia, w którym deweloper przy aktualizacji motywu zmienia tę klasę na .price_value.

Pomiar nie zgłasza wtedy żadnego błędu, po prostu przestaje przekazywać wartość transakcji, a Smart Bidding traci sygnał, na którym stoi cała jego optymalizacja. Właściciel sklepu dowiaduje się o tym po dwóch, trzech tygodniach, kiedy wyniki pogarszają się na tyle, że ktoś zaczyna szukać przyczyny. Algorytm zdążył się już w tym czasie przeuczyć na zaniżonych danych.

Jak fałszywe konwersje psują Smart Bidding w Google Ads

Branża sprzedaje dziś automatyzację: Smart Bidding, Advantage+, Performance Max, kampanie, które same znajdują klientów. Brzmi to dobrze i w większości przypadków jest prawdą. Kłopot polega na tym, że pod tymi hasłami leży założenie, o którym nikt nie mówi głośno, bo wydaje się zbyt oczywiste, czyli że dane wejściowe są prawdziwe. Zasada opisująca, co się dzieje, gdy nie są, jest stara jak informatyka i nazywa się GIGO, garbage in, garbage out. Algorytm nakarmiony śmieciami z wielką precyzją przepali budżet na śmieciowy ruch.

Warto spojrzeć na to z jego strony, bo wtedy widać, że nie ma w tym żadnej awarii. Algorytm nie wie, że dane są fałszywe, bo nie ma ich z czym porównać. Widzi 300 konwersji, analizuje, co łączy ludzi, którzy je wygenerowali, i zaczyna szukać kolejnych takich samych. Buduje profil idealnego klienta na podstawie osób, które nigdy niczego nie kupiły, i z każdym dniem optymalizacji ten profil dopracowuje. Coraz sprawniej znajduje więc ludzi, którzy klikają, i coraz rzadziej trafia na tych, którzy kupują. Im dłużej trwa kampania, tym trudniej to odwrócić, bo model uczy się także na własnych wynikach.

Duplikaty i fałszywe zdarzenia to jednak tylko jedna strona problemu, a druga jest cichsza, bo dane są w niej prawdziwe, tylko niepełne. Smart Bidding w trybach tROAS i tCPA przewiduje wartość przyszłego użytkownika według prostego równania, w którym oczekiwana wartość to prawdopodobieństwo konwersji pomnożone przez jej wartość. Jeśli każde zdarzenie generate_lead przychodzi z wartością zero, a taki jest domyślny stan po wdrożeniu wtyczki, drugi człon równania znika. Algorytm optymalizuje wtedy pod liczbę leadów, nie pod ich jakość, i traktuje zapytanie ofertowe za 50 000 PLN tak samo jak zapis do newslettera. Rozwiązaniem jest przypisanie wartości każdej konwersji, w e-commerce wartości koszyka, a w leadgenie wartości nadanej z góry, odpowiadającej średniemu LTV dla danego typu zapytania.

window.dataLayer.push({
  event: 'generate_lead',
  lead_value: 1000,            // PLN — średni LTV dla zapytania Enterprise
  customer_tier: 'enterprise', // smb | mid_market | enterprise
  lead_type: 'analytics_tracking',
  service_area: 'analytics',
  budget_range: '10k-50k'
});

Kiedy Google Ads wie, że lead z formularza „Wdrożenie analityki Enterprise" jest wart 1000 PLN, a zapis do newslettera 10 PLN, zaczyna szukać ludzi o profilu tej pierwszej grupy. Badania Google wskazują tu na medianowy wzrost wartości konwersji o 14% przy tym samym budżecie.

Kolejność jest jednak nieprzestawialna i to jest sedno całej sekcji. Value-Based Bidding nie jest plastrem na zepsutą analitykę, tylko nagrodą dla firm, które najpierw uporządkowały dane. Nie da się nauczyć modelu szukania klientów wartych 50 000 PLN, jeśli zdarzenie o nich przychodzi zduplikowane, bez wartości i bez parametrów.

Architektura danych zaczyna się od jednego źródła w Google Tag Managerze

Diagnoza jest gotowa, więc przechodzę do tego, co stawiam w miejscu wtyczki, w kolejności odpowiadającej kolejności prac we wdrożeniu. Pierwszą decyzję podejmuję zawsze tak samo i nie robię od niej wyjątków: jeśli w projekcie jest GTM, to GTM jest jedynym systemem, który zbiera i rozsyła dane analityczne. W praktyce oznacza to trzy operacje. Wyłączam wszystkie wtyczki analityczne, od Google for WooCommerce po MonsterInsights, usuwam z kodu strony hardkodowane gtag.js i analytics.js, a Ulepszony pomiar ograniczam do niezbędnego minimum. Dopiero wtedy duplikaty znikają, bo znika ich źródło.

Kontener staje się wtedy tłumaczem i dystrybutorem, czyli tym, czym miał być od początku. Pobiera czystą informację z Data Layer i wysyła ten sam sygnał równolegle do GA4, Google Ads i pozostałych systemów reklamowych. Wszystkie dostają identyczny obraz zdarzenia, a poprawka wprowadzona raz działa na każdy z nich.

Skoro jednak kontener ma pobierać czystą informację, ktoś musi mu ją podać, i tym kimś jest system sklepu. Data Layer to obiekt, do którego backend sam przekazuje dane w ustalonym formacie, zamiast zostawiać kontenerowi zgadywanie po elementach strony. To kontrakt między systemem sklepu a systemem pomiarowym, obowiązujący niezależnie od tego, jak strona akurat wygląda, a standardem dla e-commerce jest format zgodny ze schematem GA4 Ecommerce:

window.dataLayer = window.dataLayer || [];
dataLayer.push({ ecommerce: null }); // Czyszczenie poprzedniego obiektu — kluczowe!
dataLayer.push({
  event: "purchase",
  ecommerce: {
    transaction_id: "T_12345",
    value: 254.00,
    tax: 48.00,
    shipping: 15.00,
    currency: "PLN",
    coupon: "SUMMER20",
    items: [
      {
        item_id: "SKU_001",
        item_name: "Kurtka zimowa",
        item_category: "Odzież",
        item_brand: "BrandX",
        price: 239.00,
        quantity: 1
      }
    ]
  }
});

Linijka dataLayer.push({ ecommerce: null }) nie jest ozdobnikiem, bo bez niej obiekty z kolejnych zdarzeń e-commerce na tej samej stronie nakładają się na siebie i do analityki trafia mieszanka dwóch transakcji. Korzyść z takiej warstwy jest przy tym mierzalna w kampaniach, nie w raportach. Stabilny Data Layer oznacza brak przerw w pomiarze przy przebudowach front-endu, a każda taka przerwa przestawia Smart Bidding w tryb ponownego uczenia trwający od 7 do 14 dni, z odpowiadającym mu spadkiem skuteczności.

Jedno zdarzenie z parametrami zamiast pięćdziesięciu mikroeventów w GA4

Kiedy pomiar zaczyna działać, pojawia się pokusa mierzenia wszystkiego, a razem z nią problem, który widzę niemal w każdym audycie, czyli chaos zdarzeń i wyczerpane limity GA4. Darmowa wersja ma twarde ograniczenia. Pierwsze to pięćdziesiąt niestandardowych wymiarów na usługę, drugie to kardynalność: kiedy wartości wymiaru są zbyt zróżnicowane, GA4 zwija je do pozycji (other) i raport przestaje cokolwiek znaczyć. Amatorskie wdrożenia dochodzą do tej granicy szybko, bo tworzą osobne zdarzenie na każdą interakcję, w rodzaju click_phone_header, click_phone_footer, click_phone_hero i copy_email_contact_page. Sto takich mikroeventów zajmuje sto slotów i nie odpowiada na żadne pytanie biznesowe.

Architektura parametryczna rozwiązuje to jedną decyzją projektową, bo zamiast nowego zdarzenia na każdą interakcję używam jednego, wielokrotnego, z bogatym payloadem:

// Jedno zdarzenie, nieskończone możliwości filtrowania
window.dataLayer.push({
  event: 'contact_click',
  contact_type: 'tel',         // email | tel | whatsapp | messenger
  contact_detail: '+48798331419',
  page_path: window.location.pathname,
  click_location: 'header'     // header | footer | hero_section | pricing
});

Zajmuje to jeden slot zdarzenia i trzy do czterech slotów wymiarów. W zamian pozwala zadać w Eksploracjach GA4 pytanie w rodzaju „ile razy kliknięto w numer telefonu w sekcji hero na stronie głównej w ostatnich 30 dniach, licząc tylko ruch z Google Ads". Bez dokładania czegokolwiek w kontenerze. Punktem wyjścia przy projektowaniu nie jest więc pytanie „co chcę mierzyć", tylko „jakie pytania biznesowe zadam tym danym za pół roku", bo odpowiedź na to drugie dyktuje zarówno nazwy zdarzeń, jak i listę parametrów.

Ta sama zasada obowiązuje po stronie kontenera. Kiedy widzę w nim kilkanaście tagów o nazwach phone_click, email_click, copy_mail i copy_tel, wiem, że wdrożenie powstawało metodą dokładania kolejnego wyjątku, a koszt takiego układu ujawnia się przy pierwszej zmianie w firmie. Trzy nowe oddziały i pięć nowych numerów telefonu oznaczają wejście do kontenera, nowe reguły, aktualizację wyrażeń regularnych i publikację. Prędzej czy później ktoś zapomni o jednym numerze, a zapomniany trigger to dziura w danych, o której nikt nie wie. Standardem jest dlatego jeden globalny nasłuch, który sam rozpoznaje kontekst:

(function() {
  document.addEventListener('copy', function(e) {
    var selection = window.getSelection().toString();
    if (!selection) return;

    // Czyścimy spacje i myślniki do testu regex — zachowujemy oryginał do raportu
    var cleanSelection = selection.replace(/[\\s\\-]/g, '');

    var type = '';
    var emailRegex = /^[^\\s@]+@[^\\s@]+\\.[^\\s@]+$/;
    var phoneRegex = /^\\+?[0-9]{9,15}$/;

    if (emailRegex.test(cleanSelection)) {
      type = 'email';
    } else if (phoneRegex.test(cleanSelection)) {
      type = 'tel';
    }

    if (type) {
      window.dataLayer.push({
        'event': 'contact_copy',
        'contact_type': type,
        'contact_detail': selection.trim(),
        'page_path': window.location.pathname
      });
    }
  });
})();

Wstrzykuję ten skrypt przez GTM jako Custom HTML z regułą „All Pages", raz, i od tego momentu klient może zmieniać numery oraz adresy codziennie, a pomiar sam je rozpozna i sklasyfikuje. Utrzymanie nie kosztuje ani jednej roboczogodziny, a lista numerów nie ma jak rozjechać się z pomiarem.

Jak mierzyć lejek formularza w GA4 zamiast jednego zdarzenia o wysłaniu

Ostatni element architektury dotyczy miejsca, w którym najczęściej giną pieniądze, czyli formularza. Wtyczki kończą pomiar na binarnym zdarzeniu form_submit, a to klasyczna metryka próżności. Mówi, że sto osób wysłało formularz, i milczy o pozostałych czterystu, które kliknęły w wezwanie do działania i formularza nie wysłały. Decydentowi nie wystarczy informacja o tym, co się udało, bo musi wiedzieć, na którym polu traci klientów i czy odpowiada za to interfejs, czy kampania przyciągająca niewłaściwych ludzi.

Dlatego formularz mierzę jako sekwencję czterech zdarzeń, z których każde odpowiada na inne pytanie. Pierwsze, form_start, to fokus na dowolnym polu, więc niski współczynnik w tym miejscu wskazuje na wezwanie do działania albo na umiejscowienie formularza, a nie na kampanię. Drugie, form_field_fill, odpala się przy opuszczeniu pola z wartością i dzięki niemu widzę, że 40% osób rezygnuje po dotarciu do pola „Budżet projektu", czyli mam usterkę do naprawienia bez dotykania budżetu reklamowego.

Trzecie, form_error, zbiera walidację front-endową, a pole „NIP" generujące błąd u 30% wypełniających oznacza zbyt ostrą maskę i zniecierpliwionych klientów traconych na ostatniej prostej. Czwarte, form_submit_success, to jedyne twarde potwierdzenie z serwera i dopiero w tym momencie do Data Layer trafiają zahaszowane dane osobowe, które wysyłam równolegle do Google Ads i Mety:

window.dataLayer.push({
  event: 'form_submit_success',
  form_id: 'contact_form',
  form_name: 'Contact Form - Main',
  lead_type: 'b2b_consulting',
  service_area: 'analytics',
  budget_range: '10k-50k',
  user_data: {
    email: '[email protected]',        
    phone_number: '+4855555555'
  }
});

Consent Mode v2 decyduje, ile z tych danych dotrze do platform

Cała architektura opisana wyżej jest warta tyle, ile przepuści przez siebie warstwa zgód, więc to ostatni element wdrożenia i jedyny, który ma konsekwencje prawne. W audytach wracają dwa wzorce i oba są kosztowne, tylko w przeciwnych kierunkach. Pierwszy to blokada całkowita, w której platforma zgód albo CMS w ogóle nie wpuszcza kontenera na stronę. Nie odpala się wtedy nic i nic nie odpali się później, bo użytkownik, który kliknie „odrzuć", zostaje z martwym pomiarem do końca wizyty. Google nie dostaje od niego nawet tyle, że ktoś wszedł i odmówił. Drugi wzorzec jest odwrotny: tagi odpalają się niezależnie od wyboru, raporty wyglądają wzorowo, a każde takie wysłane zdarzenie jest naruszeniem, za które kara sięga 4% rocznego obrotu.

Zaawansowany tryb Consent Mode rozwiązuje oba problemy naraz i tu leży cała różnica wobec blokady. Kontener ładuje się zawsze, a tag odpala się również po odmowie, tylko w okrojonej postaci: bez ciasteczek i bez identyfikatorów użytkownika, niosąc samą informację, że zdarzenie miało miejsce i że zgody nie było. Pełne dane wychodzą dopiero po jej wyrażeniu. Z tych okrojonych sygnałów Google odtwarza część konwersji od osób, które zgody nie wyraziły, choć modelowanie wymaga odpowiedniego wolumenu i na najmniejszych kontach nie zadziała.

Eksploracje GA4 pokazują, w którym miejscu lejka uciekają pieniądze

Architektura ma sens tylko wtedy, gdy ktoś z tych danych korzysta. Domyślne raporty GA4 dobrze odpowiadają na pytanie, co się stało, i nie odpowiadają wcale na pytanie, dlaczego oraz w którym miejscu uciekają pieniądze. Raport „Pozyskiwanie ruchu" powie, skąd przyszli użytkownicy, ale nie powie, dlaczego 60% z nich wyszło po zobaczeniu formularza, ani że ruch z Google Ads ma trzykrotnie wyższy wskaźnik błędów walidacji niż organiczny. To pokazują dopiero Eksploracje, i wyłącznie na danych, które ktoś wcześniej zaprojektował.

W jednym z wdrożeń klient miał dobre wyniki kampanii w Google Ads i słabą konwersję na leady, czyli klasyczny objaw, który zwykle przypisuje się jakości ruchu. Zbudowałem lejek z pięciu kroków:

1. page_view (strona usługi)

2. cta_click (click_location = hero_section)

3. form_start

4. form_field_fill (field_name = budget)

5. form_submit_success

Między krokiem trzecim a czwartym odpadało 58% osób. Ponad połowa tych, którzy zaczęli wypełniać formularz, rezygnowała dokładnie w momencie, gdy padało pytanie o budżet, a ruch z kampanii nie miał z tym nic wspólnego.

Naprawa polegała na przesunięciu tego pola na koniec formularza, za imię, adres e-mail i opis projektu, czyli do momentu, w którym wypełniający jest już zaangażowany. Konwersja formularza wzrosła o 18% bez zmiany kampanii, budżetu i kreacji. Ze standardowych raportów nie da się dojść do takiego wniosku, bo wymaga on zdarzeń z parametrami, w tym przypadku parametru field_name w form_field_fill, oraz narzędzia, które ustawi je w sekwencję.

Ten sam lejek daje się rozbić na segmenty. Sekwencja wygląda wtedy zupełnie inaczej dla ruchu z Google Ads i organicznego, dla mobile i desktopu, dla odwiedzających pierwszy raz i powracających. Największą różnicę widać między użytkownikami deklarującymi różne przedziały budżetu. Ustandaryzowane parametry przekładają się przy tym bezpośrednio na listy remarketingowe eksportowane do Google Ads i Mety. Trzy, które buduję regularnie i których bez tej architektury zbudować się nie da:

• osoby, które wybrały service_area = analytics i nie ukończyły formularza, kierowane na artykuł edukacyjny o kosztach złej analityki, bo intencja jest już wyrażona i brakuje tylko powodu do powrotu

• użytkownicy z customer_tier = enterprise, którzy odwiedzili cennik trzy razy lub więcej w ciągu 14 dni, kierowani wprost na konsultację, bo są gotowi na rozmowę, a nie na kolejną reklamę zasięgową

• klienci, którzy kupili z kategorii Szkolenia, ale nie z kategorii Wdrożenia, jako naturalna grupa do cross-sellu

Wtyczka wysyłająca purchase bez pozycji, kategorii i wartości daje w tym miejscu jedną możliwą grupę, czyli „wszyscy, którzy cokolwiek kupili". Sam przy budowaniu list zaczynam zresztą od pytania, kogo wykluczyć, a nie kogo dodać. Odcięcie osób, które definitywnie wypadły ze ścieżki zakupowej, obniża zmarnowany budżet równie skutecznie jak precyzyjne targetowanie, a kosztuje mniej pracy przy utrzymaniu.

Enhanced Conversions i Meta CAPI, czyli pomiar mimo blokad przeglądarki

Wszystko powyżej dotyczy pomiaru wykonywanego w przeglądarce, a nawet perfekcyjnie zaprojektowany pomiar traci tam część danych, i nie z powodu błędów konfiguracji, tylko dlatego, że przeglądarka przestała być neutralnym narzędziem. Blokery treści, restrykcje prywatności i ograniczenia ciasteczek działają w niej niezależnie od jakości wdrożenia. Pierwszą odpowiedzią na to są mechanizmy dopasowania po danych użytkownika, które Google nazywa Rozszerzonymi Konwersjami (Enhanced Conversions), a Meta zaawansowanym dopasowaniem realizowanym przez Conversions API. W obu działa to tak samo: zahaszowany funkcją SHA-256 adres e-mail lub numer telefonu zostaje porównany z danymi kont reklamowych i pozwala przypisać konwersję nawet wtedy, gdy ciasteczko wygasło albo zostało zablokowane.

Wtyczki mają z tym kłopot strukturalny w obu ekosystemach naraz. Sięgają po dane z profilu zalogowanego użytkownika albo z ciasteczka sesji, a nie z formularza, który ktoś właśnie wypełnił, więc osoba niezalogowana nie zostawia im niczego do wysłania. GTM pobiera te dane w locie, w momencie zdarzenia form_submit_success, i normalizuje je przed zahaszowaniem, czyli sprowadza numer telefonu do jednej postaci niezależnie od numeru kierunkowego, a adres e-mail do jednakowej wielkości liter. Ten sam payload trafia równolegle do Google Ads i Mety, a wyższy wskaźnik dopasowania oznacza konwersje odzyskane z ruchu, który wcześniej lądował w kategorii „bezpośrednie".

To jednak nadal pomiar wykonywany w przeglądarce, więc nadal podlega jej ograniczeniom. Najdotkliwszym jest mechanizm ITP w Safari. Skraca on żywotność ciasteczek zapisywanych przez skrypty do około siedmiu dni, a przy wejściu z oznaczonego linku reklamowego nawet do doby. Klient klika reklamę w poniedziałek, ogląda produkty i wychodzi, a kiedy wraca w środę i kupuje, wraca jako ktoś zupełnie obcy. Transakcja ląduje wśród wejść bezpośrednich, kampania wygląda na nierentowną, a algorytm nie dowiaduje się, która reklama doprowadziła do sprzedaży.

Server-side tagging przenosi pomiar poza przeglądarkę

Rozwiązaniem tej klasy problemów jest zmiana trasy, którą pokonują dane. W klasycznym układzie przeglądarka klienta rozmawia bezpośrednio z Google i Metą. W układzie serwerowym między nią a platformami staje serwer pomiarowy działający pod adresem sklepu. Strona rozmawia wyłącznie z nim, a on decyduje, co i dokąd przekazuje dalej. Mechanikę opisałem osobno w przewodniku po server-side taggingu, tu liczy się jeden mit, który obalam od razu, bo kosztuje najwięcej. Powszechne przekonanie mówi, że wystarczy postawić subdomenę w rodzaju metrics.twojsklep.pl, żeby ominąć blokady, tymczasem w 2026 roku przeglądarki i blokery wykrywają taki alias bez trudu.

W swoich wdrożeniach buduję architekturę opartą na Cloudflare Workers. Subdomena nadal istnieje, ale nie jest zwykłym wpisem CNAME, tylko węzłem pośredniczącym typu reverse proxy. Worker przejmuje ruch i maskuje docelową infrastrukturę pomiarową, zamiast ją wystawiać. Daje to dwie korzyści. Ruch przechodzi przez domenę sklepu i dla blokera jest nieodróżnialny od ładowania grafik czy działania koszyka, więc nie zostaje wycięty. Ciasteczko analityczne nie jest już zapisywane przez skrypt w przeglądarce, tylko nadawane przez serwer w nagłówku Set-Cookie, co ITP traktuje z pełnym zaufaniem, więc okno atrybucji wraca z tygodnia do miesięcy.

W moich wdrożeniach ta zmiana przywracała do pomiaru rzędu 20 do 40% zdarzeń, w zależności od tego, ile ruchu przychodziło z urządzeń i przeglądarek wycinających pomiar. Ta liczba wymaga jednak zastrzeżenia, bo bywa nadużywana w ofertach: dotyczy wyłącznie strat, w których przeglądarka miała szansę wysłać sygnał i została zablokowana.

Obok niej istnieją inne klasy strat, przede wszystkim zakupy opłacone w bramce płatniczej, po których klient nigdy nie wraca na stronę z podziękowaniem. W tym przypadku nie ma czego odblokowywać, bo nie ma ani jednej chwili, w której skrypt mógłby cokolwiek wysłać, i potrzebne jest zupełnie inne rozwiązanie, czyli zgłoszenie prosto z systemu sklepu. Liczby z tych dwóch światów się nie sumują, więc pytanie „ile odzyskam" bez podziału na klasy strat nie ma dobrej odpowiedzi. Sposób policzenia własnej dziury opisałem w tekście o Data Blackout, a odzyskiwanie transakcji z bramek płatności w case study wdrożenia webhooka.

Kolejność prac wynika z tego wszystkiego sama. Najpierw trzeba zaprojektować rzetelne źródło danych, a dopiero na nim budować pomiar poza przeglądarką. Odwrotna kolejność kosztuje najwięcej, bo serwer postawiony na zdublowanych zdarzeniach powiela je równie wiernie jak wcześniej, tylko drożej. Najtańszy pierwszy krok zajmuje za to kilkanaście sekund i nie wymaga dostępu do żadnego panelu, bo darmowa wtyczka Google Tag Assistant w Chrome pokazuje, ile kontenerów działa na stronie. Więcej niż jeden kontener GTM albo GTM stojący obok gtag.js oznacza, że duplikacja trwa już teraz i codziennie przekłada się na stawki w kampaniach.

Zrób ten test u siebie, zanim zaczniesz zmieniać cokolwiek w kampaniach. Jeśli zobaczysz więcej niż jedno źródło danych, napisz do mnie z tym, co pokazał Tag Assistant, a ustalimy, ile ta duplikacja kosztuje przy Twoim budżecie i od czego zacząć.