Еженедельное исследование AI-поиска: почему одного названия платформы недостаточно

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

Источники раздела:[1] Perplexity[2] ACL Anthology[3] Google Analytics

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

Источники раздела:[1] Perplexity

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

Источники раздела:[2] ACL Anthology

Документация Google Analytics важна для понимания трафика: переходы из AI Overviews и AI Mode могут попасть в обычный канал органического поиска, а не в отдельную группу AI-сервисов. Поэтому один отчёт по переходам из AI почти наверняка неполон. Отдельно сохраняйте источник и канал визита, первую открытую страницу, адрес предыдущей страницы, переходы из Telegram и прямые визиты. Если предыдущая страница не передалась, это не доказывает, что пользователь пришёл из AI. Панель должна показывать эту неопределённость, а не выдавать техническую классификацию за знание о мотивах пользователя.

Источники раздела:[3] Google Analytics

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

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

Источники раздела:[1] Perplexity[2] ACL Anthology[3] Google Analytics

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

Источники раздела:[1] Perplexity[2] ACL Anthology[3] Google Analytics

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

Источники раздела:[1] Perplexity[2] ACL Anthology[3] Google Analytics

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