API конверсий: что даёт и чего не заменяет

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

Коротко

• API конверсий (Conversions API) — это серверный канал передачи событий о конверсиях на рекламную площадку.
• Он работает параллельно с пикселем: оба источника дополняют друг друга.
• Дедупликация в Meta работает по совпадению названия события и параметра event_id.
• Серверные события помогают набрать объём данных для выхода из фазы обучения, но не определяют срок.
• API конверсий не исправляет ошибки в идентификаторах и не заменяет настройку конверсионных действий.
• Он не даёт данных о бюджетах и результатах конкурентов.

Что такое API конверсий и зачем он нужен

API конверсий — это интерфейс, через который сервер вашего сайта или CRM отправляет данные о действиях пользователя напрямую на площадку. Событие формируется не в браузере, а на серверной стороне, поэтому блокировщики рекламы и ограничения браузеров на него не влияют.

Пиксель работает иначе. Он запускается в браузере посетителя, и если браузер блокирует скрипт или пользователь запретил отслеживание, событие не дойдёт. Серверный канал таких потерь не знает: вы контролируете, что и когда отправить.

Зачем это нужно на практике. Когда часть конверсий не доходит до площадки, алгоритм кампании видит неполную картину и оптимизируется на неполных данных. Серверные события возвращают эту часть обратно. Но важно понимать: API конверсий — это канал передачи, а не инструмент исправления ошибок в настройке целей или в идентификаторах.

Чем API конверсий отличается от пикселя

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

Ключевое различие — в точке сбора данных. Браузерный канал теряет события там, где серверный их сохраняет. Но серверный канал не видит того, что происходит в браузере до отправки на сервер: например, если пользователь закрыл страницу до того, как сработал серверный триггер.

Именно поэтому оба канала работают вместе. Отключить пиксель и оставить только API конверсий — значит потерять события, которые сервер не получил.

Как работает дедупликация событий в Meta

Meta объединяет события пикселя и API конверсий по совпадению названия события и параметра event_id. Если оба канала передают событие с одинаковым названием и одинаковым event_id, Meta считает его одной конверсией.

Отдельного переключателя для дедупликации нет. Совпадение идентификаторов нужно обеспечить на стороне сайта и сервера: один и тот же event_id должен уйти и в пиксель, и в серверный запрос. Если event_id не совпадает или отсутствует, одна и та же конверсия может попасть в отчёт дважды.

Это не значит, что дедупликация сломана. Это значит, что её нужно проверять. Рост или падение числа конверсий после подключения API конверсий — гипотеза до того момента, пока вы не проверили события, идентификаторы, источники и атрибуцию. Изменение числа конверсий само по себе не доказывает, что дедупликация работает корректно.

Как проверить на практике:

1. Убедитесь, что название события в пикселе и на сервере совпадает.
2. Проверьте, что event_id генерируется один раз и передаётся в оба канала.
3. Сравните число конверсий в отчёте площадки с числом конверсий в вашей CRM или аналитике.
4. Если расхождение есть, проверьте, не дублируются ли события с разными event_id.
5. Убедитесь, что источники событий не пересекаются по одним и тем же действиям.

Что API конверсий даёт кампании

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

Второй эффект — устойчивость к изменениям в браузерах. Ограничения на отслеживание в браузерах усиливаются, и браузерный канал теряет данные. Серверный канал от этих изменений не зависит.

Третий эффект — возможность передавать события, которых нет в браузере. Например, конверсию, которая происходит в CRM после звонка или после подтверждения заказа менеджером. Такие события пиксель передать не может.

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

Что API конверсий не заменяет

API конверсий не заменяет корректную настройку целей и не исправляет ошибки в идентификаторах. Если событие отправляется с неверным названием или без event_id, серверный канал не сделает данные точнее.

Он также не заменяет настройку конверсионных действий в Google Ads. Measurement Protocol отправляет серверные события в GA4, а не напрямую в Google Ads, поэтому его нельзя считать настройкой конверсионного действия. В Google Ads серверные конверсии передаются другими путями, например через Google Ads API или импорт из GA4.

Для дедупликации в Google Ads повтор одной конверсионной акции с тем же transaction или order ID не удваивается. Но одинаковый ID не объединяет разные акции: если вы создали две разные конверсионные акции для одной покупки, согласованный идентификатор не сведёт их в одну. Согласованный ID нужен и для браузерной, и для серверной загрузки.

API конверсий не показывает, какой источник на самом деле принёс продажу. Атрибуция — отдельная задача, и серверный канал её не решает. Он передаёт событие, но не определяет, какой канал или кампания заслуживает кредит за конверсию.

Наконец, API конверсий не даёт данных о бюджетах, расходах и результатах конкурентов. Он не строит прогноз сезонности или спроса. Это инструмент передачи событий, а не аналитическая платформа.

Как проверить, что серверные события работают

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

Что проверить:

• Совпадают ли названия событий в пикселе и на сервере.
• Передаётся ли event_id в оба канала.
• Нет ли дублей с разными event_id.
• Совпадает ли число конверсий в отчёте площадки и в CRM.
• Настроены ли цели так, чтобы серверные события попадали в нужную конверсию.

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

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

Ошибки, которые встречаются чаще всего

Первая ошибка — считать, что после подключения API конверсий число конверсий должно вырасти. Оно может вырасти, а может не измениться. Это зависит от того, сколько событий терял пиксель и как настроена дедупликация.

Вторая ошибка — не проверять event_id. Если идентификатор генерируется заново на сервере и не совпадает с тем, что ушёл в пиксель, дедупликация не сработает. В отчёте появятся дубли, и вы будете думать, что конверсий стало больше, хотя на самом деле одна конверсия посчиталась дважды.

Третья ошибка — подключать серверные события, не проверив настройку целей. Если цель настроена неверно, серверный канал будет передавать события в никуда. Сначала проверьте, что цель фиксирует именно то действие, которое вам нужно.

Четвёртая ошибка — ждать, что API конверсий решит проблему атрибуции. Он её не решает. Если вы не понимаете, какой канал приносит продажи, серверные события не дадут ответа. Для этого нужна сквозная аналитика, собранная своими силами.

Пятая ошибка — не сверять данные площадки с CRM. Если в отчёте площадки конверсий больше, чем в CRM, это повод проверить дедупликацию и атрибуцию, а не радоваться росту.

Как API конверсий связан с UTM-разметкой и CRM

Серверные события передают факт конверсии, но не всегда передают источник. Чтобы понять, откуда пришёл пользователь, нужна разметка ссылок. Если вы запускаете кампании, проверьте, как работает конструктор UTM-меток для ссылок кампании.

Проблема в том, что UTM-метки часто теряются по пути. Пользователь переходит по ссылке с метками, но когда дело доходит до карточки в CRM, метки уже не сохранились. Тогда серверное событие уходит без источника, и связать конверсию с кампанией не получается. Разметка, которая доходит до карточки, — это отдельная задача, и UTM-разметка, которая доходит до карточки в CRM решает именно её.

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

Бывает и обратная ситуация: пиксель стоит, а событий нет. Тогда разбор ситуации «пиксель стоит, событий нет» поможет найти причину до того, как вы будете подключать серверный канал.

Следующий шаг

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