Приёмочный тест конверсий: отправлено, принято и учтено

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

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

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

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

Для каждого прогона сохраните собственный обезличенный протокол: запрос, ответ и тестовый режим. Затем проверьте приёмник. Ответ API и видимая запись о событии подтверждают разные этапы, а действие тестового флага зависит от платформы.

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

Что площадки записывают в документацию как «принято»

Правила приёмников нужно читать отдельно: Meta Conversions API, OpenAI Ads Conversions API и Snap Conversions API по-разному обрабатывают валидацию и тестовые запросы.

Meta задаёт общий предел для event_time: семь дней. Более старое значение вызывает ошибку всего запроса, и события не обрабатываются. В том же руководстве отдельно указано, что офлайн-транзакции и покупки в физических магазинах с action_source: physical_store следует загружать в течение 62 дней после конверсии. Учитывайте эту оговорку при проверке соответствующего источника. В другом описанном случае некорректного события запрос возвращает ошибку, но валидные события с event_id принимаются. Руководство предлагает исправить некорректные события и повторить пакет: уже сохранённые события будут отброшены как дубли. Это описанный случай Meta, а не правило для любой ошибки или API.

Это разные наблюдения в Events Manager. Рекомендация Meta проверить события в течение 20 минут не является SLA доставки. События с test_event_code попадают в Events Manager и используются для таргетинга и измерения рекламы; из рабочего payload код нужно убрать.

В OpenAI флаг validate_only: true включает проверку без сохранения событий. Этот API описывает отказ всего пакета, если одно событие не прошло обработку. При повторной отправке или передаче той же конверсии через другую интеграцию используйте прежний id. Поле timestamp_ms должно указывать время в пределах последних семи дней и не более чем на десять минут в будущем. Эти правила не задают срок хранения и не подтверждают атрибуцию; валидация сама по себе не доказывает сохранение.

Endpoint Snap POST /v2/conversion/validate принимает тестовые события, которые не учитываются как рабочие данные. Ответ перечисляет проверенные поля, предупреждения и ошибки, препятствующие обработке при рабочей отправке. В тестовых журналах используются статусы VALID, INVALID и VALID_WITH_WARNINGS: они описывают корректность запроса, а не атрибуцию рабочей конверсии. Справочник отдельно различает код 005 (ошибка всех записей) и 006 (часть записей не удалось обработать). Разбирайте фактический код и детали записей, не приписывая всем ошибкам Snap один результат.

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

Как провести приёмочный тест конверсий по шагам

Проверьте один бизнес-сценарий в нескольких приёмниках и оформите отдельный протокол для каждого запроса.

1. Выберите сценарий и отметьте, синтетические ли это данные или реальное событие. Синтетический пример проверяет форму и обработку запроса, но не подтверждает атрибуцию.
2. Проверяйте приёмники отдельно. Pixel Activator допускает до пяти событий за отправку.
3. Уточните аккаунт назначения и используйте выданные владельцем учётные данные. Для одной платформы порядок разобран в гайде Meta CAPI.
4. Запишите точный тестовый режим и его документированные последствия. Meta может использовать тестовые события для таргетинга и измерения рекламы; режим валидации OpenAI не сохраняет события.
5. Сохраните обезличенные запрос и ответ, включая ошибки отдельных событий, если они доступны.
6. Проверьте представление приёмника, подходящее для выбранного режима. Для Meta есть разбор проверки через Test Events.
7. Укажите для каждого наблюдения результат: подтверждено, отклонено, ожидает проверки или неприменимо. Приём, сохранение и атрибуцию оценивайте отдельно.

Этот шаблон заполняют для каждого приёмника. Он описывает протокол проверки, а не payload API.

сценарий      = <описание и отметка о синтетических или реальных данных>
приёмник      = <платформа и скрытый идентификатор аккаунта>
запрос        = <ссылка на обезличенный запрос>
режим         = <фактический флаг или endpoint>
ответ         = <обезличенный ответ и ошибки отдельных событий>
отправлено    = <доказательство либо неизвестно>
принято       = <доказательство либо неизвестно>
учтено        = <представление, время проверки, результат либо неприменимо>
атрибуция     = <не проверена без отдельного доказательства>
маршрутизация = <независимые запросы её не проверяют>

Симптом, доказательство, следующий тест

Политику повторов проектируют отдельно от ручной проверки; см. идемпотентность и ретраи. Ошибки разбирайте по справочнику CAPI и документации приёмника.

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

На публичной странице Pixel сказано, что события вроде Purchase отправляются со значением 1 USD. Такая проверка не подтверждает сумму и валюту рабочей интеграции. Их передачу проверяют отдельно, в том числе при использовании ChatGPT Ads через Pixel Activator.

Ручной запрос также не проверяет дедупликацию браузерного и серверного событий. Для неё нужны оба события и идентификаторы конкретного приёмника; для Meta это разобрано в статье о сопоставлении событий клиента и сервера.

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

Источники