Как оценить обращения из поиска и ответов ИИ

Определите, что именно хотите измерить

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

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

Соберите доступные признаки

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

Учитывайте особенности поисковых отчётов

В справке Search Console, проверенной 14 сентября 2026 года, описан отдельный Generative AI performance report для показов в AI Overviews и AI Mode. Доступны разрезы страниц, стран, устройств и дат. Показ ссылки не равен переходу или обращению; эти данные нельзя складывать с общим Web как независимый трафик.

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

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

Свяжите обращение с качеством

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

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

Учебный пример: противоречащие признаки

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

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

Показывайте уверенность и пробелы

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

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

Как не посчитать одну заявку дважды

Условный пример ниже показывает сверку трёх обращений. Идентификаторы учебные, персональные сведения для объяснения метода не нужны.

В таблице три обращения, а не пять касаний, превращённых в пять лидов. Для L01 нельзя без дополнительного основания заменить источник визита на ИИ; для L03 нельзя заявить технически подтверждённый переход. Сохраняйте раздельные поля и одинаковые правила в обоих сравниваемых периодах.

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