Создание конвейера аналитики обучения

Это инженерное руководство, а не юридическая консультация. Уточняйте детали у квалифицированного юриста.

Кратко

Конвейер аналитики обучения доставляет всё, что делает учащийся (каждый play и pause, ответ в тесте, завершение), от плеера на его экране до дашборда, по которому принимают решения. У него пять слоёв: сбор, транспорт, хранение, склад данных и подача. Главное решение, от которого зависит качество аналитики, принимается на первом слое: метрика не может быть богаче события, которое отправляет плеер, поэтому схему событий проектируют до того, как написан плеер. Большинство конвейеров губят две ошибки. Первая – собирать слишком мало: событие, которое вы не записали, задним числом не восстановить. Вторая – собирать слишком много: покадровая телеметрия видео разрастается до десятков гигабайт и отвечает на вопросы не лучше, чем выборочный поток в разы меньше. В статье разобрана вся сборка: схема событий xAPI, пакеты и выборка, выбор или разработка Learning Record Store, модель склада данных в российском контуре и меры приватности по 152-ФЗ, которые нужно заложить с первого коммита. Всё – со ссылками на сами стандарты.

Почему это важно

Если вы делаете обучающий продукт или отвечаете за его развитие, конвейер аналитики – это разница между «нам кажется, курс работает» и «модуль 3 теряет 60% учащихся на седьмой минуте, и вот как это исправить». Большинство команд покупают обучающую систему, довольствуются её готовыми отчётами и через год обнаруживают, что единственное нужное число, доказывающее эффективность обучения, так и не собрали, а восстановить его нельзя. Эта статья – руководство по сборке. В ней пять слоёв, схема и стандарты, по которым идут данные, расчёт объёма, который удерживает хранилище в разумных пределах, и меры приватности, которые удерживают данные учащихся в рамках закона. Она написана так, чтобы нетехнический владелец продукта мог оценить объём работ и поставить задачу инженерам, а инженеры нашли цитаты из спецификаций точными. Это практическое продолжение статьи Аналитика обучения: какие метрики важны: та объясняет, какие метрики важны, а эта – как сделать, чтобы они вообще появились.

Конвейер на одной картинке

Прежде чем писать код, представьте систему целиком. Конвейер аналитики обучения – это путь одного факта («учащийся посмотрел секунды с 0 по 95 видео модуля 3, затем вернулся к 70-й секунде») от момента, когда он произошёл, до момента, когда он повлиял на решение. У этого пути пять слоёв. Назвать их – первый шаг к хорошей сборке, потому что у каждого слоя свой владелец, свои типичные сбои и своя цена.

Сбор – плеер отправляет событие в момент, когда что-то происходит. Транспорт – надёжная доставка событий с устройства в ваши системы пакетами, без перегрузки сети. Хранение – Learning Record Store, источник истины, который принимает и хранит каждое событие. Склад данных – место, где сырые события преобразуют и связывают с остальными данными бизнеса, чтобы по ним можно было быстро строить запросы. Подача – дашборд, отчёт или API, которые превращают сохранённый факт в основание для действия.

Нажмите, чтобы увеличить

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

Решите до сборки: нужен ли вам свой конвейер?

Первый честный вопрос – «строить или купить», и большинство команд строят лишнее. Готовая система управления обучением (LMS – платформа, где размещены курсы и учащиеся) уже содержит отчётность, которая ничего не стоит и достаточна для отчётов о соответствии требованиям: кто что прошёл и когда. Если ваша единственная задача – доказать, что 800 сотрудников прошли вводный инструктаж по безопасности, свой конвейер аналитики не нужен: настройте LMS, которая у вас уже есть.

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

Нажмите, чтобы увеличить

Слой 1 – Сбор: сначала спроектируйте схему событий

Главное правило, которое определяет всё остальное: аналитика ограничена тем, что собрано. Если плеер никогда не отправляет «учащийся отмотал на десять секунд назад», ни склад, ни модель, ни дашборд не покажут вам повторные просмотры. Данные, которые вы не собрали в этом квартале, потеряны навсегда. Поэтому самый дешёвый и самый важный момент во всём проекте наступает до создания плеера, когда вы решаете, какие события он будет отправлять.

Формат событий задаёт стандарт – общая грамматика, чтобы любая система могла их прочитать. В обучении основная грамматика – xAPI, Experience API (старое рабочее название – Tin Can API). Событие xAPI – это утверждение (statement) в форме простого предложения: actor (субъект), verb (глагол) и object (объект) – «Maria – completed – Module 3». Это трёхчастное ядро спецификация делает обязательным [1]. Стандарт ратифицирован как IEEE 9274.1.1-2023 (неформально xAPI 2.0) и опубликован в октябре 2023 года [2]. Подробно сам стандарт разобран в статье xAPI (Tin Can): объяснение; здесь мы используем его для сборки.

Утверждение содержит больше, чем предложение. Основную аналитическую нагрузку несут две необязательные секции. result хранит результат действия: балл, флаг завершения, длительность и, для видео, нужные нам расширения. context хранит обстоятельства: какой курс, какая попытка, какой сеанс. Минимальное видео-утверждение с заведомо вымышленными данными выглядит так:

{
  "actor": {
    "objectType": "Agent",
    "account": { "homePage": "https://lms.example.edu", "name": "learner-8a3f" }
  },
  "verb": {
    "id": "https://w3id.org/xapi/video/verbs/seeked",
    "display": { "ru-RU": "перемотал" }
  },
  "object": {
    "id": "https://courses.example.edu/modules/3/video",
    "objectType": "Activity"
  },
  "result": {
    "extensions": {
      "https://w3id.org/xapi/video/extensions/time-from": 95.0,
      "https://w3id.org/xapi/video/extensions/time-to": 70.0
    }
  },
  "context": {
    "registration": "8f14e545-...",
    "extensions": {
      "https://w3id.org/xapi/video/extensions/session-id": "sess-44b"
    }
  },
  "timestamp": "2026-06-21T10:15:32.000Z"
}

Обратите внимание на три осознанных решения. Первое: субъект обозначен через account, а не email. xAPI позволяет обозначить учащегося через email (mbox), хеш email, OpenID или непрозрачный account в системе [1]. Непрозрачное имя вроде learner-8a3f вместо maria@company.com – ваша первая и самая дешёвая мера приватности; подробнее в слое 5. Второе: глагол и видео-расширения – это URL из xAPI Video Profile. Этот профиль утверждён сообществом и задаёт точный словарь событий видео: глаголы initialized, played, paused, seeked, completed, terminated и важнейшие расширения result – progress (доля пройденного, от 0 до 1) и played-segments (список реально просмотренных интервалов) [3]. Третье: registration связывает все утверждения одной попытки, и Video Profile агрегирует progress, played-segments и completion по этому значению [3]. Если плеер задаёт его один раз на попытку, чистая аналитика по попыткам достаётся бесплатно.

Нажмите, чтобы увеличить

Две привычки отличают удобную схему от той, о которой потом пожалеете. Используйте стабильные разрешаемые идентификаторы. Каждая активность (object.id) и каждый глагол – это URL (технически IRI), и как только под этим id сохранены утверждения, он фактически вечен. Заранее определите схему URL (https://courses.example.edu/modules/3/video) и список глаголов, оформите их как профиль и не допускайте, чтобы две команды выпустили два разных id для одного и того же. Отделяйте аналитические события от состояния возобновления. Место, где учащийся остановился (закладка «продолжить с 4:32»), – не аналитическое событие, а состояние. Для него в LRS есть отдельный State Resource (эндпоинт activities/state) – хранилище произвольных пар «ключ – документ» вроде позиции возобновления и настроек плеера [4]. Если класть закладки туда, поток утверждений остаётся чистым, а аналитические запросы – быстрыми. Особенности сбора видеоданных подробно разобраны в статье Трекинг видео через xAPI.

Несколько слов об альтернативе. Caliper Analytics консорциума 1EdTech – близнец xAPI: он задаёт MediaEvent для работы с видео с отметкой времени воспроизведения и упаковывает события в Envelope, где указаны идентификатор сенсора, время отправки, версия данных и пакет событий [5]. Сообщество стандартов считает xAPI и Caliper не конкурентами, а инструментами для разных задач: Caliper строже и чаще встречается в системах высшего образования, xAPI гибче и чаще используется в корпоративном обучении. Описанная дальше сборка подходит для обоих, меняется лишь диалект JSON.

Слой 2 – Транспорт: пакеты, выборка и устойчивость к сбоям сети

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

Отправляйте пакетами. Не делайте отдельный HTTP-запрос на каждое событие. Стандарт xAPI требует, чтобы LRS принимал целый массив утверждений в одном POST [4]: собирайте события в небольшую очередь в памяти и отправляйте, скажем, раз в несколько секунд или каждые двадцать событий. Важная деталь: пакет утверждений атомарен – по спецификации LRS должен отклонить весь пакет, если хоть одно утверждение в нём невалидно [4]. Поэтому проверяйте утверждения до отправки и не смешивайте второстепенные и критичные события в одном пакете, иначе одно ошибочное второстепенное событие потянет за собой completion. Caliper пакетирует так же: несколько событий передаются в массиве data одного Envelope [5].

Делайте выборку – именно на ней большинство конвейеров выигрывает или проигрывает. Наивный плеер отправляет событие «обновление времени» несколько раз в секунду. Если собирать их все, объём получается огромным. Посчитаем для одного 14-минутного модуля и 2000 учащихся.

«Наивный сбор, каждый time-update (~4 в секунду): 14 мин × 60 = 840 секунд × 4 = 3 360 событий на учащегося на модуль 3 360 × 2 000 учащихся = 6 720 000 утверждений на один модуль При ~1,8 КБ на утверждение [6]: 6 720 000 × 1,8 КБ ≈ 12 ГБ – на один модуль. Курс из пяти модулей: ≈ 60 ГБ на когорту, в основном бесполезной телеметрии.»

Теперь выборочная схема. Отправляйте глаголы действий только тогда, когда учащийся что-то делает (played, paused, seeked), добавьте регулярную отметку progress (пульс) каждые 10 секунд и одну сводку played-segments при паузе и завершении.

«Выборочный сбор: 840 с ÷ 10 = 84 отметки progress + ~15 событий действий ≈ ~100 утверждений на учащегося на модуль 100 × 2 000 = 200 000 утверждений ≈ 200 000 × 1,8 КБ ≈ 0,36 ГБ на модуль. Курс из пяти модулей: ≈ 1,8 ГБ на когорту – примерно в 33 раза меньше.»

Выборочный поток отвечает на все реальные вопросы (кривая оттока берётся из played-segments, повторные просмотры – из seeked, завершение – из progress) за тридцатую часть стоимости хранения и трафика. Смысл не в том, чтобы «собирать меньше», а в том, чтобы собирать с правильной детализацией. Покадровые события – шум; действия плюс пульс прогресса – сигнал.

Нажмите, чтобы увеличить

Переживите обрыв связи. Учащиеся заезжают в тоннели и лифты. Ставьте события в локальную очередь (в браузере или приложении) и отправляйте, когда связь вернётся. Это безопасно благодаря гарантии стандарта: у каждого утверждения есть уникальный id, сохранённое утверждение LRS не должен изменять, а второе утверждение с уже существующим id должен отклонить [4]. Благодаря этой неизменяемости повторная отправка идемпотентна: после обрыва очередь отправляется заново, и дубликаты просто отклоняются, а не учитываются дважды. При полностью офлайн-обучении утверждения хранят на устройстве и синхронизируют позже; этот случай мы разбираем в блоке о доступности и масштабе.

Слой 3 – Хранение: взять готовый LRS или написать свой

Learning Record Store (LRS) – источник истины, журнал, в который записывается каждое xAPI-утверждение. Это чётко определённая система: RESTful-веб-сервис, который принимает, хранит и возвращает утверждения, плюс ресурсы State, Agent Profile и Activity Profile для документов [4]. Именно это определение стандартизировал IEEE 9274.1.1-2023 [2]. LRS – не аналитическая база, а надёжный журнал, в который только дописывают и из которого она наполняется. Утверждения в LRS неизменяемы по замыслу стандарта [4]: для доверия и аудита это плюс, а при удалении данных – ограничение, которое нужно учесть (слой 5).

Выбор «написать или взять готовое» здесь почти всегда решается в пользу готового. Написать LRS, соответствующий стандарту, – значит реализовать полный API утверждений, состояния и документов, правила запросов и пагинации и пройти тесты на соответствие. Это месяцы работы, чтобы повторить то, что зрелые продукты уже умеют. Пишите своё только при необычном масштабе или интеграции, которую не поддерживает ни один продукт. В остальных случаях берите готовый, но с поправкой на место хранения: LRS с привязкой к учащимся – это база персональных данных, а с 01.07.2025 операции с ПДн граждан РФ с использованием баз данных за рубежом не допускаются [9]. Ниже – реалистичные варианты на 2026 год и стандарты, которые поддерживает каждый. (Сравнительная таблица обучающих инструментов всегда должна показывать поддержку стандартов – здесь в этом весь смысл таблицы.)

Open-source варианты (Learning Locker, SQL LRS) требуют самим заниматься хостингом и поддержкой, но взамен дают полный контроль над данными, отсутствие платы за запись и размещение в российском облаке рядом с остальным продуктом. Зарубежные облачные LRS с сильной встроенной аналитикой для ПДн российских учащихся не подходят, а поддержку xAPI и cmi5 российские LMS почти нигде публично не заявляют, поэтому на практике чаще всего выбирают self-hosted LRS плюс собственный склад и дашборды. Колонка SCORM важна, потому что старые курсы могут по-прежнему отправлять данные по стандарту SCORM. Он записывает лишь фиксированную модель данных (completion, балл, время) внутри LMS и рассматривает курс как чёрный ящик [7]. Посекундные видеоданные SCORM передать не может: если в планах тепловая карта, нужен xAPI Video Profile или Caliper, и решается это здесь, на слое хранения. Стандарты напрямую сравниваются в статье SCORM, xAPI, cmi5, LTI: какой стандарт.

Слой 4 – Склад данных: смоделируйте данные, чтобы отвечать быстро

LRS хорошо делает одну работу – надёжно хранит и возвращает утверждения – и плохо другую: отвечать на вопросы вроде «покажи медианный отток по модулям и когортам за прошлый квартал в разбивке по отделам». Утверждения – это глубоко вложенный JSON, одна строка на событие, а аналитике нужны плоские индексированные таблицы. Поэтому настоящий конвейер копирует данные из LRS в склад данных (data warehouse) – базу, рассчитанную на быстрые запросы по большим связанным наборам. В российском контуре склад для событийной аналитики чаще всего строят на ClickHouse – колоночной СУБД с открытым кодом. Её разворачивают у себя или берут как управляемый сервис в российском облаке, например Yandex Managed Service for ClickHouse, для которого провайдер заявляет соответствие требованиям 152-ФЗ [13]. Сторонние аналитические SaaS с хранением за рубежом для событий, привязанных к учащимся, не подходят по той же причине, что и зарубежный LRS [9].

Современный подход – ELT (extract, load, transform), а не прежний ETL. Вы извлекаете утверждения из LRS (у большинства есть API запросов или периодическая выгрузка), загружаете сырой JSON в склад без изменений и уже внутри склада преобразуете его в чистые таблицы [8]. Если сначала загружать сырые данные, точность не теряется, а сами данные можно заново преобразовать, когда появится новый вопрос (а он появляется всегда).

Преобразование превращает вложенные утверждения в звёздную схему: центральную таблицу фактов, окружённую таблицами измерений, с которыми она соединяется. В складе учебных данных обычно есть таблица fact_learning_event (одна строка на утверждение: кто, какой глагол, какая активность, балл, progress, время, registration), связанная с dim_learner, dim_activity, dim_course и dim_cohort. На этом слое бизнес-вопросы получают ответы, потому что здесь, и только здесь, учебные данные лежат рядом с данными HR, CRM или операционных систем (а значит, и с персональными данными сотрудников – ещё одна причина держать склад в России и выдавать доступ по ролям). Связь завершения обучения с продажами или частотой инцидентов по технике безопасности строится на складе, а не в LRS. Именно она позволяет доказать, что обучение влияет на бизнес-результат, а не просто создаёт активность.

Нажмите, чтобы увеличить

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

Слой 5 – Подача и приватность, которая охватывает весь конвейер

Последний слой превращает сохранённый факт в решение: учащийся видит свой прогресс и следующий шаг, преподаватель – отток в группе и сложность заданий, бизнес – завершение как подтверждение обучения и, где это оправдано, связь с результатами. Дашборды строят поверх склада – на Grafana, Apache Superset или BI-сервисе российского облака. Важно показывать каждой аудитории только метрики, которые относятся к её решениям: дашборд, который визуализирует всё и ничего не подсказывает, – самый частый способ убить аналитику. Проектирование отчётов, которыми действительно пользуются, – отдельное ремесло, разобранное в статье Отчётность по обучению.

Приватность – не слой в конце, а ограничение, которое закладывают в каждый слой. Поскольку записи об учащихся – персональные данные, у этого ограничения есть юридический вес: в России это 152-ФЗ. Пять инженерных мер удерживают конвейер в рамках закона. Держите все слои в России. LRS, склад, очереди и резервные копии с ПДн граждан РФ размещаются в российских базах данных: использовать зарубежные базы нельзя [9]. Если обработку ведёте вы как подрядчик (скажем, SaaS-платформа для вуза или работодателя), оператор поручает вам её договором, где перечислены данные, действия, цели и требования к защите [10]. Минимизируйте данные при сборе. Содержание и объём ПДн должны соответствовать заявленным целям и не быть избыточными [11]: собирайте только то, что нужно для конкретной цели. Поэтому в слое 1 мы использовали непрозрачный account-id, а не email: псевдонимный субъект гораздо менее рискован. Руководство Caliper тоже призывает держать контекстные данные в каждом событии минимальными [5]. Обезличивайте и храните ключ отдельно. Держите соответствие learner-8a3f реальной личности в отдельной системе со строгим контролем доступа, чтобы в аналитическом складе не было прямых идентификаторов: от 152-ФЗ это не освобождает, но резко снижает ущерб при утечке склада. Продумайте удаление с учётом неизменяемости. ПДн хранят не дольше, чем этого требуют цели обработки, а по их достижении уничтожают или обезличивают [11]. При этом LRS не позволяет редактировать утверждения [4], поэтому удаление означает обнуление или вычистку данных по субъекту. Спроектируйте эту операцию в первый же день, а не когда придёт первый запрос. Задайте сроки хранения и план реагирования до начала сбора. Решите, сколько живёт каждый класс данных, и автоматизируйте удаление: «хранить всё вечно» – это обязательство, а не актив. И подготовьте процесс на случай утечки: Роскомнадзор нужно уведомить в течение 24 часов, а штраф за саму утечку для юрлица – от 3 млн ₽, за повторную – 1–3% выручки [12].

Два частных случая. Если среди учащихся есть несовершеннолетние, согласие на обработку их данных дают законные представители, а если обработка опирается на согласие, с 01.09.2025 его оформляют отдельно от других документов [14]. Для школ и колледжей 273-ФЗ требует при электронном обучении с обработкой ПДн учеников использовать государственные информационные системы и «многофункциональный сервис обмена информацией» – мессенджер MAX [15]. Прежде чем проектировать собственный конвейер для школьного заказчика, выясните, есть ли ему вообще место в такой схеме.

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

Частая ошибка, из-за которой всё приходится переделывать

Главный провал такого конвейера – собирать события слишком поздно и слишком грубо. Команда выпускает плеер, который отправляет только «completed», запускается, а через три месяца владелец продукта спрашивает: «где учащиеся бросают модуль 3?» Ответа нет: плеер никогда не отправлял played-segments, по которым это было бы видно, а незаписанные события не восстановить. Исправление – доработка сбора и ожидание новой когорты, то есть потерянный квартал. Предотвратить это дёшево, но только в начале: спроектируйте подробную схему событий в слое 1, отправляйте события с первого релиза, даже если дашборда ещё нет, и храните их. Хранение дёшево, а недостающая история бесценна. Обратная ошибка – собирать каждое покадровое событие и тонуть в 60 ГБ шума. Это тот же провал планирования с другой стороны, и лечится он выборкой из слоя 2.

Где здесь Фора Софт

Фора Софт с 2005 года разрабатывает ПО для видеостриминга, real-time-связи на WebRTC и интерактивных плееров. В e-learning работа над аналитикой редко сводится к дашборду в конце. Главное – так настроить плеер на слое 1, чтобы нужные события в нужном стандарте и с нужной выборкой попадали в хранилище и склад, способные ответить на ваши реальные вопросы. Выбор «строить или купить», с которым мы помогаем командам, – тот же, что описан в статье. Готовая LMS бесплатно даёт типовую отчётность, но собственные тепловые карты оттока, собственные правила освоения и связь учебных данных с бизнес-результатами требуют своего слоя сбора, конвейера xAPI или Caliper и модели склада поверх него. Мы помогаем решить, какие вопросы оправдывают этот слой, а затем настраиваем сбор событий, без которого аналитика невозможна. Всё это мы разворачиваем в российском контуре – от LRS до склада и дашбордов. Та же схема «сбор – транспорт – хранение» лежит в основе наших проектов в видеоконференциях, телемедицине, OTT и видеонаблюдении.

Ключевые выводы

• У конвейера аналитики обучения пять слоёв: сбор, транспорт, хранение, склад, подача.
• Аналитика ограничена тем, что собрано: проектируйте схему событий xAPI до плеера.
• Делайте выборку: глаголы действий с пульсом progress дают те же выводы при объёме примерно в 33 раза меньше покадровой телеметрии.
• Отправляйте утверждения пакетами; благодаря неизменяемости повторная отправка после обрыва связи безопасна.
• LRS – неизменяемый журнал; быстрые запросы обеспечивает отдельный склад (например, ClickHouse в РФ).
• Закладывайте приватность в каждый слой: всё в РФ, псевдонимные id, минимизация, продуманное удаление, сроки хранения.

Что почитать дальше

• Аналитика обучения: какие метрики важны, а какие вводят в заблуждение
• Трекинг видео через xAPI: Video Profile и что отслеживать
• Отчётность по обучению для учащихся, преподавателей и бизнеса