ClickHouse и модель аналитики сайта

Сайт ProfessorWeb публикует уроки, а кабинет читателя хранит текущие закладки и прогресс. Редактору нужен другой взгляд: сколько материалов открывают, какие завершают и возвращаются ли читатели позже. Создадим учебный поток «События» и постепенно построим собственные отчёты в ClickHouse. Первый результат — модель измерения, которая не смешивает историю действий с рабочим состоянием кабинета.

Предполагаются основы SQL, HTTP и представление о строках таблицы. Используем документированные SQL-механизмы ClickHouse, проверенные по официальным источникам 11 октября 2026 года. Конкретный установленный релиз здесь не выбирался, сервер не запускался, запросы не выполнялись. Все числа учебного набора и ответы далее являются ожидаемыми результатами разбора, а не измерениями посещаемости ProfessorWeb.

Рабочая запись и аналитическое событие

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

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

Событие отправляется после успешного действия основного приложения. Отказ аналитики не должен отменять сохранение прогресса читателя. Для более строгой доставки понадобится очередь или журнал исходящих событий, но эта серия прежде всего объясняет контракт и SQL. Не объявляем небольшую JSON-фикстуру готовым промышленным сборщиком.

Система	Основной вопрос	Пример
Рабочий репозиторий	Каково состояние сейчас?	У Алины есть закладка css-layout
Аналитика событий	Что происходило за период?	В октябре урок сохранили трижды
Диагностика приложения	Почему запрос оказался медленным?	Серверная операция заняла определённое время

Диагностическая трассировка, например через OpenTelemetry, описывает исполнение запросов и зависимостей. Наша аналитика описывает действия читателя. Один запрос может быть одновременно медленным и завершить урок, однако типы идентификаторов и срок хранения не обязаны совпадать. Не будем использовать технический trace ID как постоянный идентификатор аудитории.

Три события с определённым смыслом

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

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

Для каждой строки зададим event_id, anon_id, lesson_id, event_name, время действия и время получения. Общие уроки совпадают с проектом «Маршрут»: html-start, css-layout, js-events. Имена вымышленных читателей в отчёте не используются; вместо них условные анонимные обозначения a, b, c, d для фикстуры.

Набор, который будем развивать

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

Материалы: html-start, css-layout, js-events
Период действий: 1–4 октября 2026, UTC
Первичная доставка: 14 уникальных событий
Позднее событие: завершение html-start читателем b
Повтор: завершение html-start читателем a
Все доставки: 16 строк; все уникальные события: 15

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

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

Собственные отчёты и готовая аналитика

ClickHouse не создаёт автоматически правила сеанса, согласие, атрибуцию и интерфейс отчётов. Мы определяем поля, доставку, SQL и представление результата сами. Готовая система вроде GA4 предлагает свою модель и пользовательские отчёты; собственное хранилище даёт контроль, одновременно передавая владельцу ответственность за качество измерения.

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

Вопрос определяет допустимое измерение

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

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

Собственная аналитика полезна тем, что правила можно сделать прозрачными. Но прозрачность требует сохранить определения вместе с SQL и не менять их молча при обновлении dashboard. Далее будем возвращаться к этим определениям при каждом новом разрезе, чтобы число оставалось связанным с наблюдаемым фактом.

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

Оглавление серии