Server-Side Tagging E-commerce: EMQ 9.3/10 [Case Study]

Architektura Server-Side Tracking: GTM Web, Stape i Cloudflare

Cel: jedno źródło prawdy (GTM) → czyste dane → server-side tracking → platformy reklamowe z pełnym zestawem parametrów.

Faza 1: Czyszczenie tagów i wdrożenie Consent Mode v2

Pierwszym krokiem nie było wdrożenie niczego nowego. Najpierw musiałem wyczyścić to, co zastałem.

Krok 1: Usunięcie duplikatów

Wyłączyłem plugin woocommerce-google-analytics-integration, który duplikował GA4 i Google Ads obok GTM. Następnie przeprowadziłem śledztwo - przeszukałem pliki motywu WordPress i niestandardowe moduły w poszukiwaniu ukrytych kodów analitycznych. Znalazłem gtag.js zahardkodowany w szablonie motywu i w kodzie modułu wielosztuk. Wszystko usunięte.

Krok 2: Wyłączenie zbędnych narzędzi

Hotjar został wyłączony - Microsoft Clarity robi to samo za darmo, bez limitów nagrań i z natywną integracją z GA4. Jedno narzędzie mniej obciążające stronę.

Krok 3: Przeniesienie wszystkiego do GTM

Każdy system analityczny i reklamowy - GA4, Google Ads, Meta Pixel, TikTok Pixel został przeniesiony wyłącznie do Google Tag Manager (GTM). Żadnych wtyczek, żadnych hardkodowanych skryptów. GTM jako jedyne źródło prawdy.

Krok 4: Poprawna konfiguracja Consent Mode v2

CookieYes został skonfigurowany tak, aby inicjalizować stan zgody przed załadowaniem kontenera GTM eliminując problem wasSetLate: true. Wszystkie tagi reklamowe (Meta, TikTok, Google Ads) zostały uzależnione od odpowiednich zgód (ad_storage, ad_user_data, analytics_storage).

Faza 2: Naprawa Data Layer (DOM Scraping) i zapobieganie Data Bleeding

To był najbardziej niestandardowy element wdrożenia. Moduł wielosztuk działał zupełnie inaczej niż standardowy WooCommerce, plugin GTM4WP, którego używam do budowania Data Layer, nie rozpoznawał zdarzeń add_to_cart generowanych przez ten moduł. Dane o dodaniu do koszyka były po prostu tracone.

Zwykle nie polecam metody DOM scrapingu, jest krucha i zależna od struktury HTML. Ale tutaj nie było alternatywy. Napisałem autorski skrypt, który osadzam przez GTM na stronie z modułem wielosztuk:

(function() {
  try {
    // Złap kliknięty element (zmienna wbudowana GTM: {{Click Element}})
    var clickedEl = {{Click Element}};

    // Znajdź kontener widżetu wielosztuk
    var module = clickedEl.closest('.qty-module');
    if (!module) return;

    // Pobierz dane produktu z atrybutów HTML modułu
    var productId = module.getAttribute('data-product-id');
    var basePrice = parseFloat(module.getAttribute('data-base-price')) || 0;

    // Odczytaj wybraną ilość z aktywnej opcji
    var activeOption = module.querySelector('.qty-option.active');
    var quantity = activeOption
      ? parseInt(activeOption.getAttribute('data-qty'), 10) || 1
      : 1;

    // Tabela rabatów progresywnych (1 szt = 0%, 2 = 15%, 4 = 20%, 6 = 25%)
    var discounts = { 1: 0.00, 2: 0.15, 4: 0.20, 6: 0.25 };
    var currentDiscount = discounts[quantity] || 0.00;
    var discountedUnitPrice = basePrice * (1 - currentDiscount);
    var totalValue = parseFloat((discountedUnitPrice * quantity).toFixed(2));

    // Mapowanie nazw produktów (fallback dla nowych produktów)
    var productCatalog = {
      '166': 'Dziennik wdzięczności i sukcesów - Wdzięcznopis (ECO)'
    };
    var exactItemName = productCatalog[productId] || 'Produkt ID: ' + productId;

    window.dataLayer = window.dataLayer || [];

    // Data Bleeding Prevention — czyszczenie obiektu ecommerce
    window.dataLayer.push({ 'ecommerce': null });

    // Push zdarzenia add_to_cart z pełnymi danymi e-commerce
    window.dataLayer.push({
      'event': 'dl_add_to_cart_multipack',
      'ecommerce': {
        'currency': 'PLN',
        'value': totalValue,
        'items': [{
          'item_id': String(productId),
          'item_name': exactItemName,
          'price': parseFloat(discountedUnitPrice.toFixed(2)),
          'quantity': quantity
        }]
      }
    });

  } catch (e) {
    if (window.console) console.warn('GTM Scraping Error (Wielosztuki):', e);
  }
})();

Skrypt nasłuchuje kliknięć w widżecie wielosztuk, odczytuje dane produktu bezpośrednio z atrybutów DOM (data-product-id, data-base-price), oblicza cenę po rabacie progresywnym i pushuje poprawne zdarzenie dl_add_to_cart_multipack do Data Layer.

Kluczowy detal: ecommerce: null przed właściwym pushem. Bez tego GA4 może "skleić" dane z poprzedniego zdarzenia e-commerce z nowym. Zjawisko znane jako Data Bleeding. To klasyczny edge case, który trudno wykryć, a potrafi zniekształcić raporty lejka zakupowego.

Faza 3: Dlaczego Server-Side Tracking to konieczność w 2026 roku?

Po wyczyszczeniu fundamentów klientka zdecydowała się na wdrożenie server-side tracking. Dlaczego to ma sens w 2026 roku?

Server-side tagging to przeniesienie przetwarzania danych analitycznych z przeglądarki użytkownika na własny serwer. Zamiast wysyłać dane bezpośrednio z przeglądarki do Google, Meta czy TikToka, dane lecą najpierw na własny serwer, a dopiero stamtąd — do platform reklamowych.

Co to daje:

• Odporność na adblockery i ITP - przeglądarki blokują domeny reklamowe (facebook.com, google-analytics.com). Ale nie blokują żądań do Twojej własnej domeny. Server-side tracking działa jako "pośrednik" na Twojej domenie, dla przeglądarki to ruch first-party

• Dłuższe ciasteczka - Safari skraca ciasteczka JavaScript do 7 dni (ITP). Ciasteczka ustawiane z serwera (first-party, HttpOnly) żyją znacznie dłużej — lepsze rozpoznawanie powracających użytkowników, lepsza atrybucja

• Pełna kontrola nad payloadem - decydujesz, jakie dane wysyłasz do Meta, Google czy TikToka. Możesz wzbogacać payload o dane z backendu (np. wartość LTV klienta) lub usuwać dane wrażliwe

• Lepsza jakość sygnału - Meta i Google wyraźnie preferują dane server-side. Conversions API (Meta) i Enhanced Conversions (Google) to nie dodatki — to fundament skutecznej optymalizacji kampanii

Architektura: Stape.io + Cloudflare Workers (Same-Origin)

Zdecydowałem się na konfigurację same-origin, która daje najwyższą odporność na adblockery. Schemat:

1. Domena oddelegowana na Cloudflare - pierwszy krok. Przy okazji poprawiło to szybkość ładowania strony (CDN, optymalizacja obrazów) i pozwoliło odfiltrować część ruchu botów (Cloudflare Bot Management)

2. Cloudflare Workers - ako reverse proxy — żądania do endpointu analitycznego (wdziecznopis.pl/xxx/...) są przekierowywane do kontenera GTM Server na Stape.io. Dla przeglądarki i adblockerów to ruch do domeny wdziecznopis.pl - first-party, nie do zablokowania

3. Stape.io jako hosting kontenera GTM Server - przetwarza żądania i rozsyła dane do GA4, Meta CAPI, Google Ads i TikTok Events API

Etapowe wdrożenie GA4 Server-Side

Nie przełączam od razu. Najpierw założyłem drugą usługę GA4, skierowaną przez serwer. Przez kilka dni porównywałem dane z obu usług. Gdy okazało się, że dane server-side są zbieżne, usunąłem zduplikowane tagi i przekierowałem główne tagi przez serwer za pomocą server_container_url.

Faza 4: Meta Conversions API (CAPI) i dedykowany Data Tag Stape

Konfiguracja Meta Conversions API to miejsce, gdzie większość wdrożeń idzie na skróty. Standardowe podejście: odbiór danych przez klienta Google Analytics 4 na serwerze i przekazanie ich do tagu Meta. Proste, szybkie i niedoskonałe.

Dlaczego postawiłem na dedykowany Data Tag Stape?

Meta ma inne wymagania dotyczące parametrów niż GA4 i Google Ads. Przygotowałem zestaw zmiennych Custom JavaScript (CJS) specjalnie pod Meta - mapowanie contents i content_ids, normalizacja danych użytkowników, dedykowane formaty. Chciałem mieć pełną kontrolę nad payloadem, a nie polegać na automatycznej transformacji z formatu GA4.

Dla każdego zdarzenia Meta (PageView, ViewContent, AddToCart, InitiateCheckout, Purchase) skonfigurowałem dedykowany Data Tag Stape w GTM Web, który wysyła dane do GTM Server. Tam odbiera je Data Client, który przekazuje je dalej do Meta CAPI z precyzyjnym mapowaniem Event Data i User Data.

Zmienna CJS: Meta Contents z GA4 Ecommerce

Przykład zmiennej, która transformuje tablicę items z GA4 na format content_ids wymagany przez Meta:

function() {
  var ecommerceObject = {{DLV - ecommerce}};

  if (!ecommerceObject || !ecommerceObject.items || !Array.isArray(ecommerceObject.items)) {
    return [];
  }

  var ga4Items = ecommerceObject.items;

  // Mapowanie item_id z GA4 na content_ids dla Meta
  // ES5 — pełna kompatybilność ze starszymi przeglądarkami i GTM
  var uniqueContentIds = [];
  for (var i = 0; i < ga4Items.length; i++) {
    var id = ga4Items[i].item_id;
    if (id && uniqueContentIds.indexOf(id) === -1) {
      uniqueContentIds.push(id);
    }
  }

  return uniqueContentIds;
}

Meta wymaga content_ids jako płaskiej tablicy unikalnych identyfikatorów produktów. GA4 operuje na tablicy obiektów items. Ta zmienna robi transformację i deduplikację — prosty kod, ale krytyczny dla poprawnego działania dynamicznych reklam remarketingowych.

Faza 5: Normalizacja danych (PII) i maksymalizacja Event Match Quality (EMQ)

Event Match Quality (EMQ) to metryka Meta oceniająca jakość dopasowania zdarzeń server-side do użytkowników Facebooka. Skala 1-10. Im wyższy EMQ, tym lepiej algorytm Meta rozpoznaje, kto dokonał konwersji i tym precyzyjniej optymalizuje kampanie.

EMQ 9.3/10 to wynik, który osiągają nieliczne wdrożenia. Klucz: wysyłanie maksymalnej ilości znormalizowanych danych użytkownika: email, telefon, imię, nazwisko, kod pocztowy, miasto, kraj.

Problem: dane od użytkowników są brudne. Email z wielką literą, telefon raz z +48, raz z 0048, raz sam numer. Meta wymaga konkretnego formatu — jakiekolwiek odchylenie oznacza brak dopasowania.

Zmienna CJS: Przechwycenie i normalizacja emaila

function() {
  // Dwa źródła: zalogowany użytkownik vs gość przy składaniu zamówienia
  var visitorEmail = {{DLV - customerBillingEmail}};
  var orderEmail = {{DLV - orderData Email}};

  // Priorytet: dane z zamówienia (świeższe), fallback na dane zalogowanego
  var rawEmail = orderEmail || visitorEmail;

  if (typeof rawEmail === 'undefined' || rawEmail === null || rawEmail === '') {
    return undefined;
  }

  // Normalizacja: trim + lowercase (wymóg Meta i Google)
  var cleanEmail = String(rawEmail).trim().toLowerCase();

  // Walidacja bazowa — jeśli nie wygląda jak email, nie wysyłaj
  if (cleanEmail.indexOf('@') === -1 || cleanEmail.indexOf('.') === -1) {
    return undefined;
  }

  return cleanEmail;
}

Dwa źródła danych to kluczowy element. Jeśli użytkownik jest zalogowany — mamy jego email od razu, jeszcze przed zakupem. Jeśli kupuje jako gość — email pojawia się dopiero na etapie formularza zamówienia. Zmienna automatycznie wybiera najświeższe dostępne dane.

Ważne: a co z bezpieczeństwem danych? Zmienna przygotowuje czysty tekst (lowercase, trim, walidacja) ale nie wysyła go w takiej formie do platform reklamowych. Odpowiedni tag na serwerze (w tym przypadku Stape Data Tag) automatycznie hashuje te wartości algorytmem SHA-256 przed wysłaniem ich do Meta, Google Ads czy TikToka. Platformy reklamowe nigdy nie otrzymują plain-text PII — wyłącznie zahashowane identyfikatory, na podstawie których dopasowują użytkowników. To wymóg zarówno Meta CAPI, jak i Google Enhanced Conversions, i jednocześnie gwarancja zgodności z RODO.

Największe wyzwanie: numery telefonów

Analogiczne zmienne CJS powstały dla każdego parametru użytkownika - telefon, imię, nazwisko, kod pocztowy, miasto, kraj. Najtrudniejszy był telefon. Meta wymaga samego kodu kraju i numeru, całkowicie oczyszczonego ze znaków specjalnych, spacji i plusów (np. 48111222333). Google Ads ma do tego inne podejście. A użytkownicy wpisują:

• 501 234 567

• +48 501-234-567

• 0048501234567

• 48501234567

• 501234567

Dedykowane zmienne CJS normalizują każdy z tych wariantów do wymaganego formatu. Osobno dla Mety, osobno dla Google Ads.

Deduplikacja zdarzeń: event_id

W konfiguracji Meta z Conversions API zdarzenia wysyłane są podwójnie, raz z przeglądarki (Pixel), raz z serwera (CAPI). To celowe - redundancja zwiększa pokrycie. Meta deduplikuje je na swojej stronie na podstawie event_id.

Każde zdarzenie dostaje unikalny identyfikator generowany po stronie klienta (w GTM Web), który jest wysyłany zarówno z Pixelem, jak i przez CAPI. Meta widzi dwa zdarzenia z tym samym event_id i liczy je jako jedno.