Meta Pixel и Conversions API отчитат покупката два пъти: как да откриете дублирането

Магазинът има една потвърдена поръчка, а в диагностиката на Meta виждате две Purchase изпращания. Това може да е нормалната двойка от браузъра и сървъра или реално дублиране. Разликата се установява по събитията на конкретна поръчка, не само по общия брой в рекламния отчет.

Две изпращания не означават непременно две покупки

Pixel измерва през браузъра; CAPI може да изпрати същото действие от сървъра. Тази комбинация има нужда от дедупликация. Ако системите използват различни идентификатори за една покупка, Meta може да не разпознае, че събитията се отнасят до едно действие.

Отделно съществуват разлики в приписването на резултати, времевите прозорци и статуса на поръчките. По-висок рекламен брой спрямо магазина не доказва сам по себе си дефект в дедупликацията. Първо проверете съпоставими резултати и конкретни изпращания.

Кои полета трябва да съвпаднат

Идентификаторът в таблицата е условен. Meta описва препоръчаното съпоставяне по име и event ID, като browser eventID трябва да съвпада със server event_id. При Pixel eventID е опция в четвъртия аргумент на извикването, а не просто произволно поле със сходно име сред данните за покупката.

Идентификаторът принадлежи на действието

Генерирайте устойчив идентификатор за една логическа покупка и го използвайте в двата канала. Ако сървърът създава нов случайно генериран ID при всеки опит, повторното известие изглежда като ново действие. Ако всички поръчки имат еднакъв ID, рискувате да загубите валидни резултати.

Не използвайте имейл или телефон като идентификатор на покупката. Един клиент може да направи няколко различни покупки. При поръчки от различни магазини или среди добавете безопасно разграничаване, така че номерата да не се сблъскват.

Направете карта на всички изпращачи

Проверете платформения модул, GTM, собствен код, server-side контейнер, CAPI Gateway и свързани приложения. Честа причина е едновременно работещ стар и нов механизъм. Списъкът трябва да показва кой изпраща Purchase, кога го прави и откъде взема event ID.

Не изключвайте произволно целия Pixel, за да намалите броя. Първо определете кой поток е излишен и какво друго измерва. След промяната проверете и останалите важни събития, за да не поправите покупките чрез загуба на целия път.

Тест с една поръчка, който разкрива проблема

1. Изберете тестова среда или уговорена тестова поръчка и запишете нейния номер.
2. Проверете договореното състояние за Purchase: създадена, платена или друго реално потвърждение.
3. Проследете браузърното изпращане и сървърния payload в разрешените инструменти за диагностика.
4. Сравнете името, event ID, целевия Pixel, стойността и валутата.
5. Проверете представянето на browser/server събитията и диагностиката за дедупликация в Events Manager.
6. Повторете с презареждане на страницата и повторно доставяне на webhook.
7. Направете втора различна поръчка: тя трябва да има нов идентификатор и да остане отделна покупка.

Тестът трябва да докаже едновременно две неща: повторението на първата поръчка не създава нов резултат, а втората валидна покупка не изчезва. Общата зелена отметка за активна интеграция не е достатъчна.

Повторните сървърни известия изискват собствен контрол

Webhook може да бъде доставен повторно след временна грешка. Интеграцията трябва да пази обработеното действие и да управлява повторните опити. Това е идемпотентност: една и съща входяща операция не създава нов бизнес резултат при всяко повторение.

Не разчитайте единствено на browser/server дедупликацията, за да поправи две независими сървърни интеграции. Запишете изпратеното събитие, резултата от доставката и причината за повторния опит. Логовете трябва да са достъпни само за оправомощения екип и да не показват ненужни клиентски данни.

Кога Purchase трябва да се изпрати?

Определете го според модела на магазина. При наложен платеж създадена поръчка не е равнозначна на окончателно реализиран приход. При онлайн плащане зареждането на страница „Благодарим“ може да не е достатъчно доказателство за успех. Платформата и магазинът трябва да използват ясно документиран резултат.

CAPI не отменя избора на потребителя или приложимите ограничения за данни. Пренасянето на измерване към сървъра не е основание да изпращате всичко без контрол.

За общата диагностика прочетете GA4, GTM и проследяване на реализации. При онлайн магазини DigitaL+ свързва Analytics & Tracking с Meta рекламата. Ако проблемът е в резултатите след правилно измерване, следващата тема е каталог, креативи и марж.

Често задавани въпроси

Event Match Quality показва ли, че няма дублиране?

Не. Качеството на съпоставяне на потребителските сигнали и разпознаването на повторено събитие са различни проверки.

Трябва ли event_id да е случаен?

Може да е генериран по различни начини, но трябва да е уникален за действието и устойчив при повторение. Двата канала трябва да използват една и съща стойност.

След поправката всички отчети ли ще станат еднакви?

Не. Ще премахнете конкретния дефект, но разлики поради приписване, статуси, време и допустимо измерване могат да останат.