Pomiar konwersji w sklepie: z 35 procent pokrycia zdarzeń do niemal pełnego

Kto to był i co go bolało

Sklep internetowy z branży beauty, który co miesiąc wydaje realny budżet na reklamy w Meta. Problem było widać gołym okiem: liczba zakupów raportowanych przez pixel nijak nie zgadzała się z tym, co pokazywał sam sklep. Meta widziała mniej więcej jedną trzecią konwersji. Reszta przepadała.

To nie jest wyłącznie kwestia ładnych raportów. Algorytm Meta uczy się na zdarzeniach, które faktycznie dostanie. Jeżeli dostaje co trzecie, optymalizuje kampanie na podstawie wycinka rzeczywistości i wydaje pieniądze tam, gdzie nikt świadomie by ich nie wydał. Klient płacił więc podwójnie: raz za brak danych, drugi raz za gorsze decyzje algorytmu.

Do tego dochodziły trzy rzeczy, które trzeba było rozwiązać razem, a nie po kolei. Pixel odpalał się, zanim użytkownik cokolwiek kliknął w oknie zgód. To jest jednocześnie ryzyko kary i dane, których Meta i tak nie może użyć - czyli najgorszy możliwy układ. Druga sprawa: zdarzenia z przeglądarki i z serwera musiały mieć wspólne identyfikatory, bo inaczej ten sam zakup liczy się dwa razy i przychód w raportach rośnie wyłącznie na papierze. Trzecia: zdarzenia serwerowe leciały z ubogim zestawem danych, przez co panel Meta zaniżał ocenę jakości dopasowania.

Co zrobiliśmy

Zaczęliśmy od policzenia, ile w tym sklepie faktycznie wynosi odsetek zgód. Okazało się, że pokrycie zdarzeń było w praktyce równe temu odsetkowi. Przyczyna nie leżała więc w kodzie zdarzeń, tylko w ich kolejności - pixel strzelał za wcześnie, a Meta te zdarzenia odrzucała.

Wdrożyliśmy bramkę zgody symetrycznie na obu kanałach. Warstwa przeglądarkowa stoi na Google Tag Manager, warstwa serwerowa na server-side GTM postawionym na Stape, a o tym, co i kiedy wolno wysłać, decyduje Consent Mode v2 razem z platformą zgód. Po udzieleniu zgody zdarzenia z okresu sprzed decyzji wysyłane są ponownie, w tej samej postaci po stronie pixela i po stronie Conversions API.

Żeby to samo zdarzenie nie policzyło się dwa razy, ustawiliśmy wspólne, stabilne identyfikatory. Zakup rozpoznajemy po numerze transakcji ze sklepu, a nie po losowym ciągu generowanym przy każdym odświeżeniu strony. Dzięki temu Meta skleja parę przeglądarka plus serwer w jedno zdarzenie, a przychód w raportach zgadza się z rzeczywistością.

Na koniec zajęliśmy się jakością danych. Do zdarzeń serwerowych dołożyliśmy identyfikatory użytkownika, które sklep i tak posiada, i wycięliśmy zdarzenia-śmieci: ruch botów, podglądy i przypadkowe przeładowania koszyka.

Jak to działa dzisiaj

Całość zajęła około tygodnia. Dzisiaj sklep obsługuje sześć standardowych zdarzeń Meta równolegle w przeglądarce i na serwerze. Pomiar nie rusza, dopóki użytkownik nie podejmie decyzji w oknie zgód, a kiedy zgodę wyrazi, nic z jego wizyty nie ginie - zaległe zdarzenia dosyłamy.

Każde zdarzenie ma jeden identyfikator wspólny dla obu kanałów, więc Meta usuwa duplikaty sama i przychód liczy się raz. Dane użytkownika lecą wzbogacone, a strumień jest odszumiony, więc panel Meta ocenia jakość dopasowania wyżej niż przed zmianą. Marketing patrzy na te same liczby co księgowość, co jest niską poprzeczką, ale wcześniej nie była spełniona.

Co z tego wyszło

Pokrycie standardowych zdarzeń Meta wzrosło z około 35 procent do niemal pełnego. Wszystkie sześć standardowych zdarzeń działa w obu kanałach naraz. Pomiar jest zgodny z RODO, bo nic nie wychodzi bez zgody. Jakość dopasowania danych w panelu Meta poszła w górę.

Co zrobilibyśmy inaczej

Straciliśmy pierwszy dzień na szukanie błędu w kodzie zdarzeń, bo założyliśmy, że skoro pokrycie jest niepełne, to coś się po prostu nie wysyła. Wystarczyło od razu zestawić procent pokrycia z odsetkiem zgód - liczby były praktycznie identyczne i od razu wskazywały winnego. Dzisiaj to pierwsza rzecz, którą sprawdzamy w każdym audycie pomiaru.

Drugą rzecz, czyli odsianie zdarzeń-śmieci, potraktowaliśmy na początku jak kosmetykę i zostawiliśmy na koniec. Okazało się, że to właśnie one najmocniej ciągnęły w dół ocenę jakości dopasowania. Przy kolejnym takim wdrożeniu zaczynamy od przejrzenia surowego strumienia zdarzeń, zanim w ogóle dotkniemy konfiguracji zgód.