W artykule z zeszłego roku przedstawiłem na czym polega działanie Meta Conversion API, a dziś przedstawię krok po kroku jak wdrożyć CAPI samodzielnie.
Adam Brzostek
22.03.2026Czas czytania: 15:00
Meta Conversion API - kompletny przewodnik jak wdrożyć je samodzielnie 2026
Wymagania wstępne:
- Dostęp na poziomie publikacji do kontenera GTM po stronie klienta
- Dostęp na poziomie publikacji do kontenera GTM po stronie serwera
- Jeżeli nie mamy skonfigurowanego serwera tagowania zapraszam do zapoznania się najpierw z tym tym artykułem: https://bettersteps.pl/blog/praktyczny-poradnik-gtm-server-side-tagging-google-analytics-4 natomiast w przeciwieństwie do tego co opisywałem wcześniej w artykule, na podstawie zebranego doświadczenia rekomenduje skorzystanie z ręcznej konfiguracji, dla której Google dostarczył bardzo dobrą instrukcję: https://developers.google.com/tag-platform/tag-manager/server-side/cloud-run-setup-guide?provisioning=manual&hl=pl
- Przed konfiguracją koniecznie zapoznaj się z pułapkami jakie mogą na Ciebie czychać: https://bettersteps.pl/blog/pulapki-konfiguracji-gtm-server-side-w-technologii-google-cloud-run
- Idealnie jeżeli nasz serwer tagowania będzie miał zintegrowaną własną subdomenę, poradnik jak to zrobić dostępny jest tutaj: https://bettersteps.pl/blog/integracja-wlasnej-subdomeny-do-serwera-tagowania-w-google-cloud-platform-cloud-run
- Pełny dostęp do pixela w Meta Business Suite
- Jeżeli jest to możliwe przyda nam się dostęp administracyjny do całego konta, bo wtedy będziemy samodzielnie mogli wygenerować token dostępu. Natomiast możemy poprosić kogoś z taki dostępem o jego wygenerowanie - jest to bardzo proste.
- Dostęp do Google Analytics (administracyjny na zakresie konta lub do edycji na zakresie nowej dedykowanej usługi)
- Dane do serwera tagowania będziemy wysyłać za pomocą tagów GA4, dlatego warto utworzyć dedykowaną usługę, gdyż dzięki temu za jednym zamachem wdrożymy CAPI oraz śledzenie server-side GA4
Konfiguracja po stronie klienta
Z mojego artykułu o CAPI wiemy, że dane będziemy wysyłać dwutorowo: za pomocą pixela, czyli bezpośrednio po stronie klienta oraz za pomocą serwera, do którego również musimy przesłać dane ze strony klienta.
Jest to najbardziej skomplikowana część całego wdrożenia, natomiast jeżeli to skonfigurujemy prawidłowo to konfiguracja po stronie serwera pójdzie nam bardzo gładko.
Ten artykuł przeczytasz tylko po zapisaniu się do newslettera
Dołącz do newslettera Bettersteps żeby zobaczyć pełną treść artykułu kompletnie za darmo
Zapisując się z tego formularza otrzymasz dostęp do całego materiału oraz na maila link do pobrania gotowych plików jSON dla GTM WEB oraz GTM SERVER
Do wysyłania danych za pomocą pixela użyjemy autoryzowanego szablonu od Mety.
Natomiast do wysłania danych do serwera tagowania wykorzystamy tagi Google Analytics 4.
Zmienne
Zacznijmy od konfiguracji zmiennych, które będą nam potrzebne. Wszystkie znajdują się w jSONie udostępnionym tutaj:
Oprócz standardowych parametrów opisujących zdarzenia potrzebne nam będą:
cookie - Meta Browser ID - czyli ciasteczko 1st party tworzone przez kod pixela facebooka identyfikujące konkretnego użytkownika - przesłanie tej informacji jest konieczne do deduplikacji i dopasowania danych w systemie Meta.
cookie - Meta Click ID - czyli ciasteczko 1st party tworzone przez kod pixela facebooka identyfikujące konkretne kliknięcie reklamy - przesłanie tej informacji jest konieczne do deduplikacji i dopasowania danych w systemie Meta.
cjs - Meta unique event ID - unikalny identyfikator zdarzenia, który wykorzystamy do deduplikacji zdarzeń.
Zmienna to to moja autorska twórczość. Składa się ona z połączenia nazwy eventu, identyfikatora ciasteczka Mety oraz timestamp’u zdarzenia pomniejszonego o ostatnie cztery cyfry - jest to bardzo kluczowy zabieg, gdyż aby deduplikacja działała prawidłowo wartość tej zmiennej musi być identyczna gdy jest przekazywana pixelem oraz tagiem GA4. Mimo, że teoretycznie obydwa tagi uruchamiają się w tym samym momencie to w rzeczywistości działają asynchronicznie i czas uruchomienia różni się o ułamki sekund stąd takie działanie. Kod do skopiowania dostępny jest tutaj:
function() {
var event_timestamp = Date.now();
var event_id = {{Event}} + '_' + {{cookie - Meta Browser ID}} + '_' + event_timestamp;
var len = event_id.length;
return event_id.substring(0,len - 4);
}
const - Meta Pixel ID - stała przechowująca id naszego pixela.
const - server container url - stała przechowująca adres naszego serwera tagowania.
const - server GA4 id - id pomiaru usługi GA4 dla danych przesyłanych przez serwer.
Zmienne konfiguracji
Oprócz tego dla ułatwienia będziemy korzystać ze zmiennych konfiguracji. Pomogą nam one w przyszłości zarządzać zmianami, ale ułatwią nam również sam proces tagowania.
Konfiguracja GA4 server - zmienna konfiguracji GA4 dla łatwego zarządzania zmianami tagowania w przyszłości.
Konfiguracja zdarzeń GA4 server - zmienna konfiguracji zdarzeń GA4 dla łatwego zarządzania zmianami tagowania w przyszłości.
W obydwu zmiennych deklarujemy parametry wspólne dla wszystkich zdarzeń wysyłanych do Mety przez serwer za pomocą CAPI:
- server_container_url - url naszego serwera tagowania
- x-fb-ck-fbp - identyfikator ciasteczka Mety
- x-fb-ck-fbc - identyfikator kliknięcia Mety
- event_id - identyfikator zdarzenia do deduplikacji
Bardzo ważne jest, żebyśmy użyli tego konkretnego nazewnictwa, gdyż takie jest wymagana i autmatycznie przetwarzane przez Metę.
W moim pliku jSON wszystkie powyższe zmienne są już skonfigurowane, ale należy pamiętać o zmianie wartości parametrów konfiguracyjnych:
- const - Meta Pixel ID
- const - server container url
- const - server GA4 id
Oprócz tego w pliku znajdują się też standardowe zmienne ecommerce oraz zmienne javascript w formacie wymaganym przez Facebooka.
Implementacja pixela Mety
W tym przewodniku posłużymy się przykładem zdarzenia add_to_cart, ale w analogiczny sposób możemy otagować każde zdarzenie.
Podstawowy tag Meta
Zaczynamy od wdrożenia podstawowego tagu odsłony.
Deklarujemy id naszego pixela, które przechowywane jest we wcześniej utworzonej zmiennej.
Wybieramy standardowe zdarzenie PageView.
W sekcji więcej ustawień deklarujemy identyfikator zdarzenia, który ponownie już wcześniej utworzyliśmy.
Musimy pamiętać o ustawieniu uruchamiania tagu raz na stronę oraz o ustawieniu wymaganych zgód, ale o tą kwestię rozwiniemy w dedykowanej sekcji.
Wysłanie zdarzenia
Do wysłania zdarzenia korzystamy z tego samego szablonu tagu. Rekomenduje się korzystanie ze standardowych zdarzeń, których listę i wymagane parametry znajdziemy tutaj: https://developers.facebook.com/docs/meta-pixel/reference/.
Ale oczywiście szablon daje nam możliwość wysłania również zdarzenia niestandardowego.
W naszym przypadku będzie to jednak zdarzenie standardowe o nazwie AddToCart.
Jedynymi zmianami względem podstawowego tagu jest dodanie wymaganych parametrów w sekcji Object Properties oraz dodanie zabezpieczenia, które uruchomi tag podstawowy przed tagiem zdarzenia, gdyby tamten nie wczytał się wcześniej. Ponieważ ustawiliśmy jego uruchamianie raz na stronę nie ma ryzyka, że dojdzie do zduplikowanego uruchomienia i zliczenia odsłony.
W analogiczny sposób możemy wdrożyć śledzenie każdego zdarzenia.
Przy zdarzeniu purchase jak event id najlepiej będzie wykorzystać identyfikator transakcji
Wysłanie danych do serwera tagowania
Skoro nasz pixel Meta odbiera już prawidłowo dane ze strony ze wszystkimi parametrami potrzebnymi do deduplikacji danych odebranych przez CAPI możemy przystąpić do właściwej części konfiguracji.
Do naszego serwera tagowania za pomocą tagów GA4 musimy wysłać wszystkie zdarzenia z wymaganymi parametrami, które wcześniej wdrożyliśmy za pomocą pixela.
Podstawowy Tag Google
Zaczniemy od wdrożenie podstawowego tagu Google, który obsłuży zdarzenie odsłony.
Konfiguracja jest bardzo prosta.
Jako identyfikator pomiaru deklarujemy wcześniej utworzoną zmienną.
W sekcji Zmienna ustawień konfiguracji wybieramy skonfigurowaną przez nas zmienną.
W Opcjach uruchamiania tagu wybieramy Raz na stronę.
Ponieważ w naszym założeniu tag konfiguracji wysyła zdarzenie page_view, dlatego bardzo ważne jest, żeby użyć dokładnie tej samej reguły, która była użyta dla podstawowego tagu pixela. Jest to istotne ze względu na deduplikacje zdarzeń w Mecie, na podstawie identyfikatora zdarzenia, które składa się między innymi z timestampu.
Wysłanie zdarzenia
Do wysłania zdarzenia korzystamy z tagu zdarzenia Google Analytics 4.
Konfiguracja również jest bardzo prosta.
Ponownie jako identyfikator pomiaru deklarujemy wcześniej utworzoną zmienną.
W sekcji Zmienna ustawień zdarzeń wybieramy skonfigurowaną przez nas zmienną.
W parametrach zdarzenia oprócz standardowych parametrów ecommerce przekazujemy zmienne, analogiczne do tych przekazanych w tagu pixela.
W przypadku zdarzeń wywoływanych jednocześnie z odsłoną warto dodatkowo zabezpieczyć się poprzez uruchomienie tagu konfiguracji GA4 przed tagiem zdarzenia - dzięki temu że, był on ustawiony aby uruchamiać się raz na stronę nie grozi nam sytuacja, że uruchomi się zbyt wiele razy.
W analogiczny sposób wdrażamy każde zdarzenie.
W przypadku zdarzenia purchase powinniśmy nadpisać parametr event id ze zmienne konfiguracji zdarzeń dodają ten parametr w konfiguracji tagu z wartością identyfikatora zamówienia.
Przesłanie danych z serwera do Mety
Aby wysłać odebrane przez serwer tagowania dane do naszego konta w Mecie skorzystamy z tagu Conversion API Tag od facebookincubator.
Zmienne
Potrzebujemy utworzyć dwie stałe:
const - Meta Pixel ID - stała przechowująca id naszego pixela - identycznie jak w kontenerze po stronie klienta.
const - Meta Access Token - stała przechowująca id Tokena dostępu do API.
Jak wygenerować token dostępu CAPI
Wygenerowanie tokena dostępu Conversion API może zrobić tylko administrator Meta Busines Suite.
Robi się to z poziomu menadżera zdarzeń.
Należy wejść w źródła danych - > pixel - > ustawienia, a nastepnie kliknąć przycisk Wygeneruj token dostępu.
Po wygenerowaniu tokena musimy go zapisać, gdyż po zamknięciu strony zniknie on bezpowrotnie.
Konfiguracja Tagu
Przy poprawnej konfiguracji po stronie klienta w większości przypadków nie musimy za wiele zmieniać w konfiguracji.
Deklarujemy Pixel ID oraz API Access Token za pomocą utworzonych przez nas zmiennych.
Zaznaczamy opcje Extend Meta Pixel cookies.
Dodajemy odpowiednią regułę / reguły uruchamiającą tag dla zdarzeń, które chcemy obsłużyć za pomocą CAPI.
W przypadku standardowych zdarzeń ecommerce nasz tag sam zmapuje nazwy zdarzeń na te oczekiwane przez Metę.
Dla innych zdarzeń możliwe, że będziemy musieli dodać transformację, żeby nazwy zdarzeń pasowały do taksonomi, która jest rekomendowana dla Pixela, ale możemy zadeklarować odpowiednie nazwy od razu po stronie klienta.
Debugowanie
Aby przetestować poprawność działania CAPI do naszego tagu musimy dodać kod testowy zdarzenia.
Znajdziemy go w źródła danych - > odpowiedni pixel - > testowanie zdarzeń.
Kopiujemy go i wklejamy w odpowiednie miejsce.
Pamiętajmy, że przed publikacją obszaru roboczego musimy usunąć ten parametr.
W tym momencie możemy włączyć tryb podglądu zarówno w kontenerze po stronie klienta jak i w kontenerze po stronie serwera.
Oczekujemy, że w tym samym momencie uruchomi się zarówno tag pixela jak i tag zdarzenia GA4, który wysyła dane do serwera.
W podglądzie kontenera po stronie serwera w zakładce Tags powinniśmy zobaczyć uruchomiony tag CAPI.
Natomiast ważniejsza jest zakładka Requests. Oczekujemy tam wychodzącego żądania do facebooka z kodem 200 - wtedy oznacza to, że żądanie wysłało się prawidłowo.
Na sam koniec powinnismy sprawdzić zdarzenie w menadżerze zdarzeń Meta. Dzięki temu możemy potwierdzić, czy odbieranie i deduplikacja zdarzeń działa prawidłowo.
Jeżeli wszystko działa jak należy to możemy opublikować nasze obszary robocze zarówno w GTM client side jak i GTM serwer side,
Po kilku dniach od publikacji implementacji, w menadżerze zdarzeń będziemy mogli sprawdzić jakość naszej deduplikacji.
System powinien wykryć i wskazać nam czy potrzebna jest poprawka.
Zarządzanie zgodami consent mode
Ostatnią kwestią do omówienia jest zarządzanie zgodami uruchamiania tagów.
Tagi Mety niezależnie czy są to tagi pixela czy CAPI wymagają zgody ad_storage.
W przypadku pixela jest to naturalnie proste do ustawienia.
W przypadku tagów CAPI nie jest to tak oczywiste.
Najprościej jest ustawić wymóg zgody do tagów GA4 po stronie klienta.
Natomiast rozwiązanie to nie sprawdzi się, gdy tych samych tagów używamy do śledzenia GA4 serwer-side i to w trybie advanced consent mode.
W takiej sytuacji tworzę zmienną w GTM client side przechwytującą status zgody ad_storage i dodaje dodatkowy parametr do obydwu zmiennych konfiguracji.
W GTM serwer side tworzę zmienną odczytującą tą wartość.
I używam jej, żeby uwarunkować uruchamianie tagów CAPI.
Jak korzystać z plików jSON
Pliki zostały stworzone dla następujących zdarzeń:
- page_view
- view_item
- add_to_cart
- begin_checkout
- purchase
Oprócz tego dla śledzenia GA4 znajdują się tam tagi dla:
- view_cart
- add_payment_info
- add_shipping info
Pliki są stworzone dla standardowej struktury Data Layer enhanced ecommerce
GTM client side
- Zaimportuj kontener
- Zaktualizuj zmienne
- const - GA4 id - server
- const - server-side url
- const - Meta Pixel ID
- Zaktualizuj zmienną cjs - localStorage.ad_storage tak aby przechwytywała wartość zgody ad_storage dla CMP, którego używasz - może być konieczne stworzenie kodu, który pobiera tą zmienną
GTM server side
- Zaimportuj kontener
- Zaktualizuj zmienne
- const - Meta CAPI Token
- const - Meta Pixel ID
Po pozytywnem debugu opublikuj obydwa kontenery.
Nie dostałeś plików jSON? Spróbuj jeszcze raz tutaj: https://bettersteps.pl/meta-conversion-api-sign-up
Zaobserwuj nasze profile, żeby nie przegapić innych ciekawych materiałów:
