Deduplikacja zdarzeń piksela i Conversions API – jak uniknąć podwójnego liczenia zakupów

Deduplikacja w popularnych wdrożeniach

Sposób konfiguracji zależy od tego, jak wysyłasz zdarzenia do Meta. W wielu przypadkach deduplikacja działa automatycznie – ale zawsze warto to sprawdzić.

Integracje platform sklepowych

Pomoc Meta wskazuje, że wiele integracji partnerskich, np. dla Shopify i WooCommerce, automatycznie obsługuje parametry deduplikacji. Podobnie działa Conversions API włączane przez Meta oraz Conversions API Gateway – przesyłają zdarzenia z piksela przez serwer i same je deduplikują. Problem pojawia się, gdy sklep ma jednocześnie integrację platformy i dodatkowy, ręcznie wklejony kod piksela albo drugą wtyczkę. Wtedy to samo zdarzenie może przychodzić trzy razy, z różnymi identyfikatorami. Konfigurację dla konkretnych platform opisujemy w poradnikach o Shopify i Meta, Facebook for WooCommerce i pikselu w Shoper.

Google Tag Manager

Przy wdrożeniu przez Google Tag Manager identyfikator zdarzenia zwykle pochodzi z warstwy danych (dataLayer) – np. numer zamówienia w zdarzeniu purchase. Ta sama zmienna trafia do tagu piksela jako eventID i do tagu serwerowego jako event_id. Szczegóły opisujemy w poradniku piksel Meta przez Google Tag Manager.

Integracja bezpośrednia

Przy własnej integracji programista musi zadbać o trzy rzeczy: identyczne nazwy zdarzeń, ten sam identyfikator w pikselu i w żądaniu do Conversions API oraz wysyłanie zdarzenia serwerowego tylko raz dla jednej akcji – a nie np. przy każdej zmianie statusu zamówienia. Warto też przekazywać fbp i external_id, co pomaga zarówno w deduplikacji, jak i w dopasowaniu zdarzeń.

Zdarzenia wysyłane tylko z serwera

Niektóre zdarzenia w ogóle nie mają odpowiednika w przeglądarce – np. zamówienia przyjęte telefonicznie i wprowadzone ręcznie do panelu, płatności zaksięgowane po kilku dniach czy zakupy w sklepie stacjonarnym. Takie zdarzenia wysyła się wyłącznie przez Conversions API i nie trzeba ich deduplikować z pikselem. Trzeba natomiast pilnować, by ten sam zakup nie trafiał do Meta dwiema ścieżkami serwerowymi, np. z integracji platformy i z osobnego skryptu programisty. Wtedy obie ścieżki powinny używać tego samego identyfikatora zdarzenia albo jedna z nich powinna zostać wyłączona.

[#przyklad] Sklep z akcesoriami do domu wysyła Purchase z serwera w momencie zmiany statusu na „opłacone”, a później ponownie przy statusie „wysłane”. Oba zdarzenia mają ten sam event_id, więc Meta odrzuca drugie – pod warunkiem, że dotrze w ciągu 48 godzin. Jeśli wysyłka nastąpi po trzech dniach, zakup zostanie policzony drugi raz. Rozwiązanie: wysyłać Purchase tylko przy jednym, wybranym statusie.

Najczęstsze błędy w deduplikacji

Problemy z deduplikacją rzadko wynikają z samego mechanizmu Meta. Najczęściej to błąd w konfiguracji sklepu. Te przypadki spotykamy najczęściej:

• Brak event_id w jednym ze źródeł – piksel wysyła zdarzenie bez identyfikatora, a serwer z identyfikatorem (lub odwrotnie). Meta nie ma czego porównać.

• Różne formaty identyfikatora – np. liczba w pikselu i tekst z prefiksem w Conversions API.

• Różne nazwy zdarzeń – Purchase w pikselu i purchase albo zdarzenie niestandardowe w serwerze.

• Dwie instalacje piksela – integracja platformy i ręcznie wklejony kod wysyłają to samo zdarzenie z innymi identyfikatorami.

• Zdarzenie serwerowe przy każdej zmianie statusu – zakup wysyłany wielokrotnie, czasem po upływie 48 godzin.

• Różne zbiory danych – piksel wysyła zdarzenia do jednego identyfikatora, a Conversions API do innego; deduplikacja działa tylko w obrębie tego samego zbioru danych.

Wykres – typowe problemy z deduplikacją i sposoby ich naprawy. [#chart:m14b]

[#tip] Szybki test: złóż testowe zamówienie i sprawdź w narzędziu testowania zdarzeń, czy Purchase pojawia się z przeglądarki i z serwera z tym samym identyfikatorem, a w podsumowaniu jest liczony raz. To pięć minut, które oszczędzają tygodnie analizowania zawyżonych raportów.

Jak sprawdzić, czy deduplikacja działa

Menedżer zdarzeń pokazuje otrzymane zdarzenia, ich źródła i stan deduplikacji. Sprawdzenie warto przeprowadzić po każdym wdrożeniu i po zmianach w sklepie.

1. Otwórz zbiór danych w Menedżerze zdarzeń i wybierz zdarzenie Purchase. Zobacz, czy dociera z przeglądarki i z serwera.

2. Sprawdź informacje o deduplikacji przy zdarzeniu – Meta pokazuje, jaka część zdarzeń z obu źródeł zawiera parametry pozwalające je połączyć.

3. Użyj narzędzia testowania zdarzeń: złóż testowe zamówienie i obserwuj, które zdarzenia zostały odebrane, a które oznaczone jako zduplikowane.

4. Zajrzyj do zakładki Diagnostyka – Meta zgłasza tam m.in. brakujące identyfikatory zdarzeń i problemy z deduplikacją.

5. Porównaj liczbę zakupów w Menedżerze zdarzeń z liczbą zamówień w panelu sklepu z tego samego okresu i strefy czasowej.

Szczegółowy przewodnik po tych narzędziach znajdziesz we wpisie o Menedżerze zdarzeń Meta. Pamiętaj, że liczba zakupów w Menedżerze zdarzeń i liczba zakupów przypisanych reklamom w Menedżerze reklam to dwie różne rzeczy – druga zależy od ustawień atrybucji.

Lista kontrolna wdrożenia deduplikacji

Przed uznaniem konfiguracji za gotową przejdź przez kilka punktów. Większość z nich sprawdzisz w kwadrans, korzystając z narzędzia testowania zdarzeń i panelu sklepu.

• Piksel jest zainstalowany w sklepie tylko raz – jedną integracją albo jednym kodem.

• Zdarzenia z przeglądarki i serwera trafiają do tego samego zbioru danych.

• Nazwy zdarzeń są identyczne w obu źródłach, z zachowaniem wielkości liter.

• Purchase w pikselu ma eventID, a w Conversions API event_id o identycznej wartości i formacie.

• Zakup jest wysyłany z serwera raz na zamówienie, przy jednym wybranym statusie.

• Oba źródła przekazują fbp, a jeśli to możliwe – także external_id.

• Liczba zakupów w Menedżerze zdarzeń jest zbliżona do liczby zamówień w panelu sklepu.

Jak rozpoznać brak deduplikacji w wynikach kampanii

Nawet bez zaglądania do Menedżera zdarzeń można zauważyć sygnały ostrzegawcze. Jeśli po wdrożeniu Conversions API liczba zakupów w raportach nagle wzrosła niemal dwukrotnie, a sprzedaż w sklepie się nie zmieniła, to niemal pewny znak braku deduplikacji. Podobnie, gdy wartość konwersji w Menedżerze reklam przekracza przychód sklepu z tego samego okresu.

Taki błąd ma konsekwencje wykraczające poza raporty. Kampanie optymalizowane pod zakupy uczą się na zdublowanych sygnałach, strategie stawek oparte na docelowym ROAS dostają fałszywe dane, a decyzje o skalowaniu budżetu zapadają na podstawie zawyżonych wyników. Dlatego przy każdej analizie raportów w Menedżerze reklam warto co jakiś czas porównać liczby z panelem sklepu. Z drugiej strony, umiarkowane różnice między Meta a innymi narzędziami są normalne – wyjaśniamy je w artykule dlaczego Meta Ads pokazuje inną sprzedaż niż Google Analytics 4.

[#uwaga] Po naprawie deduplikacji liczba zakupów w raportach może wyraźnie spaść. To nie oznacza pogorszenia kampanii, tylko powrót do prawdziwych danych. Uprzedź o tym osoby, które analizują wyniki, i przy porównaniach okres po zmianie traktuj osobno.

Najczęściej zadawane pytania

Czy deduplikacja jest potrzebna, jeśli mam tylko piksel?

Deduplikacja między przeglądarką a serwerem – nie. Warto jednak sprawdzić, czy piksel nie jest zainstalowany dwa razy i czy zdarzenie Purchase nie uruchamia się np. po odświeżeniu strony podziękowania.

Co powinno być identyfikatorem zdarzenia przy zakupie?

Najprościej numer zamówienia – zna go zarówno strona podziękowania, jak i serwer sklepu. Ważne, by w obu źródłach miał identyczny format.

Jak długo Meta czeka na drugie zdarzenie do deduplikacji?

Według dokumentacji Meta dla deweloperów zdarzenia z tym samym identyfikatorem są deduplikowane, jeśli dotrą w ciągu 48 godzin od pierwszego zdarzenia z tym identyfikatorem.

Czy integracja Shopify lub WooCommerce sama deduplikuje zdarzenia?

Według Pomocy Meta wiele integracji partnerskich automatycznie obsługuje parametry deduplikacji. Problemy pojawiają się zwykle wtedy, gdy obok integracji działa drugi kod piksela lub inna wtyczka.

Dlaczego po naprawie deduplikacji ROAS spadł?

Bo wcześniej część zakupów była liczona podwójnie. Nowy ROAS jest bliższy rzeczywistości i to na nim warto opierać decyzje o budżecie.

Czy deduplikacja wpływa na jakość dopasowania zdarzeń?

Pośrednio tak. Parametry takie jak fbp i external_id pomagają zarówno w deduplikacji, jak i w dopasowaniu. Więcej o tym piszemy we wpisie o jakości dopasowania zdarzeń.

Czy deduplikacja działa między różnymi pikselami?

Nie. Meta porównuje zdarzenia w obrębie jednego zbioru danych. Jeśli piksel wysyła zdarzenia do jednego identyfikatora, a Conversions API do innego, każde z nich będzie liczone osobno.

Podsumowanie

Deduplikacja jest niezbędna, gdy to samo zdarzenie wysyłasz z piksela i z Conversions API. Działa, gdy oba zdarzenia mają tę samą nazwę i ten sam identyfikator zdarzenia – w sklepie najczęściej numer zamówienia – i trafiają do tego samego zbioru danych w ciągu 48 godzin. Najczęstsze błędy to brak identyfikatora w jednym ze źródeł, różne formaty, podwójne instalacje piksela i wielokrotne wysyłanie zakupu z serwera. Regularne testy w Menedżerze zdarzeń i porównanie z panelem sklepu pozwalają je szybko wychwycić.

Jeśli chcesz, żebyśmy jako Meta Business Partner sprawdzili deduplikację i całą konfigurację pomiaru w Twoim sklepie, zobacz naszą obsługę kampanii Meta Ads.