Server-side tracking и CAPI: что подготовить до внедрения
Как подготовить контракт событий, идентификаторы, согласие, повторные отправки и критерии приёмки серверного трекинга.
Сначала назовите проблему измерения
Запрос «нам нужен CAPI» ещё не объясняет, что именно перестало работать. Возможно, браузерное событие срабатывает дважды, CRM не возвращает статус продажи или отчёт сравнивает разные периоды. Серверная интеграция может передавать события из другой точки процесса, но сама по себе не исправляет неверные определения и не доказывает прирост продаж.
Зафиксируйте конкретный разрыв: какой факт известен бизнес-системе, где он теряется и какое решение из-за этого нельзя принять. Например, заявка создаётся на сайте, а подтверждённая продажа появляется позднее в CRM. Это два разных события с разными источниками истины. Их не следует объединять под одним названием ради более высокой цифры конверсий.
Различайте серверный контейнер и API площадки
Server-side tagging описывает схему, в которой серверный контейнер принимает запросы, обрабатывает их и отправляет данные через настроенные теги. Conversions API — интерфейс передачи событий конкретной рекламной системы. Эти части могут работать совместно, но не являются взаимозаменяемыми названиями одного продукта. Для проекта важно нарисовать фактический маршрут, а не выбрать модную аббревиатуру.
На схеме обозначьте браузер, сайт, сервер приложения, CRM и получателей. Для каждой стрелки укажите владельца интеграции и точку диагностики. Если событие формирует CRM, уточните, при каком изменении записи происходит отправка. Если его создаёт браузер, выясните, какие сведения сервер только пересылает, а какие проверяет самостоятельно. Такой разбор предотвращает ложное ощущение независимого подтверждения.
Опишите контракт каждого события
Контракт — короткая спецификация, по которой разработчик и аналитик одинаково понимают событие. Включите название, бизнес-условие, время фактического действия, стабильный идентификатор и источник данных. Для денежных значений отдельно согласуйте валюту, возвраты и то, какая сумма передаётся. Отсутствующее значение нельзя незаметно заменять нулём, если это меняет смысл.
В официальной серверной модели события Meta предусмотрены поля event_name, event_time и event_id. Наличие полей в SDK не подтверждает корректность вашей интеграции: правила выбранного API проверяются отдельно. Ниже — условный контракт, который помогает подготовить такую проверку.
| Событие | Условие | Идентификатор и проверка |
|---|---|---|
| Заявка создана | Форма принята и запись сохранена | ID заявки; отправка формы не равна сохранению |
| Лид квалифицирован | Выполнены согласованные критерии | ID перехода; изменение комментария не создаёт новый факт |
| Оплата подтверждена | Платёжная система подтвердила оплату | ID платежа; повтор уведомления не является второй оплатой |
Разберите повторы, задержки и исправления
Один факт может попасть в систему по двум каналам или повторно после сетевой ошибки. Заранее определите, как каналы узнают одно действие: одинаковый стабильный ключ, журнал отправок и согласованные правила повторной доставки. Не создавайте новый идентификатор при каждой технической попытке, если бизнес-событие осталось тем же. Конкретные условия дедупликации уточняйте в документации принимающей площадки.
Отдельно опишите поздние события, отмены и возвраты. Какой статус считается окончательным, кто исправляет ошибку и что видит отчёт до исправления? Сохраните связь между фактом, попытками отправки и ответами получателя. Успешный HTTP-ответ подтверждает определённый этап доставки, но не заменяет проверку того, как событие принято и отражено в нужном отчёте.
Передайте настройки согласия по всей цепочке
Перенос отправки на сервер не отменяет требований к данным и выбору пользователя. Определите, какие сведения разрешено передавать в каждом состоянии, откуда сервер получает это состояние и что происходит при его изменении. Google описывает передачу сигналов согласия от веб-контейнера к серверному; применимость конкретной схемы нужно проверить в вашей конфигурации.
Не включайте контактные данные в UTM или адрес страницы ради связывания событий. Инструмент utm-audit проверяет предоставленные ссылки и помогает заметить проблемы меток. Он не разворачивает серверный контейнер, не диагностирует CAPI и не подтверждает соблюдение требований к обработке данных. Эти проверки выполняются отдельными средствами и ответственными участниками команды.
Принимайте интеграцию по тестовой матрице
Подготовьте синтетические сценарии: обычная отправка, повтор, отказ получателя, задержка, изменение согласия и отмена бизнес-действия. Для каждого задайте ожидаемое число фактов и ожидаемый статус. Затем сопоставьте журнал источника, журнал доставки и интерфейс получателя. Так проверяется конкретная цепочка, а не только наличие события в отладчике.
После выпуска наблюдайте за расхождениями и очередью ошибок в согласованный период. Сравнение до и после должно учитывать определения, трафик и настройки атрибуции. Более высокая зарегистрированная выручка может означать лучшее покрытие измерения, а не дополнительный доход. Итог внедрения формулируйте через проверенные свойства доставки и качество данных; коммерческий эффект требует отдельной оценки.
Применить на практике
Частые вопросы
CAPI заменяет браузерные события?
Это зависит от архитектуры и требований площадки. Если оба канала передают один факт, нужно согласовать идентификаторы и проверить обработку повторов; просто включить второй канал недостаточно.
Почему после внедрения выросло число конверсий?
Возможны лучшее покрытие, новые определения, изменение атрибуции или дубли. Сначала сопоставьте реальные бизнес-факты и журналы событий, затем делайте вывод о результате рекламы.