Conversions API i Server-Side Tracking - po co i jak wdrożyć

1. Problem - co się stało po iOS 14.5

W kwietniu 2021 Apple wprowadził App Tracking Transparency (ATT) w iOS 14.5. Każda aplikacja, która chce trackować użytkownika między aplikacjami, musi prosić o jego zgodę dialogiem systemowym. 72-85% użytkowników klika „Ask App Not To Track".

Efekt dla marketingu:

• Facebook / Instagram tracą sygnał z ok. 35-50% użytkowników iOS
• Wszystkie platformy z piksel browser-side dotknięte (Meta, TikTok, Snap, Pinterest, Reddit)
• iOS ITP (Intelligent Tracking Prevention) blokuje third-party cookies całkowicie
• Safari ETP i Chrome (Privacy Sandbox) robią to samo w przeglądarce

W rezultacie klasyczny piksel Meta widzi tylko 50-70% rzeczywistych konwersji. Algorytm Meta uczy się na częściowych danych, optymalizuje błędnie, ROAS spada. To samo dotyczy Google Ads, TikTok i innych platform.

2. Czym jest Conversions API (CAPI)

Conversions API to mechanizm, w którym konwersje wysyłane są bezpośrednio z Twojego serwera do platformy reklamowej, pomijając przeglądarkę użytkownika.

Architektura:

• Klasyczny pixel browser-side: użytkownik kupuje → przeglądarka wysyła event do Meta → Meta loguje konwersję
• CAPI server-side: użytkownik kupuje → Twój serwer wysyła event do Meta API (przez HTTPS POST) → Meta loguje konwersję

Bo wysyłka idzie z serwera, nie z przeglądarki - iOS ATT, adblockery, ITP, ETP nie mają nic do gadania. Dane docierają zawsze.

Platformy z CAPI:

• Meta Conversions API - dla Facebook / Instagram Ads
• Google Ads API + Enhanced Conversions - dla Google Ads (od 2021)
• TikTok Events API - dla TikTok Ads
• Snapchat Conversions API
• Pinterest Conversions API
• LinkedIn Conversions API

3. Czym jest Server-Side GTM (sGTM)

Server-Side Google Tag Manager to Twój własny GTM hostowany na serwerze, działający jako proxy między przeglądarką użytkownika a platformami reklamowymi. Architektura:

1. Przeglądarka użytkownika wysyła event do Twojego sGTM (zwykle na subdomenę typu `gtm.twojadomena.pl`)
2. sGTM odbiera, waliduje, wzbogaca dane (np. dodaje user ID z bazy, hash emaila, IP)
3. sGTM przekazuje do Meta CAPI, Google Ads, TikTok Events API jednocześnie
4. Każda platforma loguje konwersję ze swoich kanałów

Przewaga sGTM nad standardowym CAPI:

• First-party cookies zamiast third-party - sGTM jest na Twojej domenie, więc cookies są first-party (nie blokowane)
• Bypass adblocków - sGTM URL nie jest na liście znanych trackerów
• Wzbogacenie danych - dodajesz dane z CRM, bazy klientów, analityki przed wysłaniem do platform
• Jedno źródło prawdy - wszystkie platformy dostają te same, ustandaryzowane dane
• Mniejsze obciążenie strony - jeden tag w przeglądarce, reszta na serwerze (szybsze ładowanie)

4. CAPI vs sGTM - co i kiedy

Sam CAPI (bez sGTM)

Wystarczy dla: małych e-commerce z gotową integracją (Shopify, WooCommerce z pluginem CAPI), startujących biznesów, sytuacji „pixel działa OK, chcę go uzupełnić”. Daje 80-90% korzyści sGTM przy 20% pracy wdrożeniowej.

sGTM z CAPI

Konieczny dla: średnich i dużych e-commerce z budżetami 30k+ PLN/mies., biznesów multi-market (jedna konfiguracja dla wielu rynków), wymagających pełnej kontroli nad danymi (RODO, dane wrażliwe), z developerem do dyspozycji. Inwestycja w sGTM zwraca się na średnich budżetach w 2-4 miesiące.

5. Wdrożenie CAPI - 4 ścieżki

Ścieżka 1: Native integration (Shopify, WooCommerce)

Najprostsza. Shopify ma natywną Facebook & Instagram Sales Channel z wbudowanym CAPI. Konfiguracja:

1. Zainstaluj Facebook & Instagram app w Shopify
2. Połącz z Business Manager Meta
3. W ustawieniach włącz „Conversions API" oraz „Maximum Data Sharing"
4. Czekaj 24-48h, sprawdź EMQ w Events Manager

Czas wdrożenia: 30 minut. Wymagany developer: 0.

Ścieżka 2: Plugin / hosted CAPI (Stape.io, Stagger)

Dla platform bez native integration (Magento, PrestaShop, custom). Stape.io oferuje hosted sGTM z gotowymi tagami CAPI:

1. Załóż konto Stape.io (~30-50 USD/mies za małe konto)
2. Wskazujesz subdomenę typu `gtm.twojadomena.pl`
3. Stape dostarcza container ID do GTM web
4. Konfigurujesz tagi w GTM (Meta CAPI, Google Ads, TikTok)

Czas wdrożenia: 4-8h. Wymagany developer: ewentualnie do DNS subdomeny.

Ścieżka 3: Self-hosted sGTM (Google Cloud)

Pełna kontrola, najtaniej długoterminowo. Google oferuje App Engine flex z dedicated sGTM image za ok. 50-150 USD/mies (zależnie od ruchu):

1. Załóż projekt Google Cloud
2. Wdróż sGTM Server Container w App Engine
3. Konfiguruj DNS subdomeny
4. Połącz z GTM web container i platformami reklamowymi

Czas wdrożenia: 1-2 dni. Wymagany developer: tak (DevOps / Cloud).

Ścieżka 4: Custom server-side endpoint

Dla zaawansowanych - własny endpoint w aplikacji, który łapie konwersje (np. webhook z payment provider) i wysyła do CAPI. Pełna kontrola, ale wymaga rozwoju aplikacji. Sensowne dla SaaS i niestandardowych aplikacji.

6. Event Match Quality - jak osiągnąć 7+

EMQ to wskaźnik 0-10 określający, jak dobrze platformy dopasowują zdarzenia CAPI do użytkowników. Cel: EMQ ≥ 7.0 dla zdarzeń purchase. EMQ poniżej 5 oznacza, że Meta nie dopasowuje większości zdarzeń, więc atrybucja jest błędna.

Parametry wpływające na EMQ:

• Email (hashed SHA-256) - +2.0 do EMQ (najwyższa waga)
• Telefon (hashed) - +1.5 do EMQ
• Imię + nazwisko (hashed) - +1.0
• Miasto + kod pocztowy - +0.5
• IP użytkownika - +0.5
• User agent - +0.3
• fbp + fbc cookies - +1.0 (browser ID)
• Click ID (fbclid, gclid) - +0.5

Jak zdobyć dane:

• Email + telefon - z formularza zakupu (musi być required)
• Adres + kod pocztowy - z dostawy
• IP + user agent - z requestu HTTP
• fbp / fbc - z cookies pierwszej wizyty (Meta pixel je ustawia)
• External ID (jeśli zalogowany użytkownik) - +1.0 do EMQ

Hashowanie:

WSZYSTKIE dane osobowe muszą być hashed SHA-256 przed wysłaniem do CAPI. Email → lowercase, trim, SHA-256. Telefon → tylko cyfry (+48...), SHA-256. Imię → lowercase, trim, SHA-256. Bez tego naruszasz RODO i platformy mogą zawiesić konto.

7. Deduplikacja - klucz do poprawnych danych

Gdy działa pixel browser-side ORAZ CAPI, to samo zdarzenie purchase wysyłane jest dwa razy. Bez deduplikacji Meta liczy 2x więcej konwersji niż faktycznie, atrybucja kłamie, ROAS jest fałszywie wysoki.

Mechanizm deduplikacji Meta:

• Każde zdarzenie musi mieć unique `event_id` (UUID lub order ID)
• Pixel browser-side wysyła event_id w paramerze `eventID` w `fbq()` call
• CAPI wysyła ten sam event_id w parametrze `event_id` w API request
• Meta dedupliuje na podstawie pary `event_name + event_id` w oknie 48h

Konfiguracja w GTM (web):

Pole „Event ID" w tagu Meta Pixel ustaw na: {{Event ID}} gdzie `{{Event ID}}` to zmienna z order ID (np. z dataLayer).

Konfiguracja w sGTM / backend:

W payload CAPI ustaw `event_id` na ten sam ID, który leci do pixela web. Najczęściej: order ID z systemu e-commerce.

Walidacja:

W Events Manager Meta → Test Events → wyślij testowy zakup. Powinieneś zobaczyć JEDEN event z dwoma źródłami: „Browser + Server". Jeśli widzisz dwa osobne eventy - deduplikacja nie działa.

8. Walidacja i monitoring

Tygodniowy checklist:

• EMQ ≥ 7.0 dla wszystkich kluczowych zdarzeń (Events Manager → Overview)
• Status zdarzeń: „Browser + Server" (nie samo „Browser" lub samo „Server")
• Liczba zdarzeń z CAPI w stosunku do Pixel: 80-120% (jeśli CAPI ma znacznie mniej - błąd w wysyłce; jeśli znacznie więcej - deduplikacja nie działa)
• Dataset Quality w Test Events: minimum „Good"

Co miesiąc:

• Porównaj liczbę purchase w Events Manager vs Shopify / Magento / CRM. Różnica powinna być < 10%.
• Sprawdź czy nowe zdarzenia (nowe produkty, nowe rynki) mają CAPI
• Audyt parametrów: czy email, telefon, adres są wysyłane (nie pomijane)

Najczęstsze problemy:

• EMQ poniżej 5 - brak hashowania, brak email/telefon, brak fbp cookie
• Brak deduplikacji - event_id niezgodny między pixel a CAPI
• Zdarzenia tylko browser - CAPI nie wysyła, błąd w konfiguracji / endpointzie
• RODO compliance - dane wysyłane bez hashowania, naruszenie