Как перенести офлайн-конверсии Google Ads в Data Manager API

Перед переходом на Data Manager API сохраните контрольный период старого импорта, состав полей и идентификаторы действий-конверсий. Затем перенесите одну небольшую партию, зафиксируйте request_id, дождитесь асинхронной диагностики и только после сверки отключайте прежний маршрут.

Google объявил, что с 15 июня 2026 года загрузки офлайн-конверсий и enhanced conversions for leads переходят на Data Manager API. В документации Google Ads API отдельно уточнено: UploadClickConversions не работает для разработческих токенов без прежней активности по таким загрузкам; для новых и будущих интеграций рекомендован Data Manager API. Наличие старого работающего токена не стоит считать долгосрочным планом — сначала проверьте фактический маршрут своего аккаунта и подготовьте управляемое переключение.

Сначала опишите текущий контракт данных

Не начинайте с переписывания запроса. Сохраните одну страницу с тем, что уже означает офлайн-конверсия в вашем процессе:

Если критерий события ещё не определён, сначала настройте статусы и причины отказа в CRM. Миграция транспорта не исправляет расплывчатое значение qualified_lead.

Сопоставьте старые поля с новой схемой

В таблице перехода Google поля меняются не только по названию. Например, conversion_date_time становится event_timestamp в RFC 3339, order_id — transaction_id, currency_code — currency, а идентификаторы пользователя перемещаются в user_data.user_identifiers. Аккаунт и действие-конверсия задаются через Destination: operating_account должен владеть действием, а product_destination_id содержит его числовой ID.

Минимальная карта для рабочей проверки:

Data Manager API требует как минимум один допустимый способ сопоставления: рекламный идентификатор, атрибуты сессии, пользовательские данные либо поддерживаемые сведения об устройстве. Не отправляйте email или телефон открытым текстом: документация требует форматировать и хешировать пользовательские идентификаторы.

Проведите локальную проверку до API

Возьмём вымышленное событие на 25 BYN:

{
  "lead_id": "L-1042",
  "event_timestamp": "2026-10-21T14:25:00+03:00",
  "transaction_id": "qualified-L-1042-v1",
  "conversion_value": 25.00,
  "currency": "BYN",
  "gclid": "TEST-GCLID-REDACTED"
}

Это учебная строка, а не готовый запрос. До сборки Event проверьте:

1. event_timestamp разбирается как RFC 3339 и содержит смещение;
2. transaction_id не пуст и не повторяется внутри выбранного окна;
3. ценность числовая, валюта заполнена вместе с ней;
4. есть хотя бы один разрешённый идентификатор;
5. действие-конверсия принадлежит указанному operating_account;
6. пользовательские данные нормализованы, хешированы и передаются только при нужном правовом основании.

Плохую строку лучше отправить в карантин, а не добавлять в пробную пачку. При миграции это особенно важно: Data Manager API использует модель fast-fail — ошибка проверки любого поля может отклонить весь IngestEventsRequest, тогда как старый процесс мог возвращать частичный результат.

Разделите приём запроса и обработку событий

HTTP 200 подтверждает, что запрос принят синхронным слоем. Он ещё не доказывает, что события обработаны и появятся в отчёте. Сохраните request_id вместе с контрольной суммой исходной партии, числом строк, временем отправки и ID действия-конверсии.

Google рекомендует запрашивать диагностику по request_id через 30 минут, затем повторять с увеличивающимся интервалом, пока назначение не получит SUCCESS, PARTIAL_SUCCESS или FAILURE. Обработка может занять до 24 часов. Даже при SUCCESS нужно просмотреть предупреждения: warning не отклоняет запись, но может означать, что часть данных была проигнорирована.

Учебная схема показывает границы проверки. Она не изображает фактический результат конкретного аккаунта.

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

Не включайте два маршрута без защиты от дублей

При переключении старый и новый процессы могут выбрать одну и ту же строку CRM. В Data Manager API transaction_id используется для дедупликации внутри одного действия-конверсии; карта миграции прямо связывает его со старым order_id. Сохраните это значение без переизобретения и не создавайте новый ID при сетевом повторе.

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

• оба маршрута пишут в одно действие-конверсию или в разные;
• одинаков ли идентификатор транзакции;
• кто блокирует повторную выборку события — CRM, очередь или загрузчик.

Если вы создаёте новое действие-конверсию для Data Manager, не рассчитывайте на дедупликацию между разными действиями. На время проверки исключите новое действие из ставок либо следуйте настройкам своего аккаунта, чтобы тестовая партия не изменила оптимизацию кампаний до приёмки.

Примите миграцию по шести доказательствам

Миграция завершена, когда одновременно выполнены условия:

1. число подходящих CRM-событий за контрольное окно известно;
2. локальная проверка не пропускает неверные время, валюту, ID и идентификаторы;
3. каждый рабочий запрос сохраняет request_id и состав партии;
4. асинхронная диагностика завершилась, ошибки и предупреждения разобраны;
5. в Google Ads событие найдено по правильному действию и времени конверсии;
6. после отключения старого маршрута следующая регулярная партия пришла по расписанию без дублей.

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

Остановитесь, если доказательств не хватает

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

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

Источники

• Источник 1
• Источник 2
• Источник 3
• Источник 4
• Источник 5
• Источник 6
• Источник 7

Материал подготовлен редакцией WiseLab с помощью AI. Источники и фактические утверждения проверены при подготовке.