Междоменное отслеживание GA4: как сохранить путь пользователя между своими сайтами
Покупатель изучает предложение на основном сайте, нажимает «Заказать» и попадает в магазин на другом домене. Для бизнеса это один путь к покупке. В аналитике он может выглядеть как два отдельных посещения: первое заканчивается на кнопке, второе начинается уже возле оплаты. В такой ситуации междоменное отслеживание GA4 помогает связать действия между площадками, которые участвуют в общей воронке.
Настройку удобно принимать по воспроизводимому маршруту: откуда пришёл тестовый посетитель, какую ссылку нажал, что получил второй сайт и какие идентификаторы отправила аналитика. Один скриншот списка доменов этих вопросов не закрывает. Ниже — последовательность настройки и проверки для своих сайтов, включая формы, переадресации и возвращение от внешнего платёжного сервиса.
Когда нескольким доменам нужна общая аналитика
Сначала опишите бизнес-сценарий без названий настроек. Например: реклама ведёт на презентационный сайт, подбор услуги происходит там же, а бронирование — в отдельной системе на другом домене. Команда хочет оценивать весь маршрут и понимать, на каком этапе человек уходит. Такое описание помогает выбрать границы измерения и назначить ответственных за обе стороны перехода.
Составьте перечень площадок, где вы можете согласованно установить и настроить тег. Принадлежность доменов одной компании сама по себе ещё не означает, что любые данные следует объединять: у отдельных продуктов могут быть разные цели измерения и правила доступа. Сначала согласуйте общую задачу, затем техническую схему. Сторонний сайт, на котором вы не управляете аналитикой, рассматривайте отдельно.
Различайте корневые домены и поддомены. Для связки основного сайта с его поддоменом сначала проверьте область действия cookies и существующую конфигурацию. Не переносите на неё автоматически решение для двух независимых доменов. В документации Google о cookies GA4 описана их роль в различении пользователей и сохранении состояния сеанса. При разборе конкретного проекта важны фактические настройки браузера, а не только похожие названия адресов.
Зафиксируйте и границы результата. Приёмочный сценарий ниже относится к переходу в одном браузере. Покупка позже с другого устройства, открытие ссылки другим человеком и новая сессия после долгого перерыва требуют отдельного анализа. Не включайте их в обещание «всегда один пользователь» после добавления списка доменов.
Что собрать перед настройкой cross-domain GA4
Подготовьте небольшую карту внедрения. Она особенно полезна, когда главный сайт поддерживает одна команда, магазин — другая, а контейнер тегов принадлежит подрядчику. В карте должны быть конкретные адреса и ответственные: формулировка «аналитика стоит везде» слишком расплывчата для проверки.
| Что записать | Зачем это потребуется |
|---|---|
| Домен, назначение сайта и основные шаблоны страниц | Выбрать реальные точки входа и завершения перехода |
| Веб-поток GA4 и его идентификатор G- | Сопоставить назначение данных на обеих площадках |
| Способ установки тега | Найти владельца настройки и возможные дубли подключения |
| Ссылки, формы, кнопки и промежуточные адреса | Составить маршруты для проверки |
| Состояние согласия и используемый браузер | Повторить тест в тех же условиях |
| Ответственный за сайт и дата изменения | Передать найденную ошибку нужному исполнителю |
Проверьте несколько типов страниц, а не только главные. Кнопка заказа может вести на шаблон, который подключает другой контейнер или вообще не содержит нужного тега. Для проекта с каталогом возьмите карточку товара, корзину и начало оформления; для записи на услугу — посадочную страницу, форму и подтверждение её отправки. Добавьте мобильное меню, если его переход реализован отдельно.
В этой же карте отметьте тестовую среду. Не включайте её домен в производственный маршрут автоматически: сначала определите, где будут проверяться изменения и куда попадут тестовые события. Чем яснее граница между испытанием и рабочей воронкой, тем проще оценить результат без догадок по отчётам.
Как настроить связь доменов в GA4
Для стандартной схемы Google требует один и тот же идентификатор G- одного веб-потока на участвующих страницах. Нахождение разных потоков внутри одного ресурса не заменяет это условие. Проверьте назначение тега до изменения списка доменов, затем откройте настройки нужного потока с правами редактора или выше.
- В администрировании GA4 перейдите к потокам данных и выберите веб-поток.
- Откройте настройки Google tag.
- Найдите раздел настройки доменов.
- Добавьте условия для участвующих доменов, выбрав подходящий тип соответствия.
- Сохраните изменения и перейдите к проверке реальных переходов.
Актуальная последовательность и требования приведены в инструкции Google по междоменному измерению. Условия списка объединяются логикой «или». Поэтому проверяйте каждое из них отдельно и не добавляйте широкие совпадения без необходимости.
После сохранения оставьте в рабочей заметке итоговый список и причины включения каждого домена. Рекомендованный интерфейсом адрес также стоит сопоставить с картой проекта: автоматическая подсказка не знает ваших бизнес-границ. Если связку уже настраивали в коде или контейнере, сначала выясните, где хранится действующая конфигурация. Несколько несогласованных способов настройки затрудняют поиск причины расхождения.
Как работает параметр _gl и почему его проверяют кликом
Google tag добавляет к переходу служебный параметр _gl. Принимающая сторона считывает действительное значение для междоменного измерения. Согласно техническому руководству по linker, параметр формируется при клике и действует две минуты. Поэтому отсутствие _gl в исходном HTML ссылки ещё не означает ошибку, а вчерашний адрес из переписки не подходит для приёмочного теста.
Откройте первую страницу в выбранном тестовом браузере и выполните обычное действие посетителя. Затем посмотрите адрес перехода и сетевые запросы. Зафиксируйте, появился ли параметр на пути к нужному домену. Повторяйте действие заново для каждого испытания: это позволяет проверять текущую работу механизма, а не сохранённую копию старого URL.
Не добавляйте вручную произвольное значение _gl в постоянные ссылки. В тестовой заметке достаточно отметить наличие параметра; рабочий идентификатор не нужен в публичном отчёте. Также не пытайтесь заменить связь доменов UTM-метками: обозначение рекламной кампании не является передачей идентичности посетителя. Для внутреннего маршрута записывайте точку перехода в плане событий, а механизм связи проверяйте отдельно.
Почему отдельно проверяют ссылки, формы и кнопки
С точки зрения посетителя меню, большая кнопка и отправка формы могут одинаково означать «перейти к заказу». В реализации сайта это разные действия. Сделайте отдельную строку проверки для каждого способа перехода, особенно если кнопка сначала выполняет JavaScript, запрашивает адрес у сервера или открывает промежуточную страницу.
Для ручной конфигурации linker параметр decorate_forms по умолчанию выключен; его включение описано в техническом руководстве выше. Там же Google уточняет: у тегов Google Analytics в Tag Manager нет отдельного элемента управления этим параметром, и для такого случая следует обращаться к указаниям для gtag.js. Не переносите инструкции для рекламного Conversion Linker на GA4 без проверки применимости.
Задание разработчику лучше сформулировать через результат: «после отправки этой формы принимающая страница получает действительные данные связи, а идентификаторы в согласованном тесте сохраняются». Так исполнитель сможет учесть конкретную форму, обработчик и навигацию. Добавление ещё одного тега вслепую создаёт дополнительную переменную и не объясняет, на каком этапе возникала потеря.
Проверяйте действие в том виде, в каком оно доступно пользователю. Если в настольном меню обычная ссылка, а в мобильном — программный переход, успех первого сценария ничего не говорит о втором. Такой перечень становится полезным заданием для повторной проверки после обновления интерфейса.
Как найти потерю параметра на редиректе
Рассмотрите учебную ситуацию: посетитель нажимает кнопку, адрес назначения получает _gl, но промежуточный обработчик переводит браузер на чистый URL. Здесь нужно исследовать цепочку до загрузки принимающей страницы. Сохраните сетевой журнал, найдите исходный запрос, ответы с переадресацией и финальный адрес. Для каждого шага отметьте, какие параметры сохранились.
Не делайте вывод по одному снимку адресной строки после загрузки. Важен момент, когда принимающий тег получил возможность прочитать значение. Сформулируйте исправление вокруг конкретного обработчика: сохранить необходимый параметр на этом переходе до его обработки аналитикой. Затем повторите тот же маршрут и проверьте идентификаторы. Массовое изменение всех редиректов без установленной причины только расширяет область проверки.
Отдельно убедитесь, что приложение открывает правильную страницу при наличии служебного параметра: не сбрасывает выбранную услугу, не теряет корзину и не показывает ошибку. Эти проверки относятся к пользовательскому маршруту. Исправная аналитика бесполезна, если сам посетитель не может продолжить оформление заказа.
Как подтвердить сохранение пользователя и сеанса
Наличие _gl показывает только часть процесса. Для контролируемого теста сопоставьте идентификаторы до и после перехода. Проводите его в одном браузере, без очистки данных посередине, при разрешённом аналитическом хранении и без длительной паузы. Запишите исходную страницу, конечную страницу, время и состояние согласия. Это позволит другому специалисту повторить наблюдение.
Справочник API Google tag описывает команду get для чтения client_id и session_id. В среде, где доступна уже загруженная функция gtag, разработчик может выполнить такие диагностические вызовы, заменив учебный G-идентификатор на идентификатор своего потока:
gtag('get', 'G-XXXXXXXXXX', 'client_id', function(value) {
console.log('client_id:', value);
});
gtag('get', 'G-XXXXXXXXXX', 'session_id', function(value) {
console.log('session_id:', value);
});Это чтение значений для проверки, а не код установки аналитики. В реализации через контейнер не предполагайте, что глобальная функция обязательно доступна: используйте подходящий способ отладки и наблюдение за событиями. Отсутствующее значение сначала требует проверить загрузку тега, его назначение и условия теста; оно не доказывает автоматически неисправность междоменной связи.
Сравнивайте пару идентификаторов вместе. В описании сеансов GA4 Google поясняет, что идентификатор сеанса формируется из времени его начала, а для уникального определения сеанса вне GA4 его следует сочетать с идентификатором пользователя. Если между измерениями был большой перерыв, сначала проверьте тайм-аут сеанса. Не пытайтесь исправить нормальное начало нового сеанса искусственным присвоением старого номера.
Как учитывать согласие на аналитическое хранение
Состояние согласия является частью условий проверки. Согласно описанию Consent Mode, при analytics_storage со значением denied тег не читает и не записывает аналитические cookies. Поэтому нельзя требовать от такого сценария того же результата, что от теста с разрешённым хранением, или принудительно менять выбор посетителя ради совпадения идентификаторов.
Для рабочего протокола выделите два сценария. В первом тестировщик делает предусмотренный сайтом выбор, разрешающий аналитическое хранение, и команда проверяет связь. Во втором он отказывается, а команда проверяет соблюдение этого выбора. Запишите фактическое состояние на обеих площадках: визуально похожие баннеры ещё не доказывают одинаковую реализацию.
Если первая площадка уже знает выбор, а вторая показывает новый запрос, это отдельный вопрос к схеме управления согласием. Не скрывайте его настройкой linker. Также не публикуйте в открытом задании полные журналы с реальными пользовательскими данными. Для учебного отчёта замените значения условными обозначениями и оставьте только сведения, необходимые для воспроизведения ошибки.
Чем внешний платёжный сервис отличается от своего второго сайта
Если оплата проходит у стороннего провайдера, обычно команда магазина не управляет его страницами и тегом. Простое добавление такого домена в свою схему не создаёт измерение действий внутри провайдера. Сначала установите, какую задачу решаете: связать два контролируемых сайта или корректно трактовать возвращение покупателя после оплаты.
Для второго случая Google описывает нежелательные переходы и прямо приводит пример платёжных систем. Их исключение из реферальных источников меняет обработку источника перехода. Оно не выполняет передачу идентификаторов между площадками и не подтверждает сохранение пользователя. Эти две настройки нужно проверять разными наблюдениями.
Возьмите тестовый маршрут «магазин — оплата — возвращение» и отдельно проверьте страницу возврата, состояние корзины, факт подтверждения заказа и назначение аналитического тега. Затем оцените источник в данных подходящего периода. Запишите, что удалось подтвердить, а что остаётся вне контроля вашей команды. Возврат на сайт сам по себе не является доказательством успешного платежа.
Не исключайте все внешние домены ради красивого отчёта без referral. Так можно скрыть полезные источники. Каждый адрес в исключениях должен иметь понятную роль в процессе, а изменение — зафиксированную причину. Важно сохранить возможность объяснить отчёт владельцу бизнеса после следующей смены подрядчика.
Учебный пример: три маршрута работают, четвёртый разрывает путь
Предположим, вымышленный проект использует example.com для описания услуг и example.net для записи. Оба домена контролируются командой и используют согласованный веб-поток. В тесте разрешено аналитическое хранение, браузер не меняется, а каждый переход выполняется сразу. Обозначения A1, B2, S1 и S2 ниже условные; это не реальные значения cookies или результат измерения конкретного клиента.
| Маршрут | Наблюдение до исправления | Следующее действие |
|---|---|---|
| Ссылка из меню на запись | A1 / S1 сохраняются | Оставить как контрольный маршрут |
| Отправка формы на систему записи | A1 / S1 сохраняются | Зафиксировать успешную обработку формы |
| Возврат из записи к описанию услуги | A1 / S1 сохраняются | Сохранить проверку обратного направления |
| Кнопка через промежуточный адрес | После перехода появляются B2 / S2 | Разобрать цепочку переадресации |
При исследовании последнего маршрута команда видит: первый запрос содержит _gl, промежуточный ответ направляет на URL без него, принимающая страница получает уже очищенный адрес. Разработчик исправляет именно этот обработчик. При повторении того же короткого перехода сохраняются A1 и S1; остальные три маршрута также проходят проверку.
Результат формулируют точно: четыре выбранных сценария прошли в записанных условиях после изменения обработчика. Из этого нельзя заключить, что проверены все браузеры, кампании и способы оплаты. Для важной воронки следующими берут реальные дополнительные сценарии из карты внедрения, а не увеличивают число одинаковых кликов ради внушительной цифры в отчёте.
Такая запись полезна при передаче задачи. Она содержит симптом, место потери, изменение и повторный результат. Если через месяц новый интерфейс снова перестанет сохранять путь, команда сможет воспроизвести контрольный сценарий и сравнить поведение с принятой версией.
Какие вопросы задать, если настройка выглядит правильной
Достаточно ли увидеть оба домена в одном отчёте? Это подтверждает наличие данных о площадках, но не тождественность посетителя на конкретном маршруте. Вернитесь к короткому воспроизводимому тесту и сопоставлению идентификаторов. Общий график посещаемости не показывает место потери параметра.
Можно ли проверить переход, вставив конечный URL в новую вкладку? Для проверки обычной ссылки начните с исходной страницы и выполните сам клик. Ручное открытие чистого конечного адреса пропускает шаг, работу которого вы пытаетесь оценить. Отдельно тестируйте способы открытия, которыми действительно пользуются посетители.
Почему список доменов сохранён, но часть маршрутов остаётся проблемной? Сравните успешный и неуспешный сценарии: шаблон, способ навигации, промежуточный адрес, загрузку тега и состояние согласия. Начните с первого наблюдаемого различия. Повторное сохранение той же настройки без нового наблюдения редко помогает установить причину.
Нужно ли добавлять UTM к каждой внутренней кнопке? Для задачи междоменного измерения это не критерий успеха. Сначала добейтесь корректной связи и понятного плана событий. Если команда хочет измерять эффективность конкретной кнопки, опишите это как отдельную аналитическую задачу с собственным событием и проверкой.
Как принять настройку и сохранить результат после обновлений
Согласуйте короткий протокол приёмки между владельцами двух сайтов. Он должен содержать дату, веб-поток, проверенные страницы, браузер, состояние согласия и наблюдения по каждому маршруту. Результат «работает» без этих условий сложно использовать после переноса магазина или замены формы.
- Участвующие страницы отправляют данные в согласованный веб-поток.
- Проверены реальные переходы, включая формы и отдельные мобильные элементы.
- Свежий параметр связи проходит необходимые промежуточные шаги.
- В контролируемом сценарии сопоставлены идентификаторы до и после перехода.
- Согласие проверено отдельно для разрешения и отказа.
- Внешняя оплата и исключения источников разобраны как отдельный маршрут.
- За каждой найденной проблемой закреплены исполнитель и повторная проверка.
Возвращайтесь к этому протоколу после изменения домена, системы заказа, шаблонов, редиректов или подключения аналитики. Сохранённая карта маршрутов позволяет проверять именно затронутую часть, а не начинать расследование с нуля. Для бизнеса результатом становится объяснимая воронка с понятными ограничениями измерения.
Чтобы отдельно контролировать внешнюю HTTP-доступность страниц на обоих доменах, подключите SiteGuard. Проверку идентификаторов GA4 и прохождения междоменных маршрутов закрепите за командой аналитики.