Multi-source conversions: как отдать Google реальные апрувы из Keitaro

16 сентября 2026 года Google выложил документацию по multi-source conversions, бете, которая позволяет подключить к веб-конверсии второй источник данных: CRM, базу заказов или трекер. Второй источник не просто дополняет тег, он становится источником истины по ценности конверсии и перезаписывает то, что тег зафиксировал в момент лида.

Для арбитража на лидовых офферах это закрывает старую дыру. Пиксель отправляет Google конверсию в момент заявки, а деньги приходят только за апрув, через часы или дни. Smart Bidding учится на заявках, а платят за подтверждённые. Разбираем по документации, как работает связка, какие правила нельзя нарушать, и считаем, во что превращается tROAS по тегу при апруве 40 процентов.

Что такое multi-source conversions

Механика простая. У вас есть действие-конверсия на сайте, настроенное через Google tag или Tag Manager. К нему через Data Manager или Data Manager API подключается дополнительный источник: выгрузка из CRM, базы заказов или трекера. Google сверяет события двух источников по одному ключу, transaction_id, и делает три вещи: добавляет конверсии, которые тег не поймал из-за блокировщиков и настроек браузера, перезаписывает ценность конверсии значением из выгрузки и дополняет событие пользовательскими данными вроде хеша почты или телефона, если тег их не собрал.

Google перечисляет пять выгод, и для арбитража важна одна: «отправляйте точные финансовые обновления, такие как пересчёты, допродажи или итоговые суммы корзины из CRM, чтобы перезаписать ценность, записанную тегом». Именно это позволяет превратить заявку в апрув с реальной выплатой уже внутри Google Ads.

Функцию переименовали в августе: раньше она называлась «conversions with multiple data sources», о чём писал PPC News Feed. 16 сентября Search Engine Roundtable сообщил о новой странице справки и трёх сопутствующих документах: диагностика, FAQ и поддерживаемые источники. Статус пока бета: если в вашем аккаунте функции нет, значит, её ещё не выдали.

Второй источник перезаписывает ценность

Главный абзац справки стоит перевести дословно. Дополнительный источник данных становится источником истины по ценности конверсии. Когда transaction_id совпадает с существующим событием тега, ценность из выгрузки навсегда перезаписывает ценность, изначально записанную тегом.

Дальше таблица правил обработки строки. Если transaction_id совпал: ценность и валюта обновляются из выгрузки; пользовательские данные дописываются, только если тег их не собрал; все остальные поля вроде GCLID из выгрузки игнорируются. Если transaction_id не совпал ни с чем, из строки создаётся новое событие конверсии, и Google пытается привязать его к клику по переданным идентификаторам: GCLID, GBRAID, WBRAID или хешу пользовательских данных.

Ноль в ценности допустим, Google приводит пример полного возврата. Для лидов это и есть рабочий сценарий: отклонённая заявка получает ценность 0, подтверждённая реальную выплату. Если строку обновлять не нужно, в ценности ставят NULL, любое число сразу уйдёт в отчёты и в ставки.

Что обязательно передать в выгрузке

Обязательных полей два: transaction_id и дата со временем конверсии. Плюс хотя бы один идентификатор атрибуции: клик-ID (GCLID, GBRAID или WBRAID) или хешированные пользовательские данные. Без идентификатора атрибуции придётся маппить адресные поля. Дальше по желанию: ценность с валютой, поля согласия, user agent и атрибуты сессии.

Требование к самому источнику: это должна быть полная и авторитетная запись всех транзакций, из бэкенда или CRM, а не экспорт из другой тег-аналитики, которая точно так же страдает от потери сигнала. Загружать рекомендуют как можно быстрее, в идеале в течение 24 часов после конверсии. Обновление ценности работает только для конверсий не старше 55 дней.

Ограничение по типу действия: подключить второй источник можно только к веб-конверсии, настроенной вручную кодом через Google tag или Tag Manager. Импортированные конверсии из Google Analytics и конверсии по URL без кода не подходят: у первых объединение должно происходить в GA, у вторых нет transaction_id.

14 дней без ставок и два алерта, которые всё ломают

После подключения источника к биддабельному действию начинается 14-дневный пробный период. Всё это время новые конверсии из выгрузки видны в отчётах и диагностике, но не используются в ставках. Для совпавших transaction_id обновление ценности в Google Ads также отключено до конца пробного периода, как указано в справке. Конверсии тега при этом остаются биддабельными как раньше. Отсчёт идёт с первой полученной выгрузки по каждому действию.

По истечении 14 дней конверсии из второго источника автоматически становятся биддабельными. Важная оговорка из справки: независимо от наличия диагностических алертов. То есть если вы за две недели не починили формат, Smart Bidding начнёт учиться на сломанных данных.

Два алерта уровня Urgent, которые чаще всего и ломают связку. Первый: расхождение ценностей между тегом и вторым источником больше чем в 10 раз за последние два дня. Классическая причина: тег отдаёт 10.00 в долларах, а выгрузка 1000 в центах, и Google читает это как 1000 долларов. Единицы не конвертируются, справка предупреждает об этом трижды. Второй: меньше 10 процентов transaction_id совпало за два дня, статус «конверсии могут считаться дважды». Причины по списку Google: префиксы вроде order-12345 против 12345, регистр, тип 12345 против 12345.0, ведущие нули, заглушки вроде undefined.

Остальные алерты: тег перестал слать данные (48 часов для обычных действий, 7 дней для multi-source), источник не найден, тег не передаёт transaction_id. Смотреть всё это в Goals, Summary, вкладка Diagnostics, карточка «Multi-source conversions».

Как собрать связку с Keitaro

У Keitaro есть штатная интеграция с Google Ads: Maintenance, Integrations, Google Ads. Она забирает расходы по кампаниям каждые 12 часов и отправляет конверсии в Google Ads раз в 6 часов, но только при наличии gclid в клике. Статусы и события, которые уходят в Google, выбираются в разделе Mapping интеграции. Это классический импорт офлайн-конверсий по GCLID, и он решает половину задачи: Google узнаёт об апруве.

Multi-source conversions добавляет вторую половину: апрув не создаёт отдельную офлайн-конверсию, а подтверждает и переоценивает ту, что тег уже отправил на лендинге. Для этого нужно, чтобы transaction_id в событии тега и в выгрузке совпадал. Ключ должен быть уникальным для каждой конверсии внутри действия. Subid Keitaro подходит только если на один клик приходится не более одной такой заявки. Если заявок может быть несколько, создавайте отдельный lead/order ID и храните связь с subid и click-ID в обеих системах.

Дальше по шагам. На лендинге событие лида в Google tag отправляется с параметром transaction_id, равным уникальному ID заявки; subid можно использовать только при одной заявке на клик. Партнёрка присылает постбек со статусом и выплатой, Keitaro пишет их в конверсию. Из трекера регулярно выгружается таблица: transaction_id, gclid, дата и время, ценность в валюте тега (выплата для апрува, 0 для отклонённого), статус согласия. Таблица подключается к действию-конверсии как второй источник через Data Manager: подойдут Google Sheets, SFTP, HTTP, облачное хранилище или база вроде MySQL и PostgreSQL. Для файловых источников Data Manager при каждом запуске забирает данные за 90 дней, для баз данных за 14.

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

Отклонённые лиды с ценностью 0 тоже сигнал: если мусорных заявок много, кампания начнёт уходить от источников мусора. Часть такого мусора можно отсекать ещё до отправки в партнёрку, например проверкой номеров телефонов по API. Похожую связку трекера с рекламной сетью мы разбирали для Meta в материале про Keitaro и Conversions API.

Считаем: реальный ROAS при tROAS по тегу и апруве

Типичная лидовая схема до multi-source: тег отправляет конверсию с ценностью, равной выплате за апрув, потому что другой цифры в момент заявки нет. Smart Bidding держит tROAS по этой ценности. В упрощённой модели при одинаковой выплате и фактически достигнутом ROAS тега на уровне цели реальный ROAS равен этому значению, умноженному на долю апрува. Если цель не достигнута или выплаты различаются, подставлять tROAS напрямую нельзя.

При tROAS 200 процентов и апруве 40 реальный ROAS 80: минус ещё до расходов на домены и креативы. Чтобы получить реальные 150 при том же апруве, tROAS по тегу пришлось бы ставить 375. При этом тег ничего не знает про апрув, и кампания продолжает оптимизироваться под заявки, а не под деньги.

После подключения второго источника ценность каждого лида переписывается фактом: 0 для отклонённого, выплата для подтверждённого. Через 14 дней Smart Bidding учится уже на этих значениях, но tROAS 200 остаётся целевой, а не гарантированной фактической окупаемостью. Проверяйте достигнутый ROAS, задержку апрувов и полноту выгрузки. Кампания начинает искать не тех, кто оставляет заявку, а тех, кого подтверждает партнёрка. После того как Google убрал подушку бюджета и цель стала единственным рычагом, точность этой цели решает всё.

Чем это отличается от расширенных конверсий и офлайн-импорта

Расширенные конверсии укрепляют событие самого тега: добавляют к нему хешированные данные пользователя, чтобы лучше сопоставить с кликом. Офлайн-импорт по GCLID создаёт отдельную конверсию из внешней системы. Multi-source конверсии делают третье: сшивают событие тега и запись из бэкенда в одно событие с правом бэкенда переписать ценность. Google в FAQ отдельно не советует заводить под тест отдельное действие-конверсию: сравнение двух действий даёт разрыв в отчётах на время калибровки, нужен 28-дневный прогрев и метрика «All conv. (by conv. time)».

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

Чеклист перед подключением

• Проверить, что действие-конверсия настроено кодом через Google tag или Tag Manager, а не по URL и не импортом из GA.
• Добавить transaction_id в событие тега на лендинге и убедиться, что он приходит на каждый лид: без него включится алерт «тег не передаёт transaction ID».
• Выбрать уникальный ID заявки и передавать одну и ту же строку в теге и выгрузке. Subid подходит только при одной конверсии на клик. Не меняйте регистр, префиксы и ведущие нули уже существующих ID независимо в разных системах.
• Ценность в выгрузке в тех же единицах, что у тега: 42.00, а не 4200. Иначе через два дня придёт алерт о десятикратном расхождении.
• Отклонённым лидам ставить 0, а не NULL: NULL означает «не обновлять».
• Выгружать не реже раза в день, в идеале в течение 24 часов после статуса; апрувы старше 55 дней ценность уже не обновят.
• Первые 14 дней смотреть вкладку Diagnostics каждый день: после пробного периода данные пойдут в ставки независимо от алертов.

Частые вопросы

Материал носит информационный характер. Описание функции приведено по справке Google Ads и документации Data Manager API на 18 сентября 2026 года, функция в статусе беты и может быть недоступна в вашем аккаунте. Расчёт реального ROAS выполнен редакцией, схема связки с Keitaro собрана по документации трекера.