Сопоставимые запросы и журнал наблюдений

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

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

Запрос как воспроизводимая единица

Слова «перенос старого сайта» могут означать разные задачи. Один человек хочет сохранить URL, другой ищет новую CMS, третий выясняет, почему исчезли изображения. Если каждый раз наблюдать случайную формулировку, изменение ответа нельзя уверенно отнести к доработке одной страницы. Поэтому запрос получает устойчивый query_id, полный текст и intent_id. Текст сохраняем буквально, а намерение описываем отдельным коротким именем.

В query-panel.csv строка Q01 относится к задаче preserve-url, Q02 — к проверке прежних PHP-адресов, Q03 — к организации Markdown. У двух вопросов может быть общее намерение, но это не разрешает объединять их наблюдения до расчёта. Такая структура позволяет позднее заметить, что урок отвечает на общий вопрос, но не объясняет частный случай со старым расширением. Для редактора это полезнее, чем список похожих ключевых слов.

Второй файл, observations.csv, хранит отдельную попытку наблюдения. В ней есть observation_id, время, система, регион, язык, тип устройства, состояние авторизации и признак генеративного ответа. Поле site_mentioned заполняем лишь для ответа, который действительно присутствовал. Если генеративного блока нет, значение становится not_applicable, а не false. Иначе в знаменателе смешаются разные события.

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

При повторении сохраняем прежний текст вопроса и добавляем новую попытку, не перезаписывая старую. Это важнее обещания получить один и тот же ответ. Яндекс указывает, что ответы и состав источников могут меняться. Запись условий помогает различить изменение страницы, изменение окружения и обычную вариативность ответа, хотя полностью отделить эти причины ручная панель не сможет.

Из строки наблюдения в редакционную задачу

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

Из строки Q02 видим содержательный недостаток: ответ обсуждает редиректы, а страница Lab объясняет лишь новое дерево каталогов. Запишем гипотезу: добавить полный пример соответствия исторического URL и Markdown-файла. Это не инструкция немедленно создавать ещё одну почти одинаковую статью. Сначала откроем существующий урок, проверим намерение и решим, нужен ли отдельный результат или достаточно связанного раздела.

Измените учебное условие: один вопрос оказался слишком широким. Не заменяйте его текст в старой панели. Создайте версию panel-v2, отметьте дату и причину, а старые результаты оставьте с panel-v1. Для динамики можно использовать только общий неизменный набор либо показывать разрыв метода. Иначе улучшение доли окажется последствием удаления неудобных вопросов.

Последний столбец журнала называется editorial_note. В нём объясняем наблюдение обычным языком: отсутствует пример, неясна версия, ссылка ведёт на обзор вместо инструкции. Здесь не место для записи «алгоритм предпочитает длинные страницы»: панель такой причинный вывод не подтверждает. Полученный журнал в следующем уроке свяжем с устойчивыми идентификаторами страниц.

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

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

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

Чтение сохранённого состояния

Читайте панель и журнал как два связанных файла. Первая таблица описывает вопрос, вторая — конкретную попытку. Один query_id может повторяться во многих наблюдениях. Если соединить их и посчитать количество строк панели как количество ответов, знаменатель получится неправильным. Для нашего результата нужны только попытки с ai_answer: present.

Строка	Значение для наблюдения
Q02	Частный вопрос о PHP-пути сохраняется без переформулировки между версиями одной ручной панели.
O01 и O04	Это две вымышленные попытки с упоминанием, а не подтверждение двух разных реальных посетителей.
O09–O11	Ответ недоступен, поэтому упоминание не оценивается и в знаменатель доли эти строки не входят.
panel-v1	Имя методики позволяет отличить повторное наблюдение от новой выборки с изменёнными вопросами.

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

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

Основной артефакт query-panel.csv находится в lesson-02 архива серии. Полный снимок содержит также исходные таблицы и договоры. Они читаются вручную; результаты примеров описаны как ожидаемые, выполнение не проводилось.

Первичные источники: alice.