Что измерять на учебном сайте

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

Начнём серию с плана измерения. Мы будем работать с маленькой вымышленной библиотекой analytics-lab, которая использует знакомые документы XML и Markdown. Их постоянные адреса взяты из общего учебного примера; статистика и действия посетителей придуманы. На настоящем ProfessorWeb мы сохраняли маршруты и отделяли содержание от шаблонов. Это позволяет поставить задачи измерения, но не даёт готовых результатов аналитики.

От задачи читателя к наблюдению

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

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

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

Вопрос	Наблюдение	Возможное решение
Какие статьи открывают?	Открытия по стабильному ID	Проверить содержание и место в каталоге
Продолжают ли маршрут?	Активация ссылки следующего шага	Проверить переход и предпосылки главы
Нужен ли учебный исходник?	Активация ссылки примера	Улучшить объяснение запуска и структуры
Помог ли материал решить задачу?	Одних событий недостаточно	Добавить содержательную обратную связь

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

Две статьи и один учебный маршрут

В реестре остаются xml с адресом /my/LINQ/linq_xml/level7/7_1.php и markdown с адресом /articles/markdown-guide.html. ID обозначает документ, URL служит переходу, название помогает человеку. Изменение заголовка не создаёт нового материала в отчёте. Иначе редактор потеряет историю как раз тогда, когда захочет проверить результат своего улучшения.

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

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

Рассмотрим вымышленный период W1. У Markdown было 100 открытий и 20 активаций следующего шага. Отношение равно 20%. Мы называем его отношением lesson_next к lesson_open, а не долей обученных читателей. Если один посетитель несколько раз нажал ссылку, событие может повториться; если назначения не удалось загрузить, переход к чтению ещё не состоялся.

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

Условия сравнения

К каждому будущему отчёту запишем период, источник, набор документов и применённые фильтры. Для учебных таблиц используются два семидневных периода W1 и W2, устройство desktop и условная страна sample_country. Эти значения не описывают реальную аудиторию. Они позволяют удерживать условия одинаковыми и объяснять вычисления без доступа к чужой панели.

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

Сведения из поисковой панели тоже остаются отдельными. Показ результата Google не равен открытию страницы с исполненным JavaScript. Клик может привести к странице, где счётчик заблокирован, либо закончиться сетевой ошибкой. В SEO-курсе мы исследовали доступность и показы; здесь задача продолжается после входа на сайт. Эти источники дополняют друг друга, а не обязаны давать одинаковые суммы.

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

Минимальный набор данных

В рабочей заметке measurement-plan.md достаточно сохранить вопрос, событие, единицу счёта, условия сравнения и решение, которое может последовать. Не начинайте с передачи любых строк страницы. Для наших задач нужны ID материала и название действия; email, текст поискового запроса и содержимое формы не помогают посчитать переход к следующему уроку.

Метрика позволяет передавать целевые действия и дополнительные параметры, а GA4 строится вокруг событий. Возможность платформы не обязывает использовать все её поля. Собственная модель должна объяснить назначение каждого параметра и порядок его удаления, если он больше не нужен. Передача событий в Метрику, события Google Analytics.

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

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