Кросс-доменное отслеживание 2026: где теряются конверсии

Вы платите за клик на site.com, а форма заявки живёт на app.site.io, оплата — на checkout.provider.com, а запись на демо — в виджете calendly.com. В отчёте Google Ads конверсий в полтора-два раза меньше, чем в CRM, а в GA4 половина платного трафика внезапно числится как Direct / (none). Это не «Google недосчитывает» и не «алгоритм барахлит». Так выглядит сломанное кросс-доменное отслеживание: переход между доменами обрывает сессию и теряет идентификатор клика.

Разберём, как именно рвётся цепочка, как за 20 минут найти обрыв руками, как настроить кросс-доменное отслеживание в Google Ads и GA4 так, чтобы оно пережило редиректы, iframe и «умные» платёжные шлюзы, и какие ошибки в 2026 году встречаются чаще всего.

Что такое кросс-доменное отслеживание и почему оно ломается

Браузер хранит cookie строго в рамках одного домена (точнее — одного eTLD+1). Когда пользователь переходит с site.com на app.site.io, второй домен не видит cookie первого. А в этих cookie лежит всё самое ценное:

_gcl_aw — сохранённый GCLID, идентификатор клика по объявлению Google Ads;
_ga — Client ID, склеивающий сессии в GA4;
_gcl_dc, _gcl_gb — идентификаторы для Display & Video и для кликов с гибридных поверхностей.

Без этих значений конверсия на втором домене выглядит как визит нового анонимного пользователя, пришедшего «ниоткуда». Google Ads не может связать её с кликом, GA4 открывает новую сессию и переписывает источник.

Решение на уровне механики простое: при переходе между доменами идентификаторы нужно передать явно — в URL. Google-тег делает это через параметр _gl (linker parameter), принимающий домен читает его и восстанавливает свои cookie. Весь смысл настройки сводится к тому, чтобы каждый переход между вашими доменами нёс этот параметр, а принимающая сторона умела его прочитать.

Кросс-доменное отслеживание — не «галочка в интерфейсе». Это цепочка из пяти звеньев: тег на домене A, ссылка с параметром, тег на домене B, конверсионное действие, отправка данных. Рвётся любое звено — рвётся вся цепочка.

Пять сценариев, в которых цепочка рвётся чаще всего

1. Форма или корзина на поддомене другого eTLD+1

Самый распространённый случай: маркетинговый сайт на brand.com, приложение на brand.app или getbrand.io. Поддомены одного домена (shop.brand.com) cookie делят автоматически, если они выставлены на корневой домен, — а вот разные домены второго уровня не делят ничего.

2. Платёжный шлюз с возвратом на сайт

Пользователь уходит на secure.payments.xx, платит, возвращается на site.com/thank-you. Возврат почти всегда происходит по «чистому» URL, прописанному в настройках шлюза, — без _gl, без UTM. Если cookie на site.com ещё живы, конверсия засчитается. Если пользователь оплачивал 40 минут и сессия GA4 успела истечь — источник в GA4 переписывается на прямой заход, хотя конверсия Google Ads при этом уцелеет (у неё своё окно, см. окна конверсии и лаг конверсии в Google Ads).

3. Виджет бронирования или календаря в iframe

Calendly, Cal.com, встроенные формы CRM. Контент внутри iframe — это другой домен со своими cookie. Передать _gl туда можно только вручную, добавив параметр в src iframe.

4. Редирект-трекер или сокращатель ссылок между доменами

Если между доменами стоит промежуточный редирект (внутренний шортлинк, трекер, лендинг-билдер), он обязан пробрасывать параметры запроса дальше. Многие сервисы по умолчанию «съедают» всё, что идёт после знака вопроса. Здесь же теряется и GCLID — подробно про его поведение мы разбирали в материале о GCLID, GBRAID, WBRAID и шаблонах отслеживания.

5. Мобильное приложение и web-to-app переход

Переход в приложение через deep link рвёт всё: cookie браузера в приложение не переносятся. Здесь работает не linker, а отдельная схема — передача параметров в deferred deep link и серверный импорт конверсий.

Как за 20 минут найти обрыв руками

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

Пройдите путь пользователя сами. Откройте объявление (или вручную добавьте ?gclid=TEST123 к посадочной), пройдите весь путь до благодарственной страницы и на каждом шаге смотрите в адресную строку.
Проверьте наличие _gl. На переходе между доменами в URL должен появиться длинный параметр _gl=1*xxxxx*.... Нет его — linker не сработал.
Проверьте cookie на принимающем домене. DevTools → Application → Cookies. На втором домене должны появиться _ga и _gcl_aw с теми же значениями, что были на первом. Расходятся — параметр пришёл, но тег его не прочитал.
Проверьте порядок загрузки. Google-тег должен загрузиться до того, как пользователь кликнет по ссылке. Тег, вставленный в конец body на тяжёлой странице, может не успеть навесить обработчики — и первые клики уйдут без _gl. Это одна из причин, по которой скорость лендинга и Core Web Vitals влияют не только на конверсию, но и на полноту данных.
Сверьте три числа. Конверсии в Google Ads, конверсии в GA4 и сделки в CRM за одинаковый период с одинаковой моделью атрибуции. Расхождение Google Ads и CRM в 30–50% при «нормальном» GA4 — почти всегда кросс-домен.

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

Быстрая таблица симптомов

Симптом	Вероятная причина	Где смотреть
Много Direct / (none) в GA4 при живом платном трафике	Рвётся Client ID между доменами	Cookie `_ga` на втором домене
Конверсий в Google Ads вдвое меньше, чем сделок в CRM	Теряется GCLID	Cookie `_gcl_aw`, параметры URL
Сессий больше, чем пользователей, в 2–3 раза	Каждый переход стартует новую сессию	Отчёт по session_start
Конверсии есть, но все с задержкой в один клик	Дубли событий на обоих доменах	См. дедупликацию конверсий
Данные пропали у части пользователей, но не у всех	Согласие на cookie не получено	Consent Mode v2

Настройка: правильный порядок действий

Шаг 1. Составьте карту доменов

Выпишите все домены, через которые проходит пользователь от клика до оплаты, включая промежуточные редиректы и iframe. Отметьте, на каких из них стоит Google-тег, а на каких нет. В 8 случаях из 10 проблема обнаруживается уже на этом шаге: на платёжной или «спасибо»-странице тега просто нет.

Шаг 2. Пропишите список доменов в Google-теге

В интерфейсе Google-тега (Google Ads → Инструменты → Google-тег, либо GA4 → Потоки данных → Настроить параметры тега) есть раздел Настроить междоменное отслеживание. Туда добавляются все домены списком. Важные нюансы:

Домены указываются без протокола и без слеша: site.com, app.site.io.
Список должен быть одинаковым на всех доменах. Настроили только на отправляющем — принимающий не будет знать, что параметру _gl можно доверять.
Сопоставление идёт по вхождению подстроки — site.com покроет и shop.site.com, и, к сожалению, notmysite.com. Не пишите слишком короткие фрагменты.

Шаг 3. Если используете GTM — настройте линкер в теге конфигурации

В Google Tag Manager то же самое делается в настройках Google-тега: поле Настройки конфигурации → параметр linker с массивом доменов, либо через встроенный интерфейс междоменного отслеживания. Проверьте, что тег срабатывает на триггере Initialization или All Pages — а не на кастомном событии, которое может не успеть.

Шаг 4. Прокиньте параметры в iframe вручную

Автоматический декорирование ссылок на iframe не распространяется. Для виджетов используйте API виджета или добавляйте параметр в src программно, взяв текущее значение _gl:

// упрощённая схема
gtag('get', 'G-XXXXXXX', 'gclid', function(v) {
  iframe.src = baseUrl + '?gclid=' + encodeURIComponent(v || '');
});

Для большинства коммерческих виджетов есть штатный способ передать UTM и GCLID в скрытые поля формы — это надёжнее, чем возиться с cookie.

Шаг 5. Сохраните GCLID в свою базу

Самое устойчивое решение — не полагаться на браузер вовсе. При сабмите формы кладите GCLID в скрытое поле, сохраняйте его вместе с лидом в CRM и потом возвращайте сделки в Google Ads через Data Manager и данные первой стороны. Тогда даже полностью сломанный фронтенд не мешает считать деньги: цепочка «клик → лид → сделка» живёт у вас на сервере.

Шаг 6. Включите расширенные конверсии

Расширенные конверсии дособирают часть того, что потеряно на кросс-домене: хешированный email или телефон, переданный вместе с конверсией, позволяет Google сматчить её с кликом даже без GCLID. Это не замена настройке, а страховка поверх неё — но она регулярно возвращает 5–15% конверсий (ориентир, не гарантия: величина зависит от доли авторизованных пользователей и качества передаваемых полей).

Шаг 7. Перенесите измерение на сервер, где это оправдано

Серверное отслеживание не решает кросс-домен автоматически — идентификатор всё равно нужно как-то передать между доменами, — но оно радикально повышает выживаемость данных после перехода. Подробная схема в материале про server-side трекинг на sGTM.

Три типовые конфигурации и что в них настраивать

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

Конфигурация А: SaaS — маркетинговый сайт и приложение на разных доменах

Путь: brand.com (объявление → лендинг) → app.brand.io (регистрация) → внутри приложения апгрейд до платного тарифа через месяц.

Что делать: linker между двумя доменами обязателен, но он решает только первый шаг. Настоящая конверсия — оплата — происходит через недели, когда никакой cookie уже нет. Рабочая схема: при регистрации записывайте GCLID в профиль пользователя в базе, а факт оплаты отправляйте серверным импортом с этим же GCLID. Клиентский тег в этой связке отвечает только за регистрацию как за микроконверсию, а оптимизироваться стоит на оплату.

Частая ошибка: оптимизировать кампании на регистрацию, потому что «оплату не видно в Ads». Итог — алгоритм гонит дешёвые бесплатные регистрации, выручка не растёт.

Конфигурация B: e-commerce с внешним чекаутом

Путь: shop.com (каталог, корзина) → pay.provider.com (оплата) → shop.com/success (возврат).

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

Конфигурация C: лидогенерация с виджетом записи

Путь: agency.com (лендинг) → iframe виджета календаря → подтверждение записи → сделка в CRM через две недели.

Что делать: linker до iframe не дотягивается. Забирайте GCLID на лендинге JavaScript-ом и передавайте в скрытое поле виджета (у большинства сервисов есть параметр для UTM и произвольных полей). Дальше — та же логика: GCLID приезжает в CRM вместе с записью, закрытая сделка возвращается импортом. Конверсию «запись на встречу» считайте как вторичную, оптимизируйтесь на состоявшуюся сделку, когда объёма хватает.

Что происходит с UTM-метками и источником в GA4

Отдельная путаница, из-за которой люди «чинят» не то. Google Ads и GA4 определяют источник по-разному, и это нормально.

Google Ads опирается на GCLID. Пока идентификатор долетел до конверсии, конверсия будет атрибутирована клику — даже если GA4 показывает Direct.
GA4 опирается на кампанийные параметры и Client ID. Потеряли _ga при переходе — стартует новая сессия, и она получает источник заново. Если реферер при этом не передан (а при редиректах и из приложений он часто пустой), сессия падает в Direct.

Практический вывод: не пытайтесь лечить Direct в GA4 добавлением UTM на внутренние ссылки. Это классическая ошибка: UTM на внутреннем переходе принудительно обрывает старую сессию и переписывает источник на тот, что вы сами прописали. Атрибуция становится ещё хуже, а не лучше. Правильное решение — linker, а не метки. Более широкий разбор моделей — в материале про атрибуцию GA4 для медиабайера.

Типичные ошибки и их последствия

Ошибка	Что происходит	Как проявляется в отчётах
Домены прописаны только на одном сайте	Параметр передаётся, но не принимается	Данные теряются в одну сторону
Указан протокол: `https://site.com`	Сопоставление не срабатывает	Настройка «есть», эффекта нет
Разные Measurement ID на доменах	Сессии не склеиваются в один поток	Пользователей вдвое больше реального
Редирект обрезает query-параметры	Теряются и GCLID, и `_gl`	Провал конверсий на одном канале
Тег грузится после клика	Ссылки не декорируются	Потери 10–20%, «плавающие»
Конверсия настроена на обоих доменах	Двойной счёт	Резкий рост конверсий без роста выручки
CMP блокирует тег до согласия	Нет cookie — нечего передавать	Данные только от части аудитории

Отдельно предупредим про шестую строку. Задвоение конверсий выглядит как «наконец-то починили» — цифры выросли. Через две недели Smart Bidding переобучается на завышенных данных, начинает перекупать трафик, и реальный CPA растёт. Сверяйте конверсии с выручкой всегда, а не только когда цифры падают.

Как проверить, что всё действительно работает

После настройки не полагайтесь на «в интерфейсе сохранилось». Прогоните три проверки:

Ручной проход пути. От объявления до «спасибо», с DevTools. _gl в URL при каждом переходе, _ga и _gcl_aw одинаковые на всех доменах.
Режим отладки. GA4 DebugView должен показать одну непрерывную сессию с корректным источником, а не две сессии с разными source/medium.
Сверка через 14 дней. Сравните конверсии Google Ads, GA4 и CRM. Допустимое расхождение — до 10–15% из-за разных моделей атрибуции и окон. Больше — ищите дальше.

И заложите время на переобучение: после починки трекинга алгоритм ставок видит другой объём конверсий и фактически заходит в новый период обучения Smart Bidding. Неделю-две показатели будут нестабильны — это нормально, не откатывайте изменения на третий день.

Что меняется в 2026 году

Три вещи, которые стоит держать в голове.

Первое. Сторонние cookie в Chrome никуда не делись — Google отказался от их принудительной отмены, а Privacy Sandbox свернули. Но собственные (first-party) cookie всё равно живут ограниченное время в Safari и Firefox, поэтому надёжность схемы «положил в cookie и забыл» падает. Подробный разбор — в материале о сторонних cookie и закрытии Privacy Sandbox.

Второе. Доля конверсий, которые Google моделирует, а не наблюдает, растёт. Кросс-домен для алгоритма выглядит как «нет данных», и он честно пытается их домоделировать. Чем больше реальных сигналов вы отдаёте, тем меньше модели приходится додумывать.

Третье. Любая перестройка сайта ломает настройку заново. Если у вас впереди редизайн или смена домена — сверьтесь с чек-листом миграции сайта без потери платного трафика до релиза, а не после.

Мини-чек-лист

Карта всех доменов на пути пользователя составлена и актуальна.
Google-тег стоит на каждом домене, Measurement ID один и тот же.
Список доменов для междоменного отслеживания одинаков на всех сайтах, без протоколов.
Параметр _gl виден в URL при каждом переходе.
Промежуточные редиректы пробрасывают query-параметры.
Виджеты и iframe получают GCLID явно.
GCLID сохраняется в CRM, сделки возвращаются импортом.
Расширенные конверсии включены.
Конверсия настроена ровно один раз на одну покупку.
Consent Mode настроен, теги не блокируются целиком.
Сверка Ads / GA4 / CRM поставлена на регулярную основу.

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

FAQ

Нужно ли кросс-доменное отслеживание, если все страницы на одном домене?

Нет. Поддомены одного домена (www, shop, blog) делят cookie автоматически, если тег выставляет их на корневой домен. Настройка нужна только при переходе между разными доменами второго уровня.

Что такое параметр `_gl` и не вредит ли он SEO?

Это временный служебный параметр, которым Google-тег переносит идентификаторы между доменами. Он живёт несколько минут и не индексируется, если на страницах корректно выставлен canonical. Для спокойствия добавьте _gl в список игнорируемых параметров в GA4 и в настройках canonical.

Почему в GA4 много Direct, хотя трафик платный?

Чаще всего это как раз обрыв на переходе между доменами: новая сессия стартует без источника и записывается как прямой заход. Второй по частоте вариант — редирект, обрезающий UTM и GCLID.

Потеряю ли я конверсии Google Ads, если GA4 настроен неправильно?

Не обязательно. У Google Ads собственный тег и собственные cookie: конверсия может засчитаться там, даже если GA4 показывает Direct. Но если теряется сам GCLID — потеряются обе системы.

Помогут ли расширенные конверсии, если кросс-домен вообще не настроен?

Частично. Они позволяют сматчить конверсию по хешированному email или телефону, но работают не на всех пользователях и не заменяют корректную передачу идентификаторов.

Как передать данные в платёжный шлюз, который мы не контролируем?

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

Сколько конверсий обычно возвращает правильная настройка?

Зависит от того, сколько переходов между доменами в вашем пути. Если критичный переход был один и он не был настроен, возврат в 20–40% встречается часто — но это ориентир, а не обещание: считайте на своих данных.

Нужно ли перенастраивать всё после перехода на server-side?

Список доменов и передачу _gl — нет, они остаются. Меняется только эндпоинт отправки событий и место, где вы обогащаете данные.

Как отличить проблему кросс-домена от проблемы согласия на cookie?

При проблеме с согласием потери равномерны по всем путям и коррелируют с гео (сильнее в ЕС). При кросс-домене потери привязаны к конкретному переходу: один сценарий покупки считается, другой — нет.

Влияет ли это на ретаргетинг?

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

Что проверять в первую очередь, если времени мало?

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

Кто должен это делать — маркетолог или разработчик?

Диагностику и список доменов закрывает маркетолог. Проброс параметров через редиректы, iframe и сохранение GCLID в базу — задача разработчика. Разделение ответственности стоит зафиксировать письменно, иначе задача зависает между ними.