Аналитика нескольких доменов: как сохранить источник при переходе с контентного сайта на основную форму

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

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

Миф: если ссылка содержит UTM-метки, источник сохранится сам

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

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

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

Граница, где привычная логика перестаёт работать

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

Особенно внимательной проверки требует ситуация, когда контентный домен выполняет роль первого касания, а основной сайт собирает заявки. В таком сценарии нельзя оценивать статьи только по последнему источнику формы. Иначе материал будет регулярно помогать рекламе или органическому поиску, но отчёт этого не покажет.

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

Точное правило: при переходе между доменами передавайте не только ссылку, но и идентичность визита

Задача не сводится к тому, чтобы дописать метки к каждой кнопке. Нужно настроить единую логику измерения пути: система должна распознавать, что посетитель на основном сайте, это тот же человек, который до этого читал материал на другом домене.

Конкретный способ зависит от используемой аналитики и технической реализации сайтов. Но проверка всегда строится вокруг одной последовательности:

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

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

Как выглядит корректная структура ссылки и записи в заявке

Ссылка из материала не должна быть просто адресом основного сайта вида https://site.ru/form, если техническая схема не передаёт идентификатор перехода автоматически. В ней либо должны сохраняться параметры исходного визита, либо должна работать междоменная связка, которая передаёт служебный идентификатор без ручного копирования меток.

В самой заявке полезно хранить несколько отдельных полей, а не одну строку Источник:

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

Например, корректная запись может выглядеть так: Первый источник: поиск. Первая страница: /materials/kak-vybrat-uslugu. Переход к форме: /request. Кампания: spring_search. Такая структура показывает и роль контентного материала, и место, где пользователь решил оставить заявку.

Что сравнить после настройки

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

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

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