Трекинг видео через xAPI: Video Profile и что отслеживать

Коротко

xAPI Video Profile – опубликованный и согласованный сообществом «рецепт»: он точно описывает, как видеоплеер записывает действия учащегося (каждый запуск, паузу, перемотку и конкретные просмотренные секунды) в виде стандартных утверждений (statements) для Learning Record Store. Профиль задаёт фиксированный набор действий (initialized, played, paused, seeked, interacted, completed, terminated) и измеряемых полей (time, progress, played-segments, а также контекст вроде длины видео и порога завершения), поэтому ваши данные совместимы с чужими, а не остаются самодельным диалектом. Профиль нужен, как только вам важно больше, чем «досмотрел ли»: с ним видно, что учащийся увидел лишь 35% лекции, пересматривал один фрагмент и ушёл на 19-й минуте, а один флаг завершения в SCORM этого не покажет. Цена – дисциплина: польза от трекинга целиком зависит от того, насколько продуманно спроектированы утверждения.

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

Если видео – основа вашего обучающего продукта, то данные от плеера отделяют догадки от знания. Руководитель обучения, который видит только «completed: yes», работает вслепую; тот, кто видит точную секунду, на которой зрители уходят, знает, какую лекцию переснять. Статья написана для L&D-директора, продакт-менеджера или основателя, который решает, как собирать данные о просмотре видео, и для инженера, которому нужно с первого раза правильно отправлять утверждения. Мы точны до имени поля и версии спецификации: ошибку в структуре утверждений дорого обнаружить через полгода и десять миллионов записей. Элементы, которые отправляют утверждения, и аналитика, которая их использует, разобраны в отдельных статьях по ссылкам ниже.

Проблема: «просмотрено» – это не одно событие

Представьте 20-минутную записанную лекцию внутри курса. Со старым стандартом упаковки – Sharable Content Object Reference Model, или SCORM (см. SCORM: объяснение), – плеер по окончании видео сообщает учебной системе только одно: поле статуса (cmi.core.lesson_status в SCORM 1.2) переключается в completed. Такой статус отвечает на вопрос «досмотрел ли?» и больше ни на какой.

Но за словом «просмотрено» прячется десяток реальных вопросов. Учащийся посмотрел всё или перемотал в конец, чтобы получить завершение? К каким тридцати секундам все возвращались – к запутанному месту или к самому ценному? Где половина группы бросила смотреть? Для обучающего видео смысл именно в этих ответах, а флаг завершения их теряет.

Фиксировать такие ответы умеет xAPI, Experience API (см. xAPI: объяснение). xAPI записывает обучение короткими фразами вида «actor, verb, object», например «Мария поставила на паузу видео по пожарной безопасности», и хранит их в специальной базе – Learning Record Store (LRS), своего рода журнале таких записей. Сам xAPI намеренно открыт: вы могли бы придумать собственный способ описывать видео. Беда в том, что ваше самодельное «video play» и чужое «play video» никогда не сойдутся в одном отчёте. Поэтому сообщество зафиксировало один общий способ.

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

Что такое xAPI Video Profile

Профиль в терминах xAPI – согласованный сообществом словарь для одного вида опыта: общий список verbs (действий), общий activity type (тип активности) и общие поля-расширения. Каждый элемент задан постоянным веб-адресом, чтобы две системы понимали одно слово одинаково. xAPI Video Profile – такой словарь для видео. Текущая опубликованная версия – v1.0.3. Профиль с идентификатором https://w3id.org/xapi/video/v1.0.3 хранится в репозитории авторских профилей инициативы Advanced Distributed Learning (ADL) – той самой, что создала SCORM и развивала xAPI.

Профиль работает как разговорник. Без него каждый плеер импровизирует, и в отчётах начинается вавилонское столпотворение. С ним история просмотров переносима: любой совместимый LRS, инструмент отчётности или другой вендор прочитает ваше «paused на 54,3 секунде» однозначно. Ради этой переносимости профиль и берут вместо собственных событий.

Две исторические детали помогут не запутаться. До профиля в отрасли использовали неформальный «xAPI video recipe» (verbs вроде play, watch, skip) и старый activity type http://adlnet.gov/expapi/activities/video. Такой подход ещё встречается в старом контенте и на некоторых видеоплатформах: часть из них отправляет played и watched с полем прогресса в стиле cmi5, а не профиля. Ориентируйтесь на профиль v1.0.3, а recipe, возможно, придётся только читать. И учтите: это профиль сообщества (authored profile), а не часть ядра стандарта IEEE xAPI (IEEE 9274.1.1-2023). Он надстроен над xAPI и использует его правила.

Семь verbs: о каких действиях сообщает плеер

Профиль задаёт семь действий, о которых может сообщать видеоплеер. Каждое из них – verb: действие, заданное постоянным веб-адресом и человекочитаемым названием, так что «paused» всегда означает одно и то же. Три verbs введены самим профилем (played, paused, seeked), ещё четыре взяты из общего набора, который ADL опубликовала раньше (initialized, interacted, completed, terminated). Разница важна только при записи адресов, но именно такие детали отличают совместимую реализацию от почти совместимой.

У профиля есть несколько жёстких правил. Утверждение initialized должно быть первым в видеосессии, и отправлять больше одного такого утверждения за сессию нельзя: это отметка «сессия началась». Остальные утверждения привязываются к этому началу через общий идентификатор registration (о нём ниже). Ошибка в начале сессии не позволит потом корректно её разобрать.

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

Object: каждое утверждение указывает на видео

В каждом утверждении object – то, к чему относится действие, – это само видео, и профиль строго регламентирует, как его описывать. Activity type объекта должен быть https://w3id.org/xapi/video/activity-type/video, а идентификатор видео – уникальным веб-адресом в вашем домене. Здесь ошибаются чаще всего: один activity ID на два разных видео или новый ID при каждой загрузке страницы превращают любой будущий отчёт в кашу. Одно видео – один стабильный ID, навсегда.

"object": {
  "id": "https://example.com/videos/fire-safety-intro",
  "definition": {
    "type": "https://w3id.org/xapi/video/activity-type/video",
    "name": { "ru-RU": "Пожарная безопасность: введение" }
  }
}

Result: где хранятся числа

Verb сообщает, что произошло, а result содержит измерения. Профиль задаёт пять полей result, все с адресами вида https://w3id.org/xapi/video/extensions/.... Именно их будет читать ваша аналитика.

Первое поле – time: точная секунда видео, на которой произошло событие, в виде числа, например 54.3. Второе и третье – time-from и time-to – есть только в утверждении seeked и фиксируют скачок, например «с 300-й секунды на 1080-ю». (Учащийся может перемотать и назад, поэтому time-to бывает меньше time-from; это не ошибка.)

Четвёртое – progress: какую долю видео учащийся уже просмотрел, в виде десятичной дроби от 0 до 1, то есть 0,35 – это 35%. Тут важно не перепутать: progress – это охват, доля уникального просмотренного материала, а не то, как далеко ушла позиция воспроизведения. У того, кто перемотал в конец, позиция воспроизведения большая, а progress маленький.

Пятое и самое полезное поле – played-segments: точные диапазоны видео, которые учащийся действительно посмотрел, в хронологическом порядке. Это строка в собственном формате: каждый просмотренный отрезок записывается как from.to, отрезки разделяются, а значения времени совпадают с time, time-from и time-to в этой сессии. Значение 0[.]300[,]1080[.]1140 читается как «просмотрены секунды 0–300, затем 1080–1140». Именно played-segments превращает разрозненные события в тепловую карту внимания.

"result": {
  "extensions": {
    "https://w3id.org/xapi/video/extensions/time": 300.0,
    "https://w3id.org/xapi/video/extensions/progress": 0.35,
    "https://w3id.org/xapi/video/extensions/played-segments": "0[.]300[,]720[.]780[,]720[.]780[,]1080[.]1140"
  }
}

Context: настройки и привязка к сессии

Context содержит сопутствующие сведения: общую длину видео, настройки плеера и, главное, идентификатор, который связывает утверждения одной сессии. Профиль задаёт набор расширений context (тоже с адресами в w3id.org/xapi/video): length (длина в секундах), completion-threshold (о нём ниже), session-id, cc-subtitle-enabled и cc-subtitle-lang (включены ли субтитры и на каком языке), frame-rate, full-screen, quality, screen-size, video-playback-size, speed (скорость воспроизведения), track (звуковая дорожка или дорожка субтитров), user-agent и volume.

Связывает всё поле registration – стандартное поле context в xAPI, а не расширение профиля. Это идентификатор одной попытки прохождения, и для аналитики видео он ключевой: progress, played-segments и completion считаются по всем утверждениям с одной registration. Так система понимает, что три захода учащегося – одна попытка по одному видео, и правильно суммирует уникальные секунды. Выбирайте registration продуманно (обычно одна на учащегося на попытку просмотра видео): от неё зависят все дальнейшие агрегаты.

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

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

Что должен содержать каждый verb

Профиль не оставляет состав полей на усмотрение разработчика: для каждого verb заданы обязательные поля. Заучивать таблицу не нужно, но плеер обязан ей следовать: совместимые LRS и инструменты отчётности рассчитывают на эти поля.

Особенно важны два правила. Для paused профиль требует полный набор измерений – time, progress и played-segments, – потому что пауза – естественная контрольная точка для записи накопленного просмотра. А утверждение completed должно содержать result.completion: true и result.duration – общее время просмотра видео в рамках текущей registration в формате длительности ISO 8601 (например, PT7M0S для семи минут). Завершение без duration и played-segments – запись лишь наполовину.

Порог завершения: честное определение «готово»

Здесь команды чаще всего незаметно обманывают себя. Completion-threshold – поле context (десятичная дробь от 0 до 1), которое задаёт, какую долю видео нужно просмотреть, чтобы получить «completed». Если его не указать, профиль считает порог равным 1,0, то есть 100%. Любое другое значение нужно включать в утверждения initialized, paused, completed и terminated, чтобы смысл «completed» хранился рядом с самим утверждением.

Это поле заставляет честно решить, что значит «completed» для конкретного видео. Учащийся должен увидеть каждую секунду (порог 1,0)? Или достаточно 90%, учитывая финальные титры (0,9)? Опасно здесь негласное допущение. Команда, которая отправляет completed, как только позиция воспроизведения дошла до конца, и не проверяет охват, отметит «completed» тому, кто перемотал на последнюю секунду и реально посмотрел 5%. Связка порога и progress в профиле нужна как раз для того, чтобы этого не допустить. Сверяйте progress с порогом, прежде чем засчитывать завершение.

Разбор примера: что показывает одна 20-минутная лекция

Возьмём 20-минутную лекцию – 1 200 секунд – и одну учащуюся, Марию, с порогом завершения 0,85 (85%).

Мария открывает видео (одно утверждение initialized с length: 1200 и completion-threshold: 0.85). Она смотрит первые пять минут, перематывает вперёд, дважды подряд смотрит сложную минуту, снова перематывает и вскоре останавливается. Плеер отправляет один initialized, несколько played, paused и seeked по ходу просмотра и terminated, когда она закрывает вкладку. Допустим, её played-segments, агрегированные по сессии с одной registration, составили 0–300 секунд, затем дважды 720–780 секунд и 1 080–1 140 секунд, то есть строку 0[.]300[,]720[.]780[,]720[.]780[,]1080[.]1140.

Посчитаем охват. В played-segments учитывается уникальный материал, поэтому дважды просмотренная минута засчитывается один раз:

Уникальные секунды = 300 + 60 + 60 = 420 секунд
Охват (progress)   = уникальные секунды ÷ общая длина
                   = 420 ÷ 1 200
                   = 0,35  →  реально увидено 35% видео

Progress Марии – 0,35, заметно ниже порога 0,85, поэтому completed не отправляется, и это правильно. В SCORM плеер отметил бы урок завершённым, как только позиция воспроизведения дошла до конца, и запись «completed» скрыла бы всё остальное. Video Profile вместо этого сообщает преподавателю: увидено 35%, один фрагмент пересмотрен, просмотр прерван на 19-й минуте. Это повод переснять лекцию, а не поставить галочку. Ради такой арифметики видеопродукты и используют профиль.

У такой подробности есть цена, и её лучше оценить заранее. Один внимательный просмотр может дать десять и более утверждений. Десять тысяч учащихся на одном видео – порядка 100 000 утверждений; курс из пятидесяти видео – уже миллионы. Под них нужна полноценная инфраструктура хранения и запросов, поэтому самое сложное решение здесь – выбор LRS, а не код плеера. Для российской аудитории добавляется требование к размещению: LRS с утверждениями о реальных учащихся должен находиться в России (подробнее – в разделе об ошибках). Как превратить этот объём в дашборды, разобрано в статьях Создание конвейера аналитики обучения и Тепловые карты вовлечённости и аналитика внимания.

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

Как сравниваются подходы к трекингу видео

Video Profile – лишь один из способов отслеживать видео. Ниже – что показывает каждый из них и на каком стандарте он основан.

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

Последнюю строку команды часто упускают. xAPI и Video Profile описывают, что произошло, но не определяют, как LMS запускает и назначает контент; это добавляет cmi5 (см. cmi5: объяснение). Если видео должно быть назначаемой единицей внутри учебной системы и при этом нужен трекинг уровня профиля, берите cmi5, который передаёт утверждения Video Profile. Полное сравнение четырёх стандартов – в статье SCORM, xAPI, cmi5 и LTI: какой стандарт и когда выбрать. Если курс работает в Moodle, учтите: штатно она воспроизводит SCORM 1.2, а xAPI и cmi5 подключаются плагинами (подробнее – в статье Интеграция с Moodle).

Как проектировать утверждения под будущую аналитику

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

Начинайте с вопросов, а не с событий. Если спросят «какой фрагмент учащиеся перематывают?», понадобятся утверждения seeked с точными time-from и time-to и played-segments в контрольных точках. Если спросят «какой у нас реальный процент завершения?», нужен честный порог завершения и сверенный с ним progress. Проектируйте утверждения под отчёт, иначе после запуска придётся переделывать сбор данных.

Следите за объёмом. Утверждение на каждое микрособытие перегрузит LRS, а слишком редкие утверждения не дадут построить тепловую карту. Распространённый подход: записывать played, paused и seeked при реальных действиях пользователя, собирать их в пакеты на клиенте и отправлять периодически, но при этом гарантировать обязательные поля в paused, completed и terminated. Интерактивные элементы, которые порождают эти события (квизы, подсказки, активные зоны), разобраны в статье о квизах и опросах в плеере.

Копируйте канонические ID, а не перепечатывайте. Адреса verbs и extensions из этой статьи – основа совместимости: опечатка в URI незаметно создаёт самодельный диалект, который не прочитает ни один сторонний инструмент.

Частые ошибки

Пять промахов повторяются почти в каждом проекте трекинга видео: каждый легко предотвратить и дорого исправлять потом.

Первый – трекинг видео без профиля. Самодельные события «played» без канонических verbs и extensions не совпадут ни с одним стандартным отчётом или сторонним инструментом. Используйте профиль с первого дня, даже если отправляете лишь часть утверждений.

Второй – путать позицию воспроизведения с progress. Отправлять completed, потому что позиция дошла до конца, не суммируя played-segments, – значит засчитывать завершение тем, кто просто перемотал. Всегда считайте охват и сверяйте его с порогом завершения.

Третий – небрежная работа с registration. Если у утверждений одной попытки нет общей registration, LRS не сможет агрегировать progress, played-segments и completion, и цифры незаметно окажутся неверными. Определитесь с registration до того, как начнёте что-либо отправлять.

Четвёртый – повторно используемые или нестабильные activity ID. У каждого видео должен быть один постоянный ID в вашем домене. Новые ID при каждой загрузке или один ID на несколько видео портят все будущие отчёты.

Пятый – приватность по остаточному принципу. Утверждения Video Profile содержат идентификатор учащегося (часто email) и подробный след поведения: когда смотрел, где ставил паузу, когда ушёл. Это персональные данные по 152-ФЗ, и из этого следуют три инженерных решения. Первое – где стоит LRS: с 1 июля 2025 года обрабатывать ПДн граждан РФ с использованием баз данных за рубежом нельзя (ч. 5 ст. 18), так что зарубежный облачный LRS для российской аудитории не подходит. Второе – согласие: с 1 сентября 2025 года его оформляют отдельно от других документов (ч. 1 ст. 9), а за несовершеннолетнего его даёт законный представитель. Третье – идентификатор: в actor лучше передавать внутренний ID из LMS (объект account), а не email и тем более не СНИЛС или другие данные из ЕСИА. Это снижает риск при утечке, но не выводит данные из-под действия 152-ФЗ, пока связь с человеком можно восстановить. Решите, что собираете, зачем и на какой срок, до первого утверждения. Это инженерные рекомендации, а не юридическая консультация.

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

Фора Софт с 2005 года разрабатывает ПО для видеообучения, стриминга, видеоконференций и интерактивных плееров; за это время выпущено 250+ проектов. В обучающих продуктах мы помогаем командам с тем же выбором: оставить обёртку SCORM, если курс должен работать в существующей LMS клиента, и добавить под ней xAPI Video Profile, если продукту нужны посекундная аналитика видео, честное завершение или доказательство того, что видео действительно посмотрели. Обычно мы делаем собственный слой видео и интерактива, который отправляет корректные утверждения Video Profile в LRS в российском контуре: именно здесь чаще всего решается, что разрабатывать, а что покупать. Слой трекинга мы проектируем под нагрузку в продакшене, а не под демо.

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

• xAPI Video Profile (v1.0.3) – стандартный способ отслеживать обучающее видео.
• Семь verbs (initialized, played, paused, seeked, interacted, completed, terminated) описывают действия в плеере.
• Поля result time, progress и played-segments содержат подробности для аналитики.
• Progress – уникальный охват, а не позиция воспроизведения; сверяйте его с порогом завершения.
• Одна registration на попытку связывает сессию; без неё агрегаты неверны.
• Копируйте канонические URI verbs и extensions без изменений: опечатка создаёт несовместимый диалект.
• Утверждения – персональные данные по 152-ФЗ: LRS – в России, в actor – внутренний ID, а не email.

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

• xAPI (Tin Can): утверждения, LRS и что изменилось
• cmi5: мост между SCORM и xAPI
• Создание конвейера аналитики обучения