Реферальный ИИ-трафик: как измерить посетителя из ChatGPT

Четверг, 14:40. Руководитель по маркетингу открывает отчёт по переходам и видит: за последние тридцать дней с chatgpt.com пришло 412 сессий. Она разворачивает экран к руководителю продаж, и звучит один вопрос: сколько из них запросили коммерческое предложение? Ответа нет. В CRM у 87 сделок, открытых за тот же месяц, в поле источника либо стоит «прямой заход», либо пусто. Отчёт по трафику живёт отдельно, таблица выручки отдельно, и ни одно поле их не связывает. Цифры здесь условные, но картина знакомая.

Эта статья — о том, как закрыть тот разрыв. Как сделать переходы из ИИ-ассистентов видимыми в самой аналитике, разбирает материал про ChatGPT и Perplexity в GA4; здесь мы делаем следующий шаг. По порядку: что вообще доказывает, что визит пришёл от ассистента, и какие referrer- и UTM-шаблоны указывают на какой движок; почему информация о переходе теряется на полпути; как перенести данные уровня сессии в карточку конкретного человека; какие поля должны быть в лиде; где чаще всего рвётся цепочка атрибуции; закрывает ли разрыв вопрос «откуда вы о нас узнали»; как не посчитать одного посетителя дважды; как отчитываться за день, который не удалось измерить; чем этот трафик платит — кликами или выручкой; и какие еженедельные проверки удерживают всю конструкцию.

Что доказывает, что визит пришёл от ИИ-ассистента?

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

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

Одно различие стоит провести сразу: краулер движка и посетитель, которого движок прислал, — это не одно и то же. Агенты вроде GPTBot, ClaudeBot, PerplexityBot или Google-Extended читают ваш сайт, чтобы собрать содержимое; это не человеческий визит, и в отчёте он не должен стоять в одной строке с человеком. В GEO-части Rocketly инструменты llms.txt, robots и разметки считывают статус доступа каждого такого агента по отдельности — этот экран отвечает на вопрос «пускаем ли мы ботов», а не «сколько людей пришло». Сложить их в один график — самый короткий путь к тому, чтобы движок, не приславший ни одного посетителя, выглядел успешным.

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

Ассистент	Типичный домен перехода	Частый параметр	На что смотреть при измерении
ChatGPT	chatgpt.com, chat.openai.com	utm_source=chatgpt.com	Клики из десктопного и мобильного приложения обычно приходят без домена перехода и падают в прямой трафик
Perplexity	perplexity.ai и его поддомены	utm_source=perplexity	Поддомены копятся отдельными строками; приводите имя хоста к одному виду до подсчёта
Gemini	gemini.google.com	—	Клик из ИИ-сводки в поиске выглядит как органика и отдельного домена перехода не создаёт
Claude	claude.ai	—	Ссылки внутри ответа открываются в новой вкладке, часто без информации о переходе
Copilot	copilot.microsoft.com, bing.com	—	Смешивается со строками поисковой системы; не кладите ассистента и поиск в одну корзину
Grok	grok.com, x.com	—	Пересекается с переходами из соцсетей; судить только по домену — ошибка

Почему информация о переходе теряется на полпути?

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

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

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

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

Аналитика считает сессии, CRM хранит людей и сделки. Автоматического моста между этими мирами нет. Строка «412 сессий с chatgpt.com» не говорит, кто из них заполнил форму: аналитика не знает вашего лида, а CRM не знает браузерной сессии.

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

Второй мост — то, что превращает анонимного посетителя в известный контакт. Обмен руководства, калькулятора или чек-листа на адрес почты делает идентичность визита постоянной, и на стороне измерения это и есть настоящая работа лид-магнита. Пока нет идентичности, атрибутировать нечего — нет карточки, к которой можно привязать источник.

Какие поля должны быть в карточке лида?

Одного поля «источник» для этой задачи мало. На практике нужно шесть, и каждое отвечает на свой вопрос. Канал первого касания: как человек нашёл вас впервые. Домен первого перехода: сырое имя хоста, приведённое к одному виду. Первая страница входа: какой материал стал источником ответа. Канал последнего касания: то, что было прямо перед отправкой формы. Дата первого касания: без неё цепочку задним числом не собрать. И метка классификации: карточка подтверждённая, вероятная или неопознанная.

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

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

Где чаще всего рвётся цепочка атрибуции?

Она рвётся в четырёх точках. Первая — смена устройства: вопрос задан с телефона в обед, форма заполнена с ноутбука вечером. Две сессии ничем не связаны, и карточка открывается под каналом второго устройства.

Вторая — телефонный звонок. Посетитель набирает номер со страницы, и цифровой след на этом кончается. Способ прикрепить источник к звонку — показывать разный номер разным каналам и сопоставлять входящий вызов с карточкой; довести звонок до нужной команды и открыть карточку — задача умной маршрутизации звонков. Иначе самые качественные обращения в отчёте не появятся вовсе.

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

Закрывает ли разрыв вопрос «откуда вы о нас узнали»?

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

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

Как не посчитать одного посетителя дважды?

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

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

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

Как отчитываться за день, который не удалось измерить?

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

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

Чем платит этот трафик — кликами или выручкой?

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

Второй — совокупная ценность отношений. Судить о канале как о дешёвом или дорогом по одной сделке значит обманываться; когда пожизненная ценность клиента считается по каналам, порядок нередко меняется.

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

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

Какие еженедельные проверки удерживают конструкцию?

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

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

Если вы хотите видеть эти четыре проверки на одной панели и получать еженедельный отчёт автоматически, откройте бесплатный аккаунт в Rocketly и попробуйте GEO-экраны на своём домене.

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

Почему трафик из ассистентов выглядит как прямой?

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

Достаточно ли правила канала по домену перехода?

Для старта достаточно, само по себе — нет. Списки доменов устаревают: появляются новые ассистенты и поддомены. Пересматривайте правило раз в месяц, приводите имена хостов к одному виду, а переходы, не попавшие под правило, складывайте в отдельный список. Этот список сам напишет следующую версию правила.

Как отделить краулер движка от его посетителей?

Доступ краулера виден в логах сервера и в конфигурации robots; посетителей считает тег измерения на странице. Это разные источники, и складывать их в один график нельзя. Доступ краулера отвечает за то, попадёт ли ваш материал в ответ; визит — за то, приводит ли ответ к вам людей.

Сколько источников данных нужно для такой настройки?

Три: тег измерения на сайте, скрытые поля форм и поля атрибуции в CRM. Добавьте четвёртым измерение видимости в самих ассистентах — и причину изменения трафика можно будет искать на стороне видимости. Начать можно и без него, но вопрос «почему» останется без ответа.