Meta Conversions API: ръководство за настройка 2026

Защо Meta Pixel пропуска конверсии?

Meta Pixel работи в браузъра на посетителя, а браузърите и устройствата го ограничават по няколко начина:

• От iOS 14.5 приложенията трябва да поискат разрешение чрез App Tracking Transparency, за да проследяват хората в приложения и сайтове на други компании (Apple).
• Safari изтрива бисквитките, записани с JavaScript, след седем дни без посещение, и след 24 часа, когато посетителят идва през линк с параметри от домейн, който Safari смята за проследяващ (WebKit).
• От Safari 26 (iOS 26) Safari спира известните скриптове за fingerprinting да записват дълготрайни бисквитки и да четат параметри от адреса, във всички режими на браузъра (WebKit, Safari 26.0). Private Browsing освен това маха известните click ID параметри от линковете (WebKit).
• Блокерите на реклами спират зареждането на скрипта на Pixel.

Conversions API (CAPI) е връзката на Meta от сървър към сървър. Вашият сървър праща събитието директно до Meta, така че ограниченията на браузъра не могат да го спрат. За по-широката картина на загубата на данни прочетете защо данните от рекламите ви липсват.

Какво прави CAPI?

1. Връща събития, които браузърният Pixel не е пратил заради блокери или защита от проследяване.
2. Добавя данни за клиента като хеширан имейл, телефон, fbp, fbc, IP адрес и user agent, с които Meta свързва събитията с профили.
3. Дедупликира спрямо Pixel, така че една покупка се брои веднъж.

Третата стъпка трябва да е вярна. Настройка, която брои конверсиите два пъти, надува отчетите ви и подава грешни числа към наддаването на Meta.

Кой начин на внедряване да изберете?

• Партньорски интеграции (Shopify, WooCommerce и други платформи). Включват се най-бързо и покриват стандартните събития за онлайн магазин. Имате по-малък контрол върху това кои данни за клиента пращате и как.
• Conversions API Gateway. Хостваният вариант на самата Meta, който копира Pixel събитията от сървъра с малко настройки.
• GTM server-side с тага на Meta за Conversions API. Най-много контрол върху събитията, обогатяването на данните и съгласието, но вие настройвате и поддържате сървърен контейнер.
• Managed server-side хостинг като TAGGRS (партньор на Octomize) или Stape. Същият сървърен контейнер на Google Tag Manager, но сървърите ги поддържа някой друг.
• Директна интеграция с API от вашия бекенд. Най-подходяща за собствени платформи с екип от програмисти.

Ако избирате между собствен и managed GTM server-side, вижте TAGGRS или GTM server-side.

Кои събития да пращате от сървъра?

Пращайте събитията, по които оптимизирате, не само Purchase:

1. PageView
2. ViewContent (прегледи на продукти с content ID)
3. AddToCart
4. InitiateCheckout
5. AddPaymentInfo
6. Purchase (със стойност, валута и номер на поръчката)
7. Lead (за събиране на запитвания)
8. CompleteRegistration (за регистрации)

Към всяко събитие прикачете данни за клиента: хеширан имейл и телефон, хеширани име и адресни полета, когато ги имате, плюс IP адрес, user agent, fbp и fbc.

Как работи дедупликацията?

Meta дедупликира Pixel събитие и CAPI събитие, когато eventID на Pixel съвпада с event_id от сървъра и имената на събитията съвпадат. Прави го само ако второто събитие пристигне до 48 часа след първото (Meta, deduplication).

Две правила:

• Генерирайте event_id веднъж, пратете го с Pixel събитието, предайте го на сървъра и пратете същата стойност с CAPI събитието.
• Базирайте го на номера на поръчката или друг уникален номер на транзакцията, не на час и дата.

Проверете дедупликацията в Events Manager. Метриките на Meta за качеството на набора от данни показват какъв дял от събитията идва с всеки ключ за дедупликация (Meta, Dataset Quality API).

Как да хеширате данните за клиента?

Meta изисква хеширане със SHA-256 за полетата за контакт като имейл, телефон, име, град, област, пощенски код и държава. Изрично казва да не хеширате IP адреса, user agent, fbp и fbc (Meta, customer information parameters).

Нормализирайте преди хеширането:

• Имейл: махнете интервалите и минете на малки букви. Точките остават.
• Телефон: махнете символите, буквите и водещите нули и включете кода на държавата (например 359888123456 за български номер).

Чести грешки:

• Хеширане на IP адреса, user agent или бисквитките.
• Хеширане на стойност, която вече е хеширана.
• Различно нормализиране на едно и също поле в две части на кода.
• Хеширан имейл, но нехеширан телефон.

Какво да правите с бисквитките fbp и fbc?

Meta свързва събитията по две бисквитки: _fbp (ID на браузъра) и _fbc (ID на клика, изграден от параметъра fbclid в адреса). Пращайте текущата стойност и на двете с всяко CAPI събитие, когато ги има.

Ако използвате GTM server-side на собствен поддомейн, например metrics.yourbrand.com, сървърът ви може да записва тези бисквитки като first-party през HTTP заглавките. Седемдневното ограничение на Safari важи за бисквитките, създадени с JavaScript, затова записаните от сървъра бисквитки издържат по-дълго.

Как да проверите, че CAPI работи?

Отворете Events Manager и вижте три метрики за набора от данни (Meta, Dataset Quality API):

• Event Match Quality (EMQ): оценка от 10, която показва колко добре данните ви свързват събитията с профили в Meta. Вдигате я, като пращате повече полета, нормализирани и хеширани по правилата на Meta. Започнете с имейл и телефон, защото повечето поръчки и форми вече ги събират.
• Покритие на събитията (event coverage): делът на Pixel събитията, които пращате и през CAPI със съвпадащи ключове за дедупликация. Препоръчителната цел на Meta е 75%.
• Additional Conversions Reported (ACR): оценката на Meta колко допълнителни конверсии отчитате, защото ползвате CAPI заедно с Pixel.

ACR ви казва дали работата се е изплатила, по вашите собствени данни, а не по нечий чужд бенчмарк.

Откъде да започнете?

Ако още нямате CAPI, започнете с Purchase или Lead плюс дедупликация и после добавете останалите събития от фунията. Ако сте го настроили преди време, проверете EMQ, покритието на събитията и ключовете за дедупликация, защото счупените настройки често изглеждат наред в Ads Manager.

Нашата услуга за проследяване на конверсии изгражда и одитира CAPI настройки, а управлението на Meta Ads движи кампаниите върху тези данни. За онлайн магазини вижте как работим с e-commerce бизнеси.

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

Трябва ли ми още Meta Pixel, ако ползвам Conversions API?

Да. Meta препоръчва да ползвате и двете с дедупликация. Pixel събира сигналите от браузъра, а CAPI запълва празнините, когато браузърът изпусне събития.

Каква е добрата оценка за Event Match Quality?

Meta отчита EMQ от 10 и по-високата оценка е по-добра. Сравнете оценката си преди и след промените и се съсредоточете върху пращането на повече полета за клиента, нормализирани и хеширани по правилата на Meta.

Колко дълъг е прозорецът за дедупликация в Meta?

48 часа. Meta дедупликира Pixel и сървърно събитие с едно и също име и event ID, ако второто пристигне до 48 часа след първото.

Трябва ли да хеширам fbp, fbc или IP адреса?

Не. Meta иска да не хеширате IP адреса, user agent, fbp и fbc. Нормализирайте полетата за контакт като имейл и телефон и ги хеширайте със SHA-256.

Работи ли Conversions API без съгласие?

Където законът го изисква, например за посетители от ЕС по GDPR, съгласието пак ви трябва. CAPI променя начина, по който пращате данните, а не дали имате право да ги пращате.