Meta Pixel и Conversions API: как да спрете дублираните събития
Спирате ги, като изпращате един и същ event_id и еднакво име на събитието и от браузъра, и от сървъра. Стойността трябва да съвпада знак по знак. Когато Meta Pixel и Conversions API работят заедно, всяка поръчка тръгва два пъти: веднъж от браузъра, веднъж от сървъра. Meta ги обединява само ако двете носят един и същ event_id. Ако не носят, акаунтът брои всяка покупка двойно, възвръщаемостта изглежда двойно по-добра, а решенията за бюджет стъпват върху измислено число. Проверявате го в Events Manager: отваряте набора от данни, гледате колко събития са отчетени като дублирани и следите оценката за качество на съвпадението (EMQ) по скала от 0 до 10.
Аз съм Християн Панов — Performance Marketing консултант с над 5 години опит и над €2 000 000 управляван рекламен бюджет за над 90 компании в Google и Meta. По-долу е как се проверява дедупликацията за десет минути и какво да поправите, ако е счупена.
Защо изобщо са нужни и двата канала?
Защото браузърът вече не е надежден. Блокери на реклами, ограничения в Safari и откази от бисквитки изяждат част от събитията. Сървърът не зависи от браузъра и предава останалото.
Целта не е повече събития. Целта е същите събития, доставени по два пътя, от които поне единият минава.
По какво се познава, че единият път липсва: в Events Manager всяко събитие носи източник — само браузър, само сървър или и двата. Ако при Purchase редът за сървъра е празен, CAPI не е свързан и цялото отчитане виси на браузъра. Обратното също се среща: сървърът работи, пикселът не се задейства заради отказано съгласие и наддаването остава без сигналите от сесията.
Редът на проверката е кратък. Отваряте набора от данни, филтрирате по Purchase, гледате разпределението по източник за последните дни, после го сравнявате с реалните поръчки. Двата канала не се сумират — те се припокриват. Затова следващата стъпка е дедупликацията, а не добавянето на още едно събитие.
Как точно работи дедупликацията?
Двете събития трябва да съвпадат по две неща: име на събитието (Purchase) и event_id. Meta пази прозорец от 48 часа и приема първото пристигнало, отхвърляйки второто.
Най-надеждната стойност за event_id при магазин е номерът на поръчката. Той е уникален, съществува и от двете страни и не зависи от случайно генерирани числа, които сървърът не знае.
Съвпадението е буквално. Сравнява се знак по знак — с главните и малките букви, с водещите нули и с представките. Ако браузърът праща едната форма на номера, а сървърът същия номер с добавен префикс, обединяване няма.
Кой пристига пръв няма значение за резултата. Обикновено това е пикселът, защото тръгва от страницата за благодарност, докато сървърното събитие минава през платформата. Затова не се опитвайте да решите проблема със забавяне на едното — забавянето не помага, когато идентификаторът е различен.
В пиксела стойността се подава като идентификатор на събитието към извикването на Purchase. В сървърното събитие тя стои в полето event_id. Двете места се четат едно до друго, не поотделно.
Как да проверите дали дедупликацията работи?
В Events Manager → вашият набор данни → Overview. Под събитието Purchase има ред за дублирани събития и процент дедупликация.
Три бързи проверки:
- Направете тестова поръчка и вижте в Test Events дали пристигат два записа с еднакъв идентификатор.
- Сравнете броя Purchase в Meta с реалните поръчки в системата за същия период. Разлика от порядъка на два пъти е диагноза сама по себе си.
- Проверете дали общата стойност на поръчките в Meta не е точно двойно спрямо счетоводството.
Какво е EMQ и колко е добър?
Event Match Quality е оценка от 0 до 10 колко добре Meta успява да свърже събитието с реален човек. Зависи от това колко идентификатора изпращате — имейл, телефон, име, град, IP, идентификатор на браузъра.
Под 5 означава, че губите приписване. Над 7 е добър резултат за български магазин. Най-бързият начин да го вдигнете е да добавите хеширан имейл и телефон в сървърното събитие.
Кои са трите най-чести грешки?
Трите се откриват в един и същ екран и се поправят на едно и също място — в настройката на събитието, не в кампаниите.
- Случаен event_id от браузъра. Сървърът генерира свой и двата никога не съвпадат. Ползвайте номера на поръчката. Познава се по това, че процентът дедупликация стои на нула, докато и двата източника отчитат Purchase.
- Различни имена на събитието. „Purchase“ от пиксела и „purchase“ от сървъра не се обединяват. Същото важи и за собствено име, зададено от приставка — то се появява като отделно събитие в списъка и не се брои към стандартното.
- Автоматично засичане на събития (automatic advanced matching / auto config). Пикселът праща допълнителни събития, които никой не е поръчвал, и те влизат в отчета. Изключва се от настройките на набора данни, след което проверявате дали ръчно зададените събития продължават да пристигат.
След всяка промяна изчакайте нова реална поръчка и я проследете от край до край. Отчетът не потвърждава поправката, докато през него не мине събитие, създадено след нея.
Ами стойността на поръчката?
Тя трябва да е една и съща и в правилната валута. При магазини в преход между лев и евро съм виждал пиксела да праща сума в едната валута, а сървъра — в другата. Резултатът е възвръщаемост, надута близо два пъти, без нито едно дублирано събитие.
Проверявайте не само броя, но и общата стойност срещу реалния оборот.
Дедупликацията не гледа сумата. Тя сверява име и event_id, така че разминаване в стойността минава без предупреждение и не се появява като дублирано събитие никъде в отчета.
Затова фиксирайте правилото и го спазвайте и от двете страни: една и съща база — с или без данък, със или без доставка — и едно и също поле за валута. Сумата се подава като число, без символ на валута в самото поле.
Сверката е проста. За един и същ период вземете общата стойност на Purchase и я сравнете с оборота в системата за поръчки. Ако съотношението прилича на курса между двете валути, търсете грешката в полето за валута, а не в бройката събития.
FAQ — Често задавани въпроси за Pixel и CAPI
Мога ли да ползвам само CAPI?
Технически да, но не е препоръчително. Пикселът добавя сигнали от браузъра, които подобряват съпоставянето и оптимизацията.
Трябва ли ми отделен сървър?
Не задължително. Готовите интеграции на платформите вършат работа. Собствен GTM сървър дава повече контрол и по-добър EMQ, но е допълнителен разход.
Колко време отнема да се отрази поправката?
Събитията се дедуплицират веднага, но отчетите изравняват картината за 24–48 часа. Историческите данни остават неточни.
Ще паднат ли конверсиите ми след поправката?
Отчетените — да, и това е добрата новина. Реалните продажби не се променят; вие спирате да вземате решения по надуто число.
Влияе ли съгласието за бисквитки?
Да. При отказ пикселът не се задейства; сървърното събитие също трябва да уважава избора. Проверете дали интеграцията Ви го прави.
Заключение
Дублираните събития не са техническа подробност. Те правят губеща кампания да изглежда печеливша — и колкото по-дълго стоят, толкова повече бюджет отива в грешната посока с пълна увереност.
Ако числата в Meta не се връзват с банковата Ви сметка, започнете от независим преглед.
Заявете оферта за дигитален одит →
Свързани статии: server-side проследяване · Consent Mode v2 · прагов ROAS и марж
