Conversions API не работает: где теряется событие

Подтвердить формирование и отправку запроса

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

Далее проследите передачу из обработчика к вызову API. В официальном Python Business SDK показана конструкция Event и EventRequest.execute; это подтверждает способ формирования запроса, но не факт исполнения вашей интеграции. Сохраните обезличенную запись попытки отправки, время и идентификатор внутренней операции. При очереди отдельно проверьте постановку задачи и её обработку, чтобы увидеть участок, на котором действие остановилось.

Прочитать ответ без подмены результата

Сохраните ответ API рядом с конкретной попыткой отправки. В проверенной версии официального SDK EventRequest формирует ответ с events_received, messages и fbtrace_id. Разберите полученные значения и сообщения применительно к запросу. Сам факт возврата ответа ещё не доказывает появление записи в интерфейсе, корректную атрибуцию рекламному контакту или создание подходящего лида в системе продаж.

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

Проверить смысл и согласованность параметров

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

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

Разделить видимость и рекламную атрибуцию

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

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

Оформить исправление с проверяемым завершением

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

В итоговом отчёте укажите использованные официальные источники и границы вывода. Проверенный код SDK подтверждает поля и конструкцию ответа, но не правила текущего интерфейса и не восстановление аккаунта. Следующий этап выбирайте по доказанному разрыву: исправление сайта, обработчика, передачи или отчётного сопоставления. Такая последовательность помогает устранить причину, сохраняя различие между техническим событием и коммерческим результатом.

Что проверим в вашем проекте

Вопросы по теме