Server-Side Tagging dla Meta CAPI - krok po kroku.

Pixel Meta to JavaScript uruchamiany w przeglądarce użytkownika. Po iOS 14.5 Apple zaczął blokować śledzenie między aplikacjami. iOS 17 poszedł dalej - Private Click Measurement i Link Tracking Protection usuwają parametry UTM i identyfikatory ze wszystkich linków otwieranych w Safari, Mail i iMessage. Skutek: zdarzenia z urządzeń Apple nie docierają do Meta w pełni.

Według danych z audytu producenta mebli skandynawskich (obrót ~10M PLN rocznie, marża 15%), w kwietniu 2025 roku Event Match Quality wynosił 4/10. To oznacza, że Meta matchowało zdarzenie zakupu z profilem użytkownika w mniej niż połowie przypadków. Przy takim EQS algorytm optymalizuje kampanie pod sygnał, który nie opisuje rzeczywistych kupujących.

Pixel po stronie przeglądarki traci dane z trzech powodów jednocześnie: blokery reklam odrzucają request do facebook.com, Safari ITP (Intelligent Tracking Prevention) kasuje ciasteczka _fbp po 7 dniach, a iOS 17 Link Tracking Protection usuwa fbclid z URL jeszcze zanim strona się załaduje. Każdy z tych mechanizmów działa niezależnie - razem dają dziurę w danych rzędu 25–35%.

Server-Side Tagging (SST) przenosi logikę tagowania z przeglądarki użytkownika na serwer kontrolowany przez Ciebie. Zamiast wysyłać zdarzenie bezpośrednio z JavaScript do Meta, przeglądarka wysyła request na Twój własny endpoint (np. data.twojadomena.pl). Serwer GTM odbiera zdarzenie, wzbogaca je o dane z backendu (np. wartość zamówienia, e-mail, telefon z bazy klientów) i dopiero wtedy przekazuje do Meta przez Conversions API.

Conversions API (CAPI) to interfejs server-to-server. Meta nie może go zablokować przez AdBlock, ITP ani Link Tracking Protection - request idzie z serwera, nie z przeglądarki. Jednocześnie możesz wysyłać do CAPI dane, których Pixel nigdy nie miał dostępu: zahaszowany e-mail, telefon, adres dostawy. To właśnie podnosi EQS.

Warstwa 1 - GTM Web Container

Standardowy Pixel Meta pozostaje, ale zamiast wysyłać do facebook.com, przekierowujesz zdarzenia na serwer GTM przez Data Client. Pixel nadal zbiera fbclid i _fbc z URL (jeśli użytkownik kliknie reklamę przed ITP), ale te dane trafiają na Twój serwer, nie bezpośrednio do Meta.

Warstwa 2 - GTM Server Container

Serwer GTM hostowany na Cloudflare Workers lub Google Cloud Run odbiera zdarzenia, łączy je z danymi z backendu (CRM, platforma e-commerce) i buduje pełny payload dla CAPI - z zahaszowanym e-mailem, telefonem, external_id i event_id do deduplikacji.

Warstwa 3 - Meta CAPI

Wzbogacony event trafia do Meta przez Graph API. Deduplikacja event_id zapobiega liczeniu tego samego zakupu dwa razy (raz z Pixel, raz z CAPI).

Poniższy harmonogram oparty jest na rzeczywistym wdrożeniu dla producenta mebli skandynawskich. Łączny czas: 16 godzin dev + 4 godziny strategist. Wszystkie kroki zakładają istniejący GTM Web Container i konto Meta Business Manager z dostępem do Pixel.

Krok 1 - Postaw serwer GTM (2 godz.)

Utwórz nowy GTM Server Container. Cloudflare Workers to 90 zł/mies. przy ruchu do 10M requestów - wystarczające dla sklepu do 50K sesji/mies. Alternatywa: Google Cloud Run (pay-per-use, ok. 60–120 zł/mies. zależnie od ruchu). Skonfiguruj subdomenę data.twojadomena.pl i wskaż ją na serwer GTM. Własna subdomena to klucz - zapobiega blokowaniu przez filtry anty-trackingowe na poziomie DNS.

Krok 2 - Przekieruj Web Container na serwer (3 godz.)

W GTM Web Container dodaj tag Meta Pixel z Transport URL ustawionym na https://data.twojadomena.pl. Zdarzenia z przeglądarki trafią teraz na Twój serwer, nie bezpośrednio do Meta. Dodaj Data Layer Push dla kluczowych zdarzeń: PageView, ViewContent, AddToCart, InitiateCheckout, Purchase. Dla Purchase wrzuć do Data Layer: order_id, wartość, walutę, e-mail klienta (zahaszowany SHA-256 po stronie front-end lub surowy - serwer zahaszuje).

Krok 3 - Skonfiguruj Server Container i CAPI Tag (6 godz.)

W GTM Server Container dodaj klienta Meta Pixel - będzie odbierać zdarzenia z Web Container. Dodaj tag Meta Conversions API. W konfiguracji tagu ustaw Access Token z Meta Business Manager (Pixel → Ustawienia → Conversions API → Wygeneruj token). Kluczowe pola do mapowania: event_id (użyj order_id + timestamp dla Purchase - to baza deduplikacji), user_data.em (zahaszowany e-mail), user_data.ph (zahaszowany telefon), user_data.external_id (ID klienta z CRM). Deduplikacja działa na podstawie event_name + event_id - jeśli Meta dostanie dwa eventy Purchase z tym samym event_id w ciągu 48 godzin, zliczy tylko jeden.

Krok 4 - Testy i weryfikacja EQS (5 godz.)

Użyj Meta Test Events Tool (Pixel → Test Events) - wyślij zakup testowy i sprawdź, czy CAPI odbiera event z poprawnymi user_data. Sprawdź Event Match Quality w Pixel → Overview - wzrost EQS widoczny jest w ciągu 24–48 godzin od pierwszych prawdziwych zdarzeń. Cel: EQS ≥ 7/10. Pełne matchowanie e-mail + telefon + fbclid pozwala zejść wyżej. Uruchom GTM Preview Mode na Web Container i Server Container jednocześnie - zweryfikuj, że event_id w obu jest identyczny (deduplikacja).

RODO: serwer GTM działa na infrastrukturze, którą kontrolujesz. Dane osobowe (e-mail, telefon) haszujesz po stronie serwera przed wysłaniem do Meta - Meta otrzymuje SHA-256, nie surowe PII. Cloudflare Workers domyślnie procesuje dane w regionie EU, jeśli ustawisz Workers Route na europejskim datacenter. Zaktualizuj politykę prywatności o informację o CAPI i dołącz do umów z dostawcami (Cloudflare, Google) stosowne DPA.

Przed wdrożeniem sprawdź 3 rzeczy:

1. czy platforma e-commerce wystawia order_id w Data Layer przy zdarzeniu Purchase - bez tego deduplikacja nie zadziała;
2. czy masz zgodę użytkownika na marketing w Consent Mode v2 - SST nie zwalnia z obowiązku zbierania zgód;
3. czy Pixel i CAPI mają ten sam Pixel ID - tagi z różnymi ID nie deduplikują się nawzajem.