Настройка Facebook Conversion API для партнёров: руководство 2026

Шаг 1: Определите контракт конверсии до отправки событий

Контракт конверсии - это письменное правило о том, что означает каждое событие, когда оно срабатывает и какие поля допустимы в payload. Без этого контракта CAPI может превратить беспорядочную воронку в более быструю беспорядочную воронку.

Выбирайте только те события, которые можно доказать

Большинству партнёрских воронок следует начинать с четырёх стандартных событий: ViewContent, Lead, InitiateCheckout и Purchase. Добавляйте CompleteRegistration только тогда, когда воронка содержит реальный шаг регистрации, который ещё не покрывается Lead.

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

Свяжите каждое событие с одним бизнес-действием

У каждого события должно быть одно бизнес-определение. Например, Lead может означать валидированную подписку, отправленную с вашей предпродажной страницы, а Purchase - подтверждённую платную конверсию из postback сети или подтверждения checkout.

Документируйте источник истины для каждого события:

Определите идентификаторы один раз

Используйте общую event layer для генерации event_id, event_time и action_source. Отправляйте один и тот же event_id из браузерного события и серверного события, чтобы Meta могла дедуплицировать их как одно действие.

Используйте секунды Unix epoch для event_time. Как практическое рабочее правило, отправляйте события как можно ближе к моменту действия; задержанные события всё ещё могут быть приняты, но устаревшие данные о конверсиях менее полезны для ставок и отладки.

Шаг 2: Держите Pixel и CAPI в синхроне

Pixel и CAPI должны описывать одно и то же реальное действие через два канала доставки. Если они срабатывают по разным определениям, дедупликация становится ненадёжной, а отчётность может раздуваться.

Сначала подтвердите покрытие Pixel

До построения серверных событий проверьте, что Pixel срабатывает на важных страницах воронки: landing page, ключевой шаг намерения, вход в checkout и confirmation page. Записывайте имя события, URL, timestamp, value, currency и сгенерированный event_id во время тестовых сессий.

Это также даёт вам базовую линию для серверной работы. Если браузерный путь уже работает неправильно, CAPI не исправит основную логику событий.

Создайте общий correlation token

Генерируйте correlation token при загрузке страницы или начале пользовательской сессии. Передавайте его через landing pages, формы, редиректы checkout и postbacks там, где это законно и технически возможно.

Этот token не должен заменять поля, требуемые Meta, но он даёт вашей команде способ сопоставлять логи браузера, логи сервера, postbacks сети и диагностику рекламной платформы во время отладки.

Нормализуйте контекст кампании

Сохраняйте контекст трафика в стабильных полях: source, campaign, ad set, ad, creative, placement, affiliate ID, offer ID и variant воронки. Используйте единообразную систему именования, например ваш процесс декодирования UTM, чтобы платный трафик и отчётность по партнёрам можно было сравнивать без ручной очистки.

Не сбрасывайте все доступные параметры в custom_data. Отправляйте поля, которые помогают проверить атрибуцию, value, состояние воронки или качество оптимизации.

Шаг 3: Собирайте payload с учётом согласия

Хороший payload CAPI полезен технически и учитывает приватность. Он должен включать самые сильные разрешённые поля сопоставления, но только если сбор и передача законны для этого пользователя и региона.

Начните с минимально необходимой структуры

Сначала соберите и протестируйте базовый payload, а уже потом добавляйте опциональные поля:

• event_name
• event_time
• event_source_url
• action_source
• event_id
• user_data
• custom_data

Для покупок включайте currency и value, когда value надёжно определена. Для партнёрских офферов с задержанными approval различайте в внутренней отчётности estimated conversion value и approved payout.

Правильно нормализуйте и хешируйте пользовательские данные

Адреса email и номера телефона нужно нормализовать перед хешированием. Например, удаляйте пробелы, приводите email к нижнему регистру и единообразно форматируйте номера телефона перед применением SHA-256, когда требуется hashing.

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

Закладывайте consent в путь данных

Consent нужно проверять до сборки payload, а не после отправки события. Если consent отсутствует, отправляйте только те поля, которые разрешает ваша политика, либо подавляйте событие, если это требуется вашей legal basis и региональными правилами.

Держите это отражённым в вашем compliance-процессе, включая юридические проверки и проверки compliance. Технические команды должны понимать, почему поле было включено, опущено или заблокировано.

Шаг 4: Передавайте события с повторами и дедупликацией

Качество передачи важно, потому что одна реальная конверсия должна становиться одним событием платформы. Практическая разница между лучшей оптимизацией и раздутой отчётностью - это дисциплинированная дедупликация.

Выберите правильный путь интеграции

Есть три распространённых пути реализации:

Если ваша команда уже использует серверные контейнеры Google Tag Manager, сравните этот workflow с вашей настройкой server-side GTM прежде чем выбирать отдельный relay.

Повторяйте только правильные сбои

Настройте retries для временных сбоев передачи, таких как timeout или временные server errors. Не повторяйте malformed events, не исправив сначала validation error.

Практичный шаблон retry - немедленная отправка, одна короткая повторная попытка, одна отложенная повторная попытка, затем dead-letter log для проверки. Храните request IDs, event IDs, response codes и версию payload в логах, чтобы сбои можно было аудировать.

Дедуплицируйте по event_id

Используйте один и тот же event_id для события Pixel и совпадающего события CAPI. Также держите краткоживущий server-side cache, ключом которого является event ID и business action, чтобы ваша система не отправляла одну и ту же конверсию повторно.

В качестве оценки здоровая реализация должна удерживать устойчивую утечку дублей на достаточно низком уровне, чтобы она не меняла решения по оптимизации. Немедленно расследуйте, если дубли появляются вокруг обновлений checkout, повторов postback или задержанных approvals сети.

Шаг 5: Проверяйте качество сигнала перед масштабированием

Не оценивайте CAPI по тому, появляются ли события в dashboard. Оценивайте его по тому, насколько принятые события точны, дедуплицированы, своевременны и полезны для ставок.

Запускайте контролируемые тестовые сессии

Тестируйте каждый тип события на известных сессиях до отправки полного трафика. Захватывайте браузерное событие, серверное событие, event_id, timestamp, URL, value, состояние consent и ожидаемый результат.

Проводите и отрицательные тесты. Брошенные checkout, отклонённые карты, невалидные формы и отклонённые партнёрские конверсии не должны считаться успешными покупками или лидами.

Используйте метрики здоровья с реалистичными диапазонами

Точные числа зависят от вертикали, географии, mix устройств и уровня consent, поэтому рассматривайте их как рабочие оценки, а не универсальные бенчмарки.

Отлаживайте в правильном порядке

Начните с диагностики и test events в Meta Events Manager. Затем проверьте ваш процесс Event Match Quality EMQ, серверные логи, записи network postback и отчётность рекламного аккаунта.

Не меняйте ставки, чтобы компенсировать сломанное отслеживание. Сначала исправьте определения событий, поля payload, дедупликацию и обработку consent.

Шаг 6: Применяйте CAPI к решениям о масштабировании партнёров

Командам партнёров не следует инструментировать каждый тест с одинаковой глубиной. Глубокое отслеживание наиболее ценно, когда у оффера есть доказательства повторяемой экономики.

Сортируйте офферы по операционному состоянию

Классифицируйте каждый оффер до решения об инвестициях в tracking:

• До масштабирования: ранний тестовый объём, нестабильный CPA и ограниченное подтверждение конверсий.
• Масштабирование: повторяемая conversion rate, стабильный тренд CPA и достаточный объём для обучения.
• Saturated: растущий CPA, более слабый отклик creative или ограниченный объём в повторяющихся окнах.

Daily Intel Service здесь полезен, потому что помогает операторам отделять живое поведение масштабирования от устаревших публичных снимков. Это снижает риск тратить время инженеров на офферы, которые уже выдыхаются.

Используйте внешние сигналы осторожно

Meta Ad Library может помочь проверить, запускают ли рекламодатели креативы сейчас, но она не доказывает прибыльность, spend или conversion rate. Рассматривайте её как направляющий сигнал, а не как замену собственным данным воронки.

Инструменты конкурентов вроде AdSpy, BigSpy или Anstrex могут поддерживать research creative, но они не должны определять, работает ли ваша реализация CAPI. Источником истины являются ваши собственные event logs и данные утверждённых конверсий.

Свяжите tracking с media operations

Встройте проверки CAPI в процесс rollout для media buyer. Практичный ритуал - лёгкий tracking для ранних тестов, более глубокая валидация CAPI для кандидатов в масштабирование и еженедельная очистка событий, связанных с остановленными или saturated офферами.

Для команд, использующих Daily Intel Service, наиболее сильный workflow - сочетать intelligence по состоянию оффера с внутренними проверками здоровья CAPI перед увеличением бюджета. См. методологию Daily Intel Service, если нужен framework решения, стоящий за этой классификацией.

Шаг 7: Поддерживайте governance после запуска

CAPI - это не разовая настройка. Ему нужны versioning, monitoring и ownership, потому что страницы воронки, провайдеры checkout, partner postbacks и правила валидации платформы меняются.

Ведите runbook на одну страницу для каждой воронки

У каждой воронки должен быть runbook с картой событий, schema payload, правилами consent, владельцем, источником postback, политикой retry, планом rollback и датой последней валидации. Это просто, но предотвращает зависимость от памяти при отладке.

Обновляйте runbook всякий раз, когда меняются URL оффера, checkout flow, lead form, tracking domain или правило payout.

Следите за schema drift

Schema drift возникает, когда payload, который, как вам кажется, вы отправляете, уже не совпадает с payload, который приходит в Meta. Распространённые причины включают новые поля формы, изменения checkout, обновления relay provider и изменения network postback.

Ведите версии payload и сравнивайте acceptance rate, quality match и поведение дублей до и после deployments. Если после release падает acceptance, откатите изменение tracking до изменения стратегии кампании.

Держите доверие пользователя в центре

Server-side tracking не следует использовать как обходной путь для выбора пользователя или политики платформы. Согласуйте реализацию с документацией Meta по Conversions API, рекламными стандартами Meta и принципами helpful content Google при публикации руководств или внутренних playbooks.

Устойчивая версия CAPI проста: собирайте меньше шума, отправляйте более чистые события, уважайте consent и масштабируйтесь только тогда, когда экономика воронки оправдывает более глубокую instrumentation.

Часто задаваемые вопросы

В: Что такое Facebook Conversions API?
О: Facebook Conversions API - это серверный event interface Meta для отправки web, app или offline conversion events напрямую с вашего сервера или из одобренной интеграции в Meta.

В: Нужен ли партнёрам Pixel, если они используют CAPI?
О: Да. Большинство партнёрских настроек должны использовать и Pixel, и CAPI, а затем дедуплицировать совпадающие события с помощью одного и того же event_id. Pixel даёт контекст браузера, а CAPI повышает устойчивость, когда сигналы браузера ограничены.

В: С каких событий должен начинать партнёр?
О: Начинайте с ViewContent, Lead, InitiateCheckout и Purchase только тогда, когда каждое событие соответствует реальному действию воронки. Добавляйте больше событий после того, как докажете точность базовых.

В: Как предотвратить дубли конверсий?
О: Сгенерируйте один event_id для реального действия, отправляйте этот же ID по путям браузера и сервера и держите server-side idempotency controls для повторов postback или обновлений checkout.

В: Что нужно проверить перед масштабированием spend?
О: Проверьте определения событий, acceptance payload, время события, дедупликацию, обработку consent и reconciliation утверждённых конверсий. Не увеличивайте бюджет только потому, что события CAPI видны в Meta Events Manager.

В: Event Match Quality - это то же самое, что качество tracking?
О: Нет. Event Match Quality отражает силу разрешённых полей сопоставления, но качество tracking также зависит от точной логики событий, дедупликации, своевременности и аккуратной обработки conversion value.