Book a Call
Back to archive
13.03Server-side и API-интеграции

Meta Conversions API: серверные события для Meta Ads

intermediate4 min readmeta-ads · facebook-ads · conversions-api

TL;DR

  • Meta Conversions API, или CAPI, отправляет события в Meta с сервера, CRM, приложения или другого backend-источника.
  • CAPI не обязательно заменяет Pixel. Чаще всего Pixel и CAPI работают вместе, а Meta дедуплицирует пары событий.
  • Главный технический ключ - event_id. Один и тот же customer action должен иметь одинаковый ID в браузерном и серверном событии.
  • Качество user data влияет на match rate: email, phone, IP, user agent, fbp, fbc, external_id.
  • Для leadgen CAPI особенно полезен, когда нужно отправлять не просто лид, а его качество: qualified, approved, paid.
13.03 - Meta Conversions API: серверные события для Meta Ads
13.03 - Meta Conversions API: серверные события для Meta Ads

1. Что такое CAPI

Meta Pixel работает в браузере. Он видит действия пользователя на сайте и отправляет события в Meta. Но браузер не всегда надежен: cookies режутся, скрипты блокируются, пользователь может прийти из in-app browser.

Conversions API добавляет серверный канал. Вы можете отправить событие напрямую в Meta из backend, CRM, sGTM или партнерской платформы.

Customer action

Browser Pixel

Server / CRM / sGTM

Meta Events Manager

Deduplication

Ads optimization

Идея не в том, чтобы "обмануть браузер". Идея в том, чтобы Meta получила больше корректных событий и могла лучше оптимизировать кампании.

2. Какие поля важны

У серверного события есть несколько критичных блоков.

ПолеЗачем нужно
event_nameНазвание события: Purchase, Lead, CompleteRegistration
event_timeКогда событие реально произошло
event_idДедупликация браузерного и серверного события
action_sourceГде случилась конверсия: website, app, phone_call, chat, physical_store
user_dataИдентификаторы пользователя для matching
custom_dataValue, currency, content, lead quality, order data
event_source_urlURL события для website events

Meta требует не просто "отправить purchase". Ей нужно понять, что это за событие, где оно произошло и с каким пользователем его можно сопоставить.

3. Дедупликация

Если Pixel и CAPI отправляют одно и то же событие, Meta должна понять, что это один customer action, а не две покупки.

Правильная схема:

Order #123

Pixel Purchase eventID=123

CAPI Purchase event_id=123

Meta

One purchase counted

Плохая схема: Pixel отправил eventID=abc, сервер отправил event_id=xyz. Meta видит два события. В отчетах появляются дубли, ROAS выглядит лучше реальности, алгоритм получает грязный сигнал.

Для e-commerce удобно использовать order_id. Для leadgen - lead_id или application_id. Для событий без естественного ID можно генерировать UUID и прокидывать его через frontend, backend и CRM.

4. Event Match Quality

Event Match Quality - это не vanity metric. Если Meta не может сопоставить серверное событие с пользователем, событие хуже помогает атрибуции, аудиториям и оптимизации.

Что обычно передают:

  • email в SHA-256 после нормализации;
  • phone в SHA-256 после нормализации;
  • IP address;
  • user agent;
  • fbp;
  • fbc;
  • external_id;
  • country, city, postal code, если это допустимо по privacy-политике.

Важно: хеширование не делает любые данные автоматически безопасными. Перед отправкой нужно понимать согласие, законность обработки и внутренние правила компании.

5. Leadgen: где CAPI особенно силен

Для e-commerce событие Purchase обычно понятно. Для leadgen сложнее. Не каждый лид одинаково ценен.

Пример для банка:

Lead submitted

CRM created

Qualified

Approved

Issued / paid

Send quality event to Meta

Если оптимизироваться только на Lead, алгоритм может приводить дешевые заявки без шанса на одобрение. Если отправлять QualifiedLead или ApprovedApplication, Meta получает более дорогой, но полезный сигнал.

6. Локальный контекст СНГ/РК

В Казахстане CAPI часто упирается не в GTM, а в согласование с IT и безопасностью. Особенно в банках, страховании, микрофинансах, медицине и недвижимости.

Практичный подход:

  • не отправлять сырые email и phone;
  • заранее описать список полей;
  • хешировать PII на сервере;
  • разделить marketing event и персональные данные;
  • хранить lead_id как внутренний ключ;
  • отправлять quality events после CRM-валидации.

Для малого бизнеса CAPI можно начать через sGTM или партнерский коннектор. Но даже там нужно проверить дубли. "Поставили CAPI" не равно "данные стали правильными".

7. Ошибки

ОшибкаЧто происходит
Нет общего event_idДубли покупок и лидов
Плохая нормализация email/phoneНизкий match quality
Отправляют lead без качестваАлгоритм ищет дешевые мусорные заявки
Нет Test Events проверкиОшибка живет в продакшене
Слишком много custom fieldsРастет privacy-риск и шум
Не сверяют с CRMКабинет Meta живет отдельно от реальности

8. Чеклист запуска

  • Определены события для Meta: Lead, Purchase, Subscribe, QualifiedLead.
  • Для каждого customer action есть стабильный event_id.
  • Browser Pixel и CAPI используют одинаковые названия событий.
  • User data нормализуется и хешируется там, где это нужно.
  • Проверены Test Events в Events Manager.
  • Настроена дедупликация.
  • CRM-статусы могут отправлять quality events.
  • Есть ежедневная сверка: CRM count vs Meta received events.

9. Видео

FACEBOOK CONVERSIONS API ДЛЯ ТОЧНОГО ТРЕКИНГА В META ADS: зачем нужен и как настроить правильно

10. Главный совет

CAPI стоит внедрять не ради галочки в Events Manager, а ради качества оптимизации. Передавайте не максимум данных, а минимум нужных данных, которые помогают Meta отличать ценный customer action от шума.

Что почитать