Piksel zainstalowany w przeglądarce widzi już tylko część waszych konwersji. Blokery reklam, odmowa zgody, ograniczenia przeglądarek dotyczące ciasteczek zewnętrznych: strata jest strukturalna i pogłębia się. API konwersji istnieje po to, żeby ją zrównoważyć, pod warunkiem poprawnego wdrożenia.
Dwa kanały
Piksel przeglądarkowy wykonuje się u odwiedzającego. Przechwytuje pełny kontekst: identyfikatory reklamowe, ciasteczka, zachowanie podczas przeglądania. Zostaje zablokowany, gdy tylko wkroczy bloker, rozszerzenie albo odmowa zgody.
API konwersji wysyła zdarzenie z waszego serwera do platformy, z pominięciem przeglądarki. Nie jest blokowane, ale dysponuje wyłącznie tym, co mu przekażecie, i jest ślepe na ścieżkę nawigacji.
Oba nie są alternatywami. Zalecana konfiguracja uruchamia je razem na tych samych zdarzeniach, z mechanizmem deduplikacji.
Deduplikacja
To centralny punkt techniczny i ten, który wdrożenia najczęściej psują.
Jeśli zakup zostanie wysłany przez piksel i przez API bez mechanizmu dopasowania, platforma policzy dwie konwersje. Wasze raporty pokażą podwójny wolumen, koszt pozyskania będzie wyglądał na połowę rzeczywistego, a wasze decyzje reklamowe będą się opierać na fałszywych liczbach.
Dopasowanie opiera się na dwóch wartościach, które muszą być ściśle identyczne w obu wysyłkach: nazwa zdarzenia i unikalny identyfikator wygenerowany dla tego wystąpienia.
Trzy zasady praktyczne. Identyfikator trzeba wygenerować po stronie serwera i dopiero przekazać do piksela, nie odwrotnie. Musi być stabilny przy przeładowaniu strony, co wyklucza losowanie przy każdym wyświetleniu: numer zamówienia to najlepszy kandydat przy zakupie. I musi być unikalny per wystąpienie, nie per produkt ani per sesja.
Facebook Dynamic Ads + Pixel PRO: Feed Produktów, Pixel i API Konwersji (PrestaShop 8 i 9)Sprzedawaj na Facebooku i Instagramie i mierz każdą konwersję€89,00
Czego oczekuje API
W przeciwieństwie do piksela, który sporo domyśla, API zna tylko to, co mu wyślecie. Trzy rodziny informacji.
Dane dopasowania klienta. E-mail, telefon, imię, nazwisko, miasto, kod pocztowy, kraj. Służą do powiązania konwersji z użytkownikiem platformy. Trzeba je znormalizować, a następnie zahaszować przed wysłaniem, nigdy nie przesyłać otwartym tekstem.
Dane zdarzenia. Nazwa, znacznik czasu, wartość, waluta, zawartość zamówienia z identyfikatorami produktów.
Dane kontekstu. Adres IP i user agent odwiedzającego oraz identyfikatory kliknięcia reklamowego, jeśli są obecne w adresie wejściowym. Te dwa ostatnie wyraźnie poprawiają dopasowanie i bywają pomijane.
Jakość dopasowania
Platforma wylicza wynik mierzący jej zdolność do powiązania waszych zdarzeń z użytkownikami. Ten wynik bezpośrednio warunkuje skuteczność waszych kampanii i waży znacznie więcej niż liczba wysłanych zdarzeń.
Trzy dźwignie poprawy. Wysyłać więcej parametrów dopasowania: każde dodatkowe pole zwiększa prawdopodobieństwo powiązania. Poprawnie normalizować przed haszowaniem: małe litery, usunięcie spacji, format międzynarodowy dla telefonów. Oraz przekazywać identyfikatory kliknięcia, które są najpewniejszymi sygnałami.
Niski wynik nie widać w raportach konwersji, widać go w skuteczności kampanii. Właśnie to czyni go trudnym do zdiagnozowania.
Zgoda
Punkt do potraktowania poważnie, bo wysyłka serwerowa z niczego nie zwalnia.
To, że zdarzenie wychodzi z waszego serwera, a nie z przeglądarki, nie zmienia jego natury prawnej. Jeśli odwiedzający odmówił zgody na znaczniki reklamowe, nie wolno wam przekazywać jego danych platformie reklamowej, niezależnie od kanału technicznego.
API konwersji równoważy stratę wynikającą z blokerów i technicznych ograniczeń przeglądarek, a nie stratę wynikającą z odmowy zgody. Twierdzenie odwrotne to błędna interpretacja, która krąży szeroko.
W praktyce wasze wdrożenie serwerowe musi znać stan zgody odwiedzającego i uzależniać od niego wysyłkę.
Zdarzenia do pokrycia
Pięć wystarczy do prowadzenia kampanii e-commerce: wyświetlenie treści, dodanie do koszyka, rozpoczęcie płatności, zakup oraz rejestracja, jeśli macie dla niej zastosowanie.
Zakup jest jedynym, który bezwzględnie musi iść obydwoma kanałami z deduplikacją. Pozostałe mogą na początku zadowolić się pikselem, a pokrycie serwerowe dojść później.
Punkt spójności do pilnowania: identyfikatory produktów wysyłane w zdarzeniach muszą dokładnie odpowiadać tym z waszego feedu produktowego. Rozbieżność uniemożliwia działanie kampanii dynamicznych, które opierają się na tym dopasowaniu.
Weryfikacja
Trzy kontrole, w tej kolejności.
Narzędzie testowe platformy, które pokazuje odebrane zdarzenia w czasie rzeczywistym wraz ze źródłem. Złóżcie pełne zamówienie i sprawdźcie, że zakup pojawia się raz, z adnotacją o przeprowadzonej deduplikacji.
Wynik jakości dopasowania, do odczytania po kilku dniach działania i porównania z punktami odniesienia platformy.
Uzgodnienie z waszym zapleczem, w skali tygodnia. Różnica na minus rzędu 10 do 20 % pozostaje normalna. Różnica na plus, gdy platforma liczy więcej zakupów, niż zarejestrowaliście, sygnalizuje nieudaną deduplikację.
Moduł Facebook Dynamic Ads i Pixel PRO dla PrestaShop wdraża to podwójne pokrycie na PrestaShop 8 i 9: piksel przeglądarkowy i API konwersji z deduplikacją po identyfikatorze zdarzenia, haszowanie danych dopasowania, uwzględnienie zgody i generowanie feedu produktowego dla kampanii dynamicznych.