Расширенные конверсии в Google Ads: как настроить и проверить

Что делают расширенные конверсии и что теряется без них

Обычное отслеживание конверсий держится на связке клика и куки. Человек кликает по объявлению, Google дописывает к ссылке идентификатор клика GCLID, тег сохраняет его в куку на вашем домене, а на странице благодарности конверсионный тег отправляет пинг с этим идентификатором. Google сопоставляет клик и конверсию, конверсия попадает в отчет.

Цепочка рвется в нескольких местах. Safari режет срок хранения куки первой стороны, блокировщики вырезают запросы к рекламным доменам, человек кликает с телефона, а покупает с ноутбука, часть аудитории заходит в режиме инкогнито, часть отказывается от рекламных кук в баннере согласия. Конверсия при этом происходит: заказ оплачен, заявка в CRM, деньги в кассе. В отчете Google Ads ее нет, потому что связать конверсию с кликом системе нечем.

Расширенные конверсии закрывают этот разрыв. Механика описана в справке Google четырьмя шагами:

• авторизованный в Google человек видит ваше объявление и кликает по нему;
• он конвертируется на сайте: оформляет заказ или отправляет форму;
• конверсионный тег забирает с этой страницы поле, которое вы указали, например адрес почты, хеширует его и отправляет в Google в хешированном виде;
• Google сравнивает полученный хеш с хешированными данными авторизованных аккаунтов, находит человека, находит его клик и записывает конверсию в ваш аккаунт.

Второй путь сопоставления работает там, где не сработал первый. Куки нет, GCLID потерян, устройство другое - хеш почты все равно совпадет, если человек был авторизован в Google в момент контакта с рекламой.

Разница между обычным и расширенным отслеживанием не в количестве конверсий на сайте. Оно не меняется. Меняется доля тех конверсий, которые Google видит и приписывает конкретной кампании. Поэтому корректная формулировка для клиента звучит так: мы не добавляем конверсии, мы возвращаем в отчет те, что уже произошли, но потерялись по дороге.

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

Базовая настройка отслеживания - тег, GTM, импорт целей, проверка срабатывания - разобрана отдельно в статье про настройку отслеживания конверсий в Google Ads. Расширенные конверсии надстраиваются поверх работающего отслеживания и без него не запускаются: нечего дополнять.

Веб и лиды: почему в 2026 остался один переключатель

До 2026 года под одним названием жили два разных продукта, и путаница между ними была главной проблемой темы.

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

Расширенные конверсии для лидов решали другую задачу. Заявка приходит на сайте, а сделка закрывается через три недели в CRM. Бизнес загружал офлайн-конверсию с хешированными данными того же человека, и Google связывал закрытую сделку с исходным кликом. Так алгоритм узнавал, какие заявки превращаются в клиентов, а какие остаются мусором.

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

В 2026 году Google разобрал эту конструкцию в два этапа.

Апрель 2026. Google Ads начал одновременно принимать данные пользователей из тегов сайта, из Data Manager и из подключений по API. Выбирать один способ внедрения больше не нужно: работают все сразу.

Июнь 2026. Расширенные конверсии для сайта и для лидов объединены в одну функцию с переключателем «включено или выключено». Разных способов внедрения в интерфейсе аккаунта больше не видно.

Отдельно идет техническая дата: с 15 июня 2026 импорт офлайн-конверсий и загрузка расширенных конверсий для лидов переехали в Data Manager API, а в Google Ads API заблокированы. Токены разработчика, которые не отправляли запросов с января по июнь 2026, доступ по старой схеме не получают. Если у клиента настроена автоматическая выгрузка из CRM силами подрядчика, это первое, что стоит проверить.

Миграция существующих настроек прошла автоматически, но с условием: аккаунт переносится в новый статус, только если в нем ранее приняты условия Google по данным о клиентах. Пункт выглядит формальным, а на практике дает целый класс поломок. Расширенные конверсии часто включало предыдущее агентство или внутренний специалист, который прошел половину настройки: галочку поставил, условия не подтвердил. В интерфейсе функция выглядит включенной, данные при этом не обрабатываются, потому что справка отдельно оговаривает: все, что отправлено до принятия условий, не обрабатывается.

Что объединение не отменило: разницу между покупкой на сайте и сделкой, закрытой менеджером через месяц. Это по-прежнему два потока данных с разными источниками и разной задержкой. Изменилась настройка, а не бизнес-реальность.

Какие данные уходят в Google и в каком виде

Здесь клиенты нервничают сильнее всего, поэтому механику стоит держать в голове дословно.

Данные хешируются алгоритмом SHA-256 в шестнадцатеричном виде. Хеш односторонний: из него нельзя восстановить исходную почту. Google получает строку символов и сравнивает ее с такими же строками, посчитанными от данных авторизованных аккаунтов. Совпали - конверсия привязана к клику. Не совпали - ничего не произошло.

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

Поля, которые Google принимает как признаки для сопоставления:

• адрес почты - основной признак, справка называет его предпочтительным;
• телефон - работает как самостоятельный признак, но справка рекомендует отправлять его вместе с почтой;
• почтовый адрес - обязательны четыре поля: имя, фамилия, почтовый индекс и код страны из двух букв по стандарту ISO 3166-1 alpha-2. Улицу, город и регион можно добавить как дополнительные признаки.

Правило по адресу жесткое: все четыре обязательных поля должны уходить вместе, иначе адрес не используется. Если при этом отправляется почта, сопоставление пойдет по ней, а неполный адрес не учтется.

Обязательное условие площадки: страница работает по HTTPS. На HTTP хеширование не происходит вообще, и в диагностике вы увидите соответствующий код ошибки.

Чего в Google не уходит: платежных данных, содержимого корзины сверх стандартных параметров конверсии, паролей и любых полей, которые вы сами не указали в настройке. Отправляется ровно то, что вы привязали к полям почты, телефона и адреса.

Механика хеширования first-party данных подробнее разобрана в материале про Customer Match и загрузку клиентской базы - там те же принципы нормализации, только применяются к спискам, а не к отдельным конверсиям.

Со сбором согласия расширенные конверсии связаны напрямую. Тег определяет статус согласия в момент срабатывания: если условия использования данных не приняты или параметры согласия не выставлены в разрешающее значение, данные пользователя не собираются и не обрабатываются. Как устроен режим согласия и что он делает с сигналами, разобрано в статье про Consent Mode в Google Ads.

Настройка: один переключатель и три способа собрать данные

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

Уровень аккаунта и уровень конверсионного действия

Включение на уровне аккаунта: раздел «Цели», пункт «Настройки», панель использования данных о клиентах. Там отмечается пункт про включение расширенных конверсий и отдельным пунктом - использование данных для списков клиентов на основе конверсий. Дальше система показывает условия обработки данных, которые нужно принять.

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

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

Три способа собрать данные со страницы

Способ сбора выбирается в настройках тега Google, в разделе разрешений на сбор данных пользователя.

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

Селекторы CSS или переменные JavaScript. Вы вручную указываете, в каких элементах страницы лежат нужные значения. Контроля больше, устойчивость выше, но при редизайне страницы селекторы отваливаются молча.

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

Способы комбинируются. Автоопределение можно включить на весь аккаунт, а на паре критичных конверсий поставить фрагмент кода - данные из кода приоритетнее автоматически найденных. Если конверсионное действие создано по URL, доступны только селекторы, переменные JavaScript или автоопределение.

Настройка через Google Tag Manager

В GTM данные передаются параметром события user_data в теге Google, привязанном к нужному аккаунту Google Ads. Значением параметра выступает переменная типа «данные, предоставленные пользователем», внутри которой выбирается режим: автоматический, ручная настройка или код.

При ручной настройке под каждое поле создается переменная типа «элемент DOM» с методом выбора «селектор CSS». Селектор берется из инструментов разработчика Chrome: правый клик по значению на странице, «Просмотреть код», правый клик по подсвеченному фрагменту, копирование селектора. Поле атрибута оставляется пустым.

Практика, которую справка выносит отдельным примечанием: привязывайтесь к атрибуту id, а не к классам. Идентификаторы уникальны и переживают правки верстки, классы меняются при первом же обновлении темы.

Режим «код» подходит, когда значения уже лежат в глобальных переменных JavaScript или в data layer. Тогда создается пользовательская переменная JavaScript, которая возвращает объект с ключами email, phone_number и вложенным объектом address с полями first_name, last_name, street, city, region, postal_code, country. Для предварительно хешированных значений используются ключи sha256_email_address, sha256_phone_number, address.sha256_first_name и address.sha256_last_name. Поле, которого на сайте нет, удаляется из объекта целиком, а не оставляется пустым.

Когда данных нет на странице благодарности

Классическая ситуация интернет-магазина: почта вводится в форме заказа, а на странице подтверждения показан только номер заказа. Тег на странице благодарности брать нечего.

Для этого случая в GTM есть отдельный тег типа «событие с данными, предоставленными пользователем» для Google Ads. В нем указывается тот же идентификатор отслеживания конверсий, что и в конверсионном действии, выбирается переменная с данными, а триггером ставится отправка формы по всем формам. Справка отдельно предупреждает: триггер должен быть именно на отправку формы, иначе схема не работает.

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

Что выбирать

Разложение простое и держится на цене ошибки. Автоопределение - для сайтов с небольшим объемом и типовой версткой, где нет ресурса разработчика. Фрагмент кода или data layer - для аккаунтов, где на автостратегиях крутятся заметные бюджеты и цена искаженного сигнала измеряется сотнями долларов в неделю. Data Manager и API - когда сделка закрывается в CRM и надо возвращать в Google не заявку, а закрытую продажу.

Отдельный вопрос - контейнер против прямого тега. Я держу разметку в Google Tag Manager по умолчанию, даже когда конверсию можно повесить тегом напрямую. Причина в том, что Google Ads редко бывает единственной системой на проекте: из контейнера события расходятся во все кабинеты сразу, и настройку не приходится повторять под каждый. Плюс часть событий прямым тегом собрать не получается вовсе, а через контейнер собирается.

Отчет диагностики, кстати, сам подсказывает переход: если настроено автоопределение, а покрытие низкое, Google выводит рекомендацию добавить код на страницу.

Проверка: от параметра em до отчета диагностики

Проверять надо дважды: сразу после внедрения и через двое суток, когда накопятся данные.

Немедленная проверка на странице

Откройте инструменты разработчика Chrome, вкладку сети, и совершите тестовую конверсию. В поиске по запросам наберите google и найдите обращение к googleadservices.com/pagead/conversion/ или к google.com/pagead/1p-conversion/ в некоторых браузерах. В параметрах запроса нужен параметр em.

Что вы там увидите и как это читать:

• значение вида tv.1~em. и дальше длинная строка символов - хеш ушел, настройка работает;
• параметра em нет вовсе - тег настроен неверно, данные не отправляются;
• tv.1~em. без строки после точки - параметр уходит пустым, данных на странице в момент конверсии не оказалось;
• tv.1~em.e0 - значение не прошло проверку формата: почта без символа @, буквы в номере телефона;
• tv.1~em.e1 - браузер не поддерживается, случай редкий, проверьте в свежем Chrome;
• tv.1~em.e2 - сбой хеширования, обычно из-за непредусмотренных символов во входной строке;
• tv.1~em.e3 - страница отдается по HTTP, а не по HTTPS.

Если сайт работает через GTM, тот же результат смотрится в режиме предварительного просмотра: открываете конверсионный тег Google Ads, вкладку переменных, и видите содержимое объекта с данными пользователя. Есть еще расширение Chrome под названием EC Assist от Google - оно проводит по шагам проверки и подсвечивает, что не заполнено.

Отчет диагностики через 48 часов

Путь: раздел «Цели», сводка по конверсиям, конверсионное действие, вкладка диагностики. Есть и вход на уровне аккаунта - вкладка диагностики на верху страницы конверсий, где виден статус по всем подходящим действиям сразу.

Статусы качества данных, которые там бывают:

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

Метрики в блоке влияния читаются так. Покрытие - доля конверсионных событий, в которых пришло достаточно данных пользователя. Считается как число событий с параметром, деленное на общее число конверсионных событий, показывается за семь или тридцать дней. Доля сопоставления показывает, насколько ваши данные совпадают с данными авторизованных аккаунтов; в отчете она обозначается как высокая при значении выше 15% и как низкая в интервале от нуля до 15%. Отдельные пометки: нулевое совпадение и недостаточный объем, когда валидных отправок меньше двадцати. Прирост конверсий показывает, сколько конверсий добавилось за счет данных пользователя, и доступен в первые тридцать дней после запуска.

Предупреждения строятся на данных за прошедшие сутки, а при нехватке объема - за семь дней.

Что стоит за частыми предупреждениями

• Условия по данным о клиентах не приняты. Самое частое и самое обидное: данные летят, но не обрабатываются. Лечится в настройках конверсий за минуту.
• Отсутствуют поля данных пользователя. Параметр не передавался при части срабатываний тега. Проверяйте все страницы, где стоит конверсионный тег, а не одну.
• Данные пользователя пустые. Поля отправляются, значения пустые. Причины две: данных нет на этой странице, или селектор перестал попадать в элемент. Селекторы часто ведут себя по-разному на мобильных и десктопе - проверяйте на обоих.
• Неверный формат. Почта без @, телефон без кода страны, имя с цифрами, индекс не той длины, код страны написан словом вместо двух букв.
• Не хватает обязательных полей адреса. Пришло имя и индекс, но нет фамилии или кода страны. Адрес отбрасывается целиком.
• Мало сопоставленных конверсий. Ваши данные совпадают реже ожидаемого. Либо у аудитории мало аккаунтов Google, либо люди указывают на сайте не те контакты, что в аккаунте. Лечится добавлением дополнительных признаков: к почте добавить телефон, к телефону - адрес.

Что расширенные конверсии меняют для стратегий ставок

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

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

Дальше это отражается на цифрах, которыми вы управляете. Целевая цена за конверсию и целевая рентабельность считаются от того, что видно в аккаунте. Занижение числа конверсий завышает расчетный CPA, и стратегия сбавляет обороты там, где с продажами все в порядке. Как выбирать стратегию под задачу и когда переключаться, разобрано в статье про стратегии ставок Google Ads.

Второй эффект - списки клиентов на основе конверсий. Тот же переключатель, вторым пунктом, разрешает Google собирать из данных ваших конверсий аудиторные списки. Дальше они работают на поиск похожих и на исключения.

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

Точность сопоставления и качество самой конверсии

Эти две задачи решаются в разном порядке, и порядок стоит держать в голове.

Пример из работы с интернет-магазином бытовой техники в Казахстане. Конверсией в кабинете считалась не заявка с сайта, а два события, которые приходили извне. Первое - статус лида в CRM: заявка засчитывалась, когда человек доходил до назначенной встречи в офисе или приезжал в магазин ногами. Второе - качественный звонок из колл-трекинга, где качественным считался разговор дольше 45 секунд. Оба события уходили в Google Analytics и оттуда в Google Ads.

Цена конверсии после такой перестановки выросла с $3 до $5. Подорожание тут читается как хороший знак: из счета ушли недозвоны и случайные заявки, а до отдела продаж стали доходить люди, которые уже согласились приехать. Брака меньше, времени на разбор мусора меньше, бюджет тот же. Разговор с клиентом об этом надо вести до перестановки целей, а не когда он увидит выросший CPA в отчете.

К расширенным конверсиям это отношения не имеет: там менялось само конверсионное действие, а не механизм сопоставления. Отсюда и порядок работы. Сначала решить, что считать конверсией. Потом настроить сбор данных пользователя. И только потом смотреть на покрытие и долю сопоставления. Обратный порядок дает точно измеренный поток недозвонов.

Что проверить в аккаунте, который вы приняли в работу

Порядок действий, который занимает пятнадцать минут и регулярно находит поломку.

• Открыть настройки конверсий и убедиться, что условия по данным о клиентах приняты в этом рекламном аккаунте, а не в управляющем.
• Посмотреть статус в диагностике по каждому конверсионному действию, а не по одному главному.
• Проверить покрытие. Значение около нуля при включенном переключателе означает, что сбор данных не настроен, а галочка стоит.
• Проверить долю сопоставления. Низкая при нормальном покрытии - вопрос к признакам: скорее всего, отправляется только почта.
• Сделать тестовую конверсию и посмотреть параметр em глазами. Отчет обновляется с задержкой, запрос в браузере - нет.
• Проверить, откуда приходят офлайн-конверсии, если они есть. После июня 2026 загрузки идут через Data Manager API; старая интеграция через Google Ads API отдает ошибку, а в отчете это выглядит как пропавшие конверсии.
• Сверить, что конверсионные страницы отдаются по HTTPS. У проектов с историей встречаются старые разделы на HTTP, и конверсии оттуда не хешируются.

Отдельно про разговор с клиентом, который не хочет отдавать контакты своих покупателей. Аргумент, который работает: в Google не уходит ни один читаемый контакт. Уходит необратимая строка символов, посчитанная от почты, и Google сравнивает ее с такой же строкой на своей стороне. Восстановить из нее адрес нельзя ни вам, ни Google. Юридическая сторона при этом остается на бизнесе: обработка данных подчиняется условиям Google по данным о клиентах, и принимая их, рекламодатель подтверждает, что имеет право передавать эти данные.

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

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

Что такое расширенные конверсии в Google Ads?

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

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

Первые дополняют конверсию, которая произошла на сайте: покупку, заявку, запись. Вторые возвращают в Google офлайн-событие из CRM, например закрытую сделку через три недели после заявки. С июня 2026 обе версии объединены в один переключатель, но разница в источнике данных сохранилась: сайт против выгрузки из CRM.

Какие данные уходят в Google?

Адрес почты, телефон в формате E.164 и почтовый адрес, где обязательны имя, фамилия, индекс и двухбуквенный код страны. Все значения хешируются алгоритмом SHA-256. Платежные данные, содержимое корзины и любые поля, которые вы не указали в настройке, не передаются.

Можно ли восстановить почту из хеша?

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

Через Google tag или через GTM настраивать?

Способ передачи с 2026 года не ограничен: Google Ads принимает данные из тегов сайта, из Data Manager и по API одновременно. Выбор идет по тому, что уже стоит на сайте. Если конверсии считаются через GTM - настраивайте там же через параметр user_data. Если стоит тег Google без контейнера - через настройки тега. На своих проектах я по умолчанию иду через контейнер: разметка лежит в одном месте и оттуда расходится во все рекламные системы, а не в один Google Ads.

Почему расширенные конверсии показывают статус, что настройка требует внимания?

Чаще всего по трем причинам: не приняты условия по данным о клиентах, параметр уходит пустым, потому что на странице нет данных или отвалился селектор, либо данные приходят в неверном формате. Точная причина видна в отчете диагностики в разделе предупреждений.

Сколько ждать после настройки, прежде чем смотреть отчет?

Параметр em в запросе браузера видно сразу, на первой же тестовой конверсии. Отчет диагностики в Google Ads наполняется примерно через 48 часов. Прирост конверсий отображается в первые тридцать дней после того, как расширенные конверсии заработали.

Нужны ли расширенные конверсии при небольшом объеме?

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

Что делать с загрузкой офлайн-конверсий после июня 2026?

Переводить на Data Manager API. С 15 июня 2026 импорт офлайн-конверсий и загрузка расширенных конверсий для лидов в Google Ads API заблокированы, а токены разработчика без запросов с января по июнь 2026 доступ по старой схеме не получили. Если выгрузка из CRM настроена подрядчиком, стоит запросить подтверждение, что она переехала.