W dobie dużego nacisku na ochronę danych osobowych i co raz nowszych regulacji związanych z prywatnością użytkowników w przeglądarkach internetowych wprowadzane jest coraz więcej ograniczeń związanych z ciasteczkami 3rd party.
W kontekście Meta znakomitym przykładem takiego działania jest Apple, które wprowadziło znaczne ograniczenia dla ciastek 3rd party w przeglądarce Safari skracając ich okres żywotności do zaledwie 7 dni. Jest to znaczne ograniczenie w prowadzeniu i optymalizacji działań marketingowych.
Wydaje się, że regulacje prawne będą dalej dążyć w tym kierunku, a dostawcy technologii będą musieli się do tych regulacji dostosowywać.
Jeżeli dodamy do tego jeszcze dość sporą adopcję ad blocków w Polsce, za moment okaże się, że nasze działania marketingowy i analityczne oparte są na ułamku rzeczywistych danych.
Meta Conversion API - co, dlaczego, jak? - przewodnik krok po kroku

Odpowiedzią na te ograniczenia może być wdrożenie technologi śledzenie server - side, o której możecie przeczytać więcej w kilku dostępnych u nas na blogu artykułach:
Czym jest Meta Conversion API?
W kontekście Meta Ads żeby stawić czoła opisanym wyżej wyzwaniom z pomocą przychodzi nam Meta Conversion API zwane potocznie CAPI.
W założeniu CAPI ma na celu stworzenie bezpośredniego i bardziej niezawodnego połączenia pomiędzy danymi pochodzącymi z własnych systemów ( witryna, aplikacja, CRM) a panelem Meta.
To połączenie w teorii może odbywać się z pominięciem przeglądarki, czyli bez polegania na ciasteczkach 3rd party jak ma to miejsce w przypadku pixela. Co za tym idzie pozwala to na przesyłanie znacznie szerszego zakresu zdarzeń, niż tylko interakcje ze strony, gdyż możemy rozszerzyć śledzenie, np. o interakcje pochodzące z CRM opisujące statusy zamówienia.
Brzmi super prawda?
Niestety w praktyce jest to dość skomplikowany proces. Faktycznie jest możliwe wdrożenie Meta Conversion Api z pominięciem przeglądarki ale musimy wziąć pod uwagę fakt jak skomplikowane może być to wdrożenie.
- wymaga zakodowania przez developer wysyłania zdarzeń do Meta po stronie backendu lub serwera
- wymaga przekazania identyfikatora klienta, który nawet dla zalogowanych klientów może nie być łatwo dostępny, a dla niezalogowanych musi i tak zostać przekazany z przeglądarki (ciastka: _fbp oraz _fbc)
- wymaga respektowania zasad ochrony danych osobowych, czyli pomimo tego że do Mety część identyfikatorów jak np. mail przekazywanych jest w sposób zahashowany (sha 256), to i tak musimy mieć na to zgodę użytkownika
Natomiast nadal możemy wdrożyć Meta Conversion API z udziałem przeglądarki czyli wykorzystaniem śledzenia client-side oraz śledzenia za pomocą GTM server-side, a wyniki są więcej niż zadowalające.

Powyższy przykład to tylko jeden z wielu, gdzie wdrożenie CAPI przyczyniło się do wzrostu raportowanych w panelu Meta Ads konwersji.
Jak działa Meta Conversion API za pomocą server-side GTM?

Zasada działania Meta Conversion API przy wdrożeniu z wykorzystaniem GTM server-side opiera się na założeniach GTM server-side.
Dane zostają przesłane do naszego serwera tagowania za pomocą tagu GA4, a następnie z serwera tagowania z wykorzystaniem dedykowanego szablonu Conversion API tagu przekazane do dedykowanego konta Meta Ads.
Metoda ta zakłada że po stronie klienta zostanie uruchomiony pixel, który wysyła dane do tego samego konta Meta Ads. Dzięki temu po stronie klienta zostanie utworzony identyfikator klienta przechowywany w ciasteczku _fbp, który przekazujemy jako parametr w tagu GA4 wysyłającym dane do serwera tagowania. Ta wartość jest następnie przekazywana tagiem CAPI to Mety, dzięki czemu możliwa jest identyfikacja użytkownika.
Przy optymalnym wdrożeniu wszystkie zdarzenia do Mety wysyłane są zarówno za pomocą Pixela jak i Conversion API. Powinny one posiadać parametr event id na podstawie którego w panelu Mety zostaną one zdeduplikowane.

Dlaczego warto wdrożyć Meta Conversion API?
W tym momencie powinno pojawić się pytanie po co wdrażać CAPI tą metodą, skoro praktycznie jest to tylko dłuższa ścieżka wysłania tych samych danych, które zbierze Pixel?

Tym razem inny przykład, który ma na celu zobrazowanie, że warto to robić. Jest to dosyć skrajny przykład, ale średnia uzysku z wdrożenia CAPI to około 20% dla zdarzenia zakupu.
Dzieje się tak, bo finalnie dane zebrane za pomocą Meta Conversion API nie są tymi samymi danymi, które zbierze Pixel - oczekuje się że jest ich więcej.
Wiele zależy tutaj od konfiguracji naszego serwera tagowania, tego czy zintegrujemy z nim własną domenę oraz czy wdrożmy śledzenie w trybie first party mode (artykuł o first party mode w drodze 😊).
Dane wysyłane do serwera potrafią “oszukać” nieprzyjazną przeglądarkę lub ad-block’a, że nie są to żądania wysyłane do 3rd party, tylko żądania wysyłane do naszego własnego serwera. W związku z tym dużo większa liczba tych żądań nie zostaje zablokowana a zebranych danych jest więcej.

Oprócz tego dane zbierane przez Conversion API są lepszej jakości.
Przy wdrożeniu możemy wykorzystać dużo trwalsze ciasteczka GA, które przekażemy do Mety jako dodatkowy identyfikator użytkownika wykorzystywany do powiązania aktywności z wcześniejszymi interakcjami.
Poza tym z poziomu serwera tagowania możemy ustawić cookie _fbp w kontekście first party, co zdecydowanie zwiększy jego żywotność.
Jeżeli chcesz dowiedzieć się wiedzieć więcej zapraszamy na nasze szkolenie server-side tracking, na którym w praktyce przechodzimy przez całe wdrożenie CAPI: https://bettersteps.pl/szkolenie-server-side-gtm
A jeśli chciałbyś wdrożyć Meta Conversion API dla swojej strony, a nie czujesz się na siłach zapraszamy do kontaktu.