Дополнительные источники данных конверсий Google Ads 2026

У вас в Google Ads 100 заказов в CRM и 83 конверсии в интерфейсе. Разница — не ошибка отчёта, а конверсии, которые не доехали до тега: пользователь закрыл вкладку до срабатывания скрипта, блокировщик вырезал запрос, часть сессии прошла в in-app браузере, кто-то не дал согласия на аналитику. В сентябре 2026 Google открыл бету, которая закрывает именно этот разрыв: дополнительные источники данных конверсий — механизм, который подключает вашу CRM или базу заказов напрямую к уже существующему конверсионному действию на сайте и дозаполняет пропуски, не создавая дублей.

В этой статье — что это за механизм, чем он принципиально отличается от расширенных конверсий и импорта офлайн-конверсий, какие поля обязательны при загрузке, как устроена дедупликация по transaction ID, пошаговая настройка, как проверить результат и семь ошибок, из-за которых вместо восстановленных конверсий вы получите двойной счёт и сломанные ставки.

Что такое дополнительные источники данных конверсий

Классическая схема измерения выглядит так: пользователь кликнул по объявлению, дошёл до страницы «спасибо», там сработал Google tag, конверсия записалась. Всё, что ломает последний шаг, ломает и измерение — а ломается он гораздо чаще, чем кажется по отчётам.

Дополнительные источники данных (в англоязычной документации — supplemental conversion data / multi-source conversions) меняют логику: конверсионное действие остаётся тем же самым, но у него появляется второй канал поступления данных. Кроме тега в него пишет ваша серверная система — CRM, база заказов, платформа электронной коммерции. Google сопоставляет две записи об одной и той же сделке и оставляет одну.

Ключевая мысль, которую стоит зафиксировать сразу: это не новое конверсионное действие и не замена тега. Это надстройка над существующим действием. Если завести под серверные данные отдельную конверсию «Покупка (CRM)» и оставить рядом «Покупка (тег)», вы получите ровно то, от чего механизм должен спасать — задвоение.

Почему конверсии теряются

Ограничения браузеров. ITP и аналогичные механизмы сокращают жизнь клиентских cookie до считанных дней, часть атрибуции просто истекает.
Блокировщики и корпоративные фильтры. Запрос к серверам Google не уходит вообще.
Обрыв на последнем шаге. Пользователь закрывает вкладку сразу после оплаты, страница благодарности не догружается.
Согласие. При отказе от аналитических cookie измерение переходит в моделирование — про механику мы разбирали в материале про серверный трекинг sGTM и возврат потерянных конверсий.
Оффлайн-хвост. Заказ оформлен онлайн, но подтверждён в колл-центре через сутки — тег об этом не знает.

По отраслевым оценкам расхождение между CRM и рекламным кабинетом у e-commerce и лидогенерации держится в диапазоне 8–25% — это ориентир, а не константа: в вашем аккаунте цифра зависит от географии, устройств и того, насколько агрессивно настроен баннер согласия. Считать нужно по своим данным, а не по чужому бенчмарку.

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

Три инструмента легко перепутать, потому что все три «дополняют данные». Разница — в том, что именно они дополняют.

Инструмент	Что делает	Когда применять
Расширенные конверсии	Добавляет к уже сработавшей конверсии тега хешированные данные пользователя, чтобы повысить точность сопоставления с кликом	Тег сработал, но атрибуция шаткая
Импорт офлайн-конверсий	Загружает события, которых на сайте не было вовсе: квалификация лида, подписанный договор, оплата по счёту	Сделка закрывается вне сайта, иногда через недели
Дополнительные источники данных	Достраивает те же самые веб-конверсии, которые тег не записал, и дедуплицирует их с тегом	Тег не сработал, но заказ на сайте состоялся

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

Требования к загрузке: три обязательных поля

Каждая запись, которую вы отправляете в дополнительный источник, обязана содержать три вещи.

1. Transaction ID

Уникальный идентификатор сделки — номер заказа, ID транзакции, ID записи в CRM. Именно по нему Google сопоставляет вашу серверную запись с тем, что (возможно) прислал тег. Критическое требование: тег на сайте должен отправлять ровно тот же идентификатор. Если на фронте вы передаёте ORD-10245, а из CRM выгружаете 10245 — это две разные сделки для системы, и вы получите двойной счёт.

2. Дата и время конверсии

С указанием часового пояса. Здесь чаще всего ошибаются: время берут из локального часового пояса сервера, а аккаунт работает в другом. Смещение на несколько часов размажет конверсии по соседним дням и испортит отчётность по дням недели и часам.

3. Хотя бы один идентификатор атрибуции

Либо идентификатор клика (GCLID, а для iOS-трафика — GBRAID или WBRAID), либо хешированные данные пользователя (email, телефон, имя и адрес — по алгоритму SHA-256, в нормализованном виде). Идентификатор клика точнее; хешированные данные работают, когда клик-ID не сохранился. Про то, как не потерять идентификатор клика по дороге от объявления до CRM, есть отдельный разбор — точный сигнал на first-party данных начинается именно с этого.

Дополнительно: ценность конверсии и валюту нужно передавать в том же формате, что и тег. Разная валюта на одном конверсионном действии — типовая причина того, что ROAS в отчёте вдруг вырастает в 80 раз.

Что поддерживается, а что нет

Поддерживается: веб-конверсии, настроенные через Google tag или Google Tag Manager.
Не поддерживается: конверсии, импортированные из GA4, и конверсии, определённые по URL страницы.
Требуется: Data Manager или Data Manager API для подключения источника.

Ограничение по GA4-импорту логичное: у такой конверсии нет собственного тега, к которому можно «подшить» второй источник. Если ваши ключевые конверсии до сих пор живут импортом из GA4, сначала переведите их на собственное конверсионное действие Google Ads — это в любом случае правильнее для Smart Bidding.

Как работает дедупликация — и как её ломают

Механика простая: приходят две записи с одинаковым transaction ID — засчитывается одна. Приходит только серверная — засчитывается она. Приходит только тег — засчитывается он.

Ломается это тремя способами, и все три встречаются в первый же месяц после подключения.

Разный формат идентификатора. Префиксы, ведущие нули, регистр букв, пробелы по краям. Нормализуйте идентификатор на обеих сторонах до одного вида и зафиксируйте правило в документации по трекингу.
Тег вообще не передаёт transaction ID. Классика: в dataLayer есть value и currency, а transaction_id забыли. Тогда дедуплицировать нечего — любая серверная запись считается новой конверсией.
Генерация идентификатора на лету. Если на «спасибо» идентификатор формируется случайно (например, от таймстампа), при повторном заходе на ту же страницу он будет другим. Идентификатор должен приходить из бэкенда, а не рождаться в браузере.

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

Настройка: семь шагов

Выберите одно конверсионное действие. Не все сразу. Берите главное — покупку или квалифицированный лид.
Убедитесь, что тег передаёт transaction ID. Проверьте в режиме предпросмотра GTM и в отладчике тега: поле должно приходить на каждой конверсии, а не на 70% из них.
Подготовьте выгрузку на стороне CRM. Минимум: transaction ID, дата-время с часовым поясом, GCLID (или хешированные контакты), ценность, валюта.
Подключите источник в Data Manager. Механика подключения источников и нормализации данных описана в разборе Data Manager и данных первой стороны.
Привяжите источник к выбранному конверсионному действию. Не создавайте новое действие — это принципиально.
Запустите на тестовом объёме. Выгрузите данные за один прошлый день и сверьте: сколько записей совпало с тегом, сколько добавилось, сколько отклонено с ошибкой.
Автоматизируйте регулярную выгрузку. Через Data Manager API или встроенный коннектор вашей платформы.

Окно загрузки: почему сутки — не формальность

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

Причина не в бюрократии, а в том, как работает Smart Bidding. Алгоритм переоценивает аукционы на основании свежего сигнала; конверсия, которая доехала через десять дней, повлияет на отчёт, но почти не повлияет на обучение. Это тот же эффект, из-за которого «вчерашний ROAS» систематически врёт — подробно мы разбирали его в статье про диагностику отслеживания конверсий за 30 минут.

Отсюда практическое следствие: если ваша CRM физически не умеет отдавать данные чаще раза в сутки — это нормально и достаточно. Если умеет чаще, ставьте расписание на каждый час: хуже не будет.

Как проверить, что стало лучше

Подключить источник легко, а вот доказать эффект — отдельная работа. Три способа, от простого к надёжному.

Сверка с CRM по дням

Берёте 14 дней до подключения и 14 после. Считаете соотношение «конверсий в Google Ads / заказов в CRM с рекламного источника». Если до было 0,83, а стало 0,95 — механизм работает. Если стало 1,12 — у вас дубли, немедленно останавливайте загрузку и проверяйте transaction ID.

Метрика прироста от данных первой стороны

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

Контрольный период

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

Семь ошибок, которые превращают прирост в двойной счёт

Создать отдельное конверсионное действие под CRM. Самая дорогая ошибка: алгоритм видит в два раза больше конверсий и разгоняет ставки до убыточных.
Грузить в источник все заказы подряд, включая органику и прямые заходы. Без идентификатора атрибуции они не сматчатся, но забьют лимиты и отчёт об ошибках.
Не отсекать отменённые и возвращённые заказы. Механизм добавляет конверсии, но не убирает их. Возвраты закрываются корректировками конверсий — это отдельный инструмент.
Разные валюты у тега и у выгрузки. Проверяется за минуту, ломает отчётность на месяц.
Хеширование «как получится». Без нормализации (нижний регистр, обрезка пробелов, телефон в формате E.164) доля совпадений падает в разы.
Загрузка задним числом за три месяца в первый же день. Резкий всплеск конверсий за прошлые даты перекраивает историю, на которой училась стратегия ставок.
Никто не смотрит отчёт об ошибках загрузки. Часть записей всегда отклоняется — по формату даты, по невалидному хешу, по отсутствию идентификатора. Если не читать этот отчёт, можно полгода думать, что грузится 100%, а грузиться будет 60%.

Что это меняет для ставок

Больше корректных конверсий — точнее обучение. Но переход не бесплатный: в первые дни после подключения объём конверсий в отчёте растёт, и автоматические стратегии реагируют на это как на рост спроса. Фактический CPA в системе падает, алгоритм становится агрессивнее в аукционах, расход растёт.

Что делать:

Не менять tCPA/tROAS одновременно с подключением. Дайте стратегии 7–14 дней перестроиться.
Если через две недели цель систематически перевыполняется, пересчитайте её на новую базу конверсий, а не на старую.
Смотрите на деньги в CRM, а не на конверсии в кабинете. Восстановленная конверсия — это не новая выручка, это ранее невидимая выручка.

Последний пункт — главный. Дополнительные источники не приносят продаж, они делают видимыми уже случившиеся. Если после подключения вы увидели +15% конверсий и обрадовались росту, вы обманываете себя: выручка не изменилась, изменилась её наблюдаемость. Зато на новой базе можно наконец честно считать, сколько вы готовы платить за клик — этот расчёт разобран в материале про оптимизацию по прибыли вместо ROAS.

Когда подключать не стоит

У вас меньше 30 конверсий в месяц. Разрыв измерения в таком объёме не отличить от шума, а риск дублей реальный.
Тег не передаёт transaction ID и починить это некому. Сначала техническая база, потом надстройки.
Ключевые конверсии импортируются из GA4. Механизм их не поддерживает; сначала переведите их на нативное конверсионное действие.
В CRM нет дисциплины по источникам. Если менеджер вручную проставляет «Реклама» по памяти, вы загрузите в Google Ads чужие заказы.

Ещё одно практическое замечание. Бета-функции в Google Ads меняются: доступ расширяется волнами, названия полей корректируются, требования уточняются. Перед внедрением сверьтесь с актуальной справкой Google — описанное здесь отражает состояние на конец сентября 2026 года. Если у вас нет доступа к бете, всё описанное частично закрывается связкой «расширенные конверсии + импорт офлайн-конверсий», и начинать разумно именно с неё.

Как это ложится в общую картину измерения

Дополнительные источники — третий слой в стеке измерения, и он имеет смысл только когда первые два на месте:

Базовый слой: корректный тег, уникальные transaction ID, одно конверсионное действие на одно бизнес-событие.
Слой устойчивости: расширенные конверсии, серверный контейнер, согласие настроено так, что сигнал не обнуляется.
Слой достройки: дополнительные источники данных, импорт офлайн-конверсий, корректировки на возвраты.

Поверх этого живёт отчётность — и здесь важно понимать, какие цифры вы вообще смотрите. Новые AI-дашборды в Google Ads умеют собрать отчёт по текстовому запросу, но не скажут вам, какая доля конверсий в нём модельная, а какая наблюдаемая. А управление ставками на уровне отдельных товаров через Product Value Optimization вообще бессмысленно, если ценность конверсии приходит с ошибкой: множители на кривых данных просто умножат ошибку.

Измерение не приносит денег напрямую — оно решает, куда алгоритм понесёт ваш бюджет. Конверсия, которой Google не видит, для ставок не существует, даже если деньги за неё лежат на счету.

FAQ

Чем дополнительные источники данных конверсий отличаются от расширенных конверсий?

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

Нужно ли создавать отдельное конверсионное действие под данные из CRM?

Нет, и это критично. Источник подключается к существующему веб-конверсионному действию. Отдельное действие приведёт к двойному счёту и разгону ставок.

Что обязательно должно быть в каждой загружаемой записи?

Transaction ID, дата и время конверсии с часовым поясом и хотя бы один идентификатор атрибуции — GCLID/GBRAID/WBRAID или хешированные данные пользователя. Ценность и валюту нужно передавать в том же формате, что и тег.

Работает ли это с конверсиями, импортированными из GA4?

Нет. Поддерживаются только веб-конверсии, настроенные через Google tag или Google Tag Manager. Конверсии по URL страницы тоже не поддерживаются.

Как Google понимает, что моя запись и запись тега — это одна сделка?

По transaction ID. Именно поэтому идентификатор на сайте и в выгрузке должен совпадать посимвольно, включая префиксы и ведущие нули.

Как быстро нужно загружать данные?

Ориентир для беты — в пределах суток после конверсии. Более поздняя загрузка попадёт в отчётность, но почти не повлияет на обучение стратегии ставок.

Что будет со ставками сразу после подключения?

Число конверсий в отчёте вырастет, фактический CPA в системе снизится, и автостратегия станет агрессивнее. Не меняйте цели первые 7–14 дней, дайте алгоритму перестроиться, потом пересчитайте tCPA или tROAS на новую базу.

Можно ли так загрузить отмены и возвраты?

Нет. Механизм только добавляет конверсии. Для отмены и уменьшения ценности используются корректировки конверсий — это отдельный инструмент со своей логикой.

Как понять, что появились дубли?

Сверьте отношение «конверсии в Google Ads / заказы с рекламы в CRM» до и после подключения. Значение выше единицы — почти всегда дубль из-за несовпадающих transaction ID.

Обязателен ли Data Manager?

Да, подключение источника идёт через Data Manager или Data Manager API. Это же место, где настраиваются другие потоки данных первой стороны, поэтому связка получается естественной.

Если у меня нет доступа к бете — что делать сейчас?

Включить расширенные конверсии, привести в порядок передачу transaction ID, настроить импорт офлайн-конверсий для событий вне сайта. Это закрывает значительную часть того же разрыва и в любом случае является предусловием для подключения дополнительных источников.

Это увеличит мою выручку?

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

Что делать дальше

Порядок действий на ближайшую неделю: проверить, передаёт ли тег transaction ID на всех конверсиях; сверить конверсии в кабинете с заказами в CRM за 14 дней и зафиксировать текущий разрыв; убедиться, что ключевые конверсии не импортируются из GA4; подготовить тестовую выгрузку за один день и посмотреть отчёт об ошибках. Этого достаточно, чтобы понять, даст ли вам механизм реальный прирост или сначала нужно чинить базу.

Если инфраструктура в порядке, а упирается всё в доступ к инструментам и стабильность самого рекламного аккаунта — у PPC Rebels есть агентские аккаунты Google Ads и обучение по работе с Google Ads, где разбор измерения занимает отдельный блок. Начать можно и с бесплатного гайда по Google Ads — базовые вещи вроде корректной передачи идентификатора заказа там разобраны на уровне «что нажать».

Дополнительные источники данных конверсий в Google Ads 2026: как достроить конверсии из CRM