xAPI (Tin Can): утверждения, LRS и что изменилось

Кратко

xAPI (Experience API, раньше известный как Tin Can API) – стандарт обучения, который фиксирует, что сделал человек, причём где угодно, а не только внутри плеера курса. Записи имеют вид коротких «предложений данных» – утверждений (statements) в форме «субъект – действие – объект» («Мария завершила модуль 3») и сохраняются в специальное хранилище – Learning Record Store (LRS). Более старый SCORM отслеживает лишь фиксированный набор полей внутри сессии, запущенной из LMS. xAPI фиксирует любые события: на мобильных устройствах, в симуляциях, офлайн и в видео по секундам. В октябре 2023 года он утверждён как стандарт IEEE 9274.1.1-2023. Применяйте xAPI, когда нужны подробные данные о просмотре видео и взаимодействиях или об обучении вне LMS. Цена этой свободы – проектирование утверждений и LRS, который придётся развернуть самим или купить (для данных российских учащихся – на серверах в РФ).

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

Если вы строите или покупаете обучающий продукт и вам мало знать, «дошёл ли слушатель до конца курса», вам понадобится xAPI. Он показывает не только то, что слушатель посмотрел 20-минутную лекцию, но и то, что он пропустил первые пять минут, трижды пересмотрел один фрагмент и ушёл на 19-й минуте. Такая детальность помогает улучшать курсы, даёт реальную аналитику вовлечённости и подтверждение обучения для комплаенса. Статья написана для руководителя L&D, продакт-менеджера или основателя, которому нужно решить, оправдывает ли xAPI дополнительную разработку, и говорить с инженерами, не утопая в спецификации. Точность – до имени поля, но без языка стандартов.

Что такое xAPI

Представьте предложение «Мария завершила модуль 3». В нём есть подлежащее (Мария), действие (завершила) и то, на что направлено действие (модуль 3). Любой читатель точно понимает, что произошло, и ему не нужно знать, каким приложением пользовалась Мария и с какого устройства. Стандарт обучения, который записывает события именно такими предложениями, называется xAPI – сокращение от Experience API.

Ключевое слово здесь – experience (опыт). Более старый стандарт упаковки Sharable Content Object Reference Model (он разобран в статье SCORM: что это и что отслеживает) создавали, чтобы отслеживать курс внутри обучающей системы. xAPI создан, чтобы отслеживать любой учебный опыт, где бы он ни происходил. Слушатель смотрит видео, проходит симуляцию, приходит на очный семинар, читает инструкцию с телефона без связи или отрабатывает сердечно-лёгочную реанимацию на тренажёре. Всё это учебный опыт, и каждый эпизод можно записать предложением xAPI.

Learning management system, или LMS, – платформа, которая размещает курсы, зачисляет слушателей и хранит результаты: Moodle, iSpring Learn, WebTutor, Mirapolis и сотни других. SCORM предполагает, что слушатель работает внутри одной из них, в браузере и с постоянной связью. xAPI от этого допущения отказывается: сначала он фиксирует опыт, а вопрос, где находится LMS, решается потом.

Каждое такое предложение называется statement (утверждение), а утверждения записываются в специальную базу данных – Learning Record Store, или LRS. Её можно представить как блокнот, куда записываются эти предложения. Обе части подробно разберём ниже, а пока достаточно запомнить: утверждения – предложения, LRS – блокнот.

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

От Tin Can к xAPI и стандарту IEEE: что изменилось

В названии путаются почти все, поэтому начнём с него. Этот стандарт встречается под именами Tin Can API, Experience API и xAPI, и их используют так, будто это три разные вещи. Это не так.

Примерно в 2008 году в сообществе e-learning стало ясно, что SCORM устарел, и начались обсуждения, что придёт ему на смену. Инициатива Advanced Distributed Learning (ADL), создавшая SCORM, объявила исследование спецификации следующего поколения. Его вели как открытый диалог с индустрией. Проект получил прозвище Tin Can («консервная банка») – по аналогии с двумя банками, связанными верёвочкой: простой способ системам говорить друг с другом.

Выпущенная спецификация получила официальное имя Experience API, сокращённо xAPI. «Tin Can API» было лишь рабочим прозвищем проекта, но оно прижилось в блогах и на страницах продуктов, поэтому встречается до сих пор. Запомните: xAPI – стандарт, Tin Can – название проекта. Если вендор пишет, что продукт «Tin Can compliant», он имеет в виду xAPI.

Версии важны: заявление о поддержке стандарта без даты быстро устаревает.

• xAPI 1.0.0 вышел в апреле 2013 года – первый публичный релиз.
• xAPI 1.0.3 (2016) – последняя версия, которую сопровождала непосредственно ADL; под неё построено большинство существующих продуктов.
• IEEE 9274.1.1-2023, который часто называют xAPI 2.0, утверждён комитетом IEEE Learning Technology Standards Committee 10 октября 2023 года. Теперь xAPI сопровождает IEEE – та же организация, что отвечает за Wi-Fi (IEEE 802.11). Это был первый случай, когда спецификация с открытым исходным кодом стала опубликованным стандартом IEEE.

На вопрос «что изменилось» есть два ответа. Во-первых, статус: xAPI прошёл путь от исследовательского проекта к спецификации ADL, а затем к стандарту IEEE. Значит, это уже долгоживущая инфраструктура, а не мода. Во-вторых, содержание: версия IEEE 2023 года уточнила спецификацию 1.0.3 (модель данных JSON и веб-сервис RESTful), но не переписала её, поэтому большая часть существующего xAPI-контента продолжает работать. Новый продукт в 2026 году проектируйте под IEEE 9274.1.1-2023, а 1.0.3 считайте унаследованной версией, с которой нужно сохранять совместимость.

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

Анатомия утверждения

Вся сила xAPI – в одном небольшом и легко читаемом объекте. Соберём его по частям: сначала словами, потом в JSON.

В простейшем виде утверждение – это actor, verb, object, то есть «я сделал это». Actor – кто, verb – что сделал, object – с чем. Всё остальное – необязательные детали, которые добавляют по необходимости.

{
  "actor": { "name": "Мария Иванова", "mbox": "mailto:maria@example.com" },
  "verb":  { "id": "http://adlnet.gov/expapi/verbs/completed",
             "display": { "ru-RU": "завершила" } },
  "object": { "id": "https://example.com/courses/module-3",
              "definition": { "name": { "ru-RU": "Модуль 3: пожарная безопасность" } } }
}

Если прочитать объект как фразу, получится: Мария Иванова завершила «Модуль 3: пожарная безопасность». Подписи (display, name) – это языковые карты (language maps): для русскоязычного курса задавайте их с ключом ru-RU и при необходимости добавляйте другие языки. Это всё ядро xAPI. Теперь разберём части.

Actor – кто сделал

Actor – человек (или группа, или система), о котором утверждение. xAPI намеренно ориентирован на человека: слушателя определяет идентификатор, однозначно указывающий на него, чаще всего адрес электронной почты в виде mbox: "mailto:maria@example.com". Марий может быть много, но владелец этого адреса один. Actor можно задать и через учётную запись в конкретной системе (account: адрес системы плюс внутренний ID). Это удобно, когда не хочется передавать почту, и заодно сокращает объём персональных данных в каждом утверждении. Замысел в том, чтобы история обучения следовала за человеком из системы в систему, а не оставалась запертой в таблице пользователей одной платформы.

Verb – что сделал

Verb – действие, и здесь новички часто спотыкаются: verb задаётся не словом, а URI (веб-адресом, однозначно задающим смысл) в паре с человекочитаемой подписью. Так, «completed» технически – это http://adlnet.gov/expapi/verbs/completed с подписью вроде «завершил(а)». Если две системы используют один и тот же адрес, они одинаково понимают «completed», и «done» одной системы не разойдётся молча с «finished» другой. ADL публикует базовый набор verbs – experienced, attended, attempted, completed, passed, failed, answered, interacted и другие; прежде чем придумывать свои, стоит поискать подходящий среди них.

Object – с чем

Object обычно – это activity: курс, модуль, видео, вопрос. Как и verb, каждую activity однозначно определяет URI, которым владеете вы, плюс необязательные имя и описание. Правило, которое избавит от проблем в будущем: никогда не используйте один ID activity для двух разных вещей и создавайте ID только в своём домене. Небрежные ID – самая частая причина, по которой отчёты xAPI превращаются в кашу.

Result – чем закончилось

Когда у опыта есть итог, к утверждению добавляют result. Здесь хранятся баллы, зачёт/незачёт и время:

"result": {
  "completion": true,
  "success": true,
  "score": { "scaled": 0.95 },
  "duration": "PT24M11S"
}

Этот фрагмент означает, что Мария закончила (completion: true), сдала (success: true), набрала 95% (score.scaled идёт от −1 до 1, так что 0.95 – это 95%) и потратила 24 минуты 11 секунд (duration в формате времени ISO 8601). Обратите внимание: «дошёл ли до конца» и «сдал ли» в xAPI – два отдельных поля. SCORM 1.2 не мог однозначно выразить это различие.

Context – обстоятельства

Наконец, context описывает обстоятельства: кто был преподавателем, к какому большому курсу относится эта activity, платформу, язык, регистрацию (одну попытку прохождения). Благодаря context потом можно спросить у LRS: «покажи все утверждения по записи Марии на курс пожарной безопасности, который вела Ирина». У утверждений есть также timestamp (когда событие произошло) и время stored, которое LRS проставляет при сохранении.

Ещё одно важное свойство: утверждения неизменяемы. Записанное в LRS утверждение нельзя отредактировать или удалить. Если его нужно отменить – скажем, оно отправлено по ошибке, – отправляют новое утверждение, которое аннулирует (voids) старое. Режим «только добавление» выбран намеренно: записи об обучении, которую можно незаметно переписать, никто не станет доверять.

Learning Record Store: блокнот

Само по себе утверждение – лишь фраза, повисшая в воздухе. Его нужно где-то сохранить, чтобы потом запрашивать и передавать дальше. Для этого существует Learning Record Store (LRS) – вторая половина xAPI и та часть, которую команды чаще всего недооценивают.

LRS – специализированное хранилище данных, главная особенность которого – простой веб-интерфейс по стандарту xAPI (RESTful API). Любое авторизованное приложение может отправить в него утверждение HTTP-запросом, а любой авторизованный инструмент отчётности – запросить утверждения обратно: «дай всё, что Мария сделала в этом месяце», «дай все утверждения completed по модулю 3». Это и блокнот для всех предложений xAPI, и источник данных для любого отчёта.

Архитектуру во многом определяют три свойства LRS.

Во-первых, LRS может быть отдельной системой или частью LMS. Некоторые LMS поставляются со встроенным LRS, многие – нет, и тогда добавляют отдельный. В Moodle xAPI подключается сторонними плагинами: например, logstore xAPI пересылает события Moodle во внешний LRS [7]. В российских корпоративных LMS наличие xAPI и LRS нужно уточнять у вендора. Видеопродукт, который вовсе не LMS, тоже может отправлять утверждения в собственный LRS. LRS – компонент, а не категория продукта.

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

В-третьих, LRS придётся эксплуатировать. Отправлять утверждения дёшево, а вот надёжно хранить миллионы записей, защищать их и быстро выполнять запросы – серьёзная инженерная задача. К ней мы вернёмся в разделе «строить или купить».

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

Четыре свободы: почему xAPI отслеживает там, где SCORM не может

Преимущества xAPI традиционно описывают как четыре «свободы». Такая подача удобна и нетехническому читателю: за каждой свободой стоит конкретная возможность продукта.

Свобода утверждения. Утверждение – это actor-verb-object плюс необязательные детали, поэтому записать можно почти всё, что делает слушатель, а не только «курс пройден». Посмотрел, поставил на паузу, ответил, добавил в закладки, попробовал, отработал в симуляции, подписал: если действие можно сформулировать как «я сделал это», xAPI его сохранит.

Свобода устройства. Утверждения может отправлять любое устройство с поддержкой xAPI: телефон, VR-шлем, серьёзная игра, станок на заводе. Главное – постоянная связь не нужна. Устройство может копить утверждения офлайн и отправить их, когда связь появится. SCORM так не умеет.

Свобода сценария. Обучение не обязано начинаться или заканчиваться в LMS. Слушатель может начать на публичном сайте, продолжить в мобильном приложении и закончить на очном семинаре, и весь путь попадёт в LRS. Контент больше не привязан к запуску из одной платформы.

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

Поэтому продукты, построенные вокруг видео или мобильного обучения, выбирают xAPI: это единственный массовый стандарт, изначально рассчитанный на трекинг обучения за пределами сессии LMS.

xAPI и SCORM: сравнение

Именно это сравнение больше всего нужно командам, и важно провести его правильно. SCORM и xAPI – не конкурирующие версии одного стандарта: за ними стоят противоположные компромиссы. SCORM даёт универсальную поддержку в LMS ценой фиксированной и скромной модели данных. xAPI даёт подробный трекинг где угодно ценой дополнительного проектирования и LRS, который нужно поддерживать.

SCORM по-прежнему разумный выбор по умолчанию, когда задача звучит как «курс должен загрузиться и передать результаты в имеющуюся LMS клиента уже сегодня». xAPI нужен, когда вопрос смещается к «что именно сделал слушатель, на любом устройстве, и как это доказать». Многие реальные продукты используют оба: SCORM-обёртку для совместимости с LMS и xAPI внутри для подробных данных. Полную картину из четырёх стандартов, включая два связующих, смотрите в статье SCORM, xAPI, cmi5 и LTI: какой стандарт и когда выбрать.

Отдельно о распространённом заблуждении: во многих статьях пишут, что xAPI «заменил SCORM». Это не так. SCORM остаётся самым широко поддерживаемым форматом, потому что его импортирует почти каждая LMS. xAPI добавил возможности, которых у SCORM никогда не было, но не вытеснил его. Стандарты дополняют друг друга, и выбирать между ними стоит по потребностям в данных, а не по дате выхода.

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

Трекинг видео в xAPI: Video Profile

Для продукта видеообучения самое ценное в xAPI – детальный трекинг видео. Для него есть опубликованная готовая схема – xAPI Video Profile.

Профиль – согласованный сообществом набор verbs, типов activity и extensions для конкретной области: все, кто отслеживает один и тот же вид опыта, пользуются одним словарём. Без профиля ваше утверждение «видео played» и «видео play» другого вендора не сошлись бы в отчёте. xAPI Video Profile (v1.0.3; профиль создан сообществом и опубликован в репозитории профилей ADL) задаёт стандартный способ описания видео.

Базовые verbs профиля напрямую соответствуют событиям плеера:

• initialized – видео готово к воспроизведению.
• played – слушатель нажал воспроизведение (утверждение фиксирует позицию по времени).
• paused – слушатель поставил на паузу (фиксирует, где именно).
• seeked – слушатель перемотал вперёд или назад (фиксирует время «откуда» и «куда»).
• completed – слушатель просмотрел всё видео хотя бы один раз.
• terminated – слушатель закрыл видео.

Детализацию дают result extensions – дополнительные поля со своими URI (под https://w3id.org/xapi/video/extensions/...), в которых передаются числа, действительно полезные для анализа:

• time – точная секунда видео, на которой произошло событие.
• progress – доля просмотренного видео в виде десятичной дроби (0.06 = 6%).
• played-segments – точные диапазоны, которые посмотрел слушатель, например 0[.]54.321[,]60[.]...; по ним видны пропуски и пересмотры.

Вот утверждение «пауза на 54,3-й секунде», сокращённое для наглядности:

{
  "actor": { "name": "Мария Иванова", "mbox": "mailto:maria@example.com" },
  "verb":  { "id": "https://w3id.org/xapi/video/verbs/paused",
             "display": { "ru-RU": "поставила на паузу" } },
  "object": { "id": "https://example.com/videos/fire-safety-intro",
              "definition": { "type": "https://w3id.org/xapi/video/activity-type/video",
                              "name": { "ru-RU": "Пожарная безопасность: введение" } } },
  "result": {
    "extensions": {
      "https://w3id.org/xapi/video/extensions/time": 54.3,
      "https://w3id.org/xapi/video/extensions/progress": 0.06
    }
  }
}

Профиль стандартизирует эти поля: утверждение completed обязано содержать общее время просмотра, а значения progress и played-segments агрегируются по всем попыткам слушателя в одной регистрации. Так из сырых событий play/pause получается настоящая тепловая карта вовлечённости. Подробно эта спецификация разобрана в статье трекинг видео через xAPI Video Profile; интерактивные элементы, которые порождают эти утверждения, – в статье квизы и опросы в плеере, а аналитика, которая их использует, – в статье аналитика обучения.

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

Пример: трекинг одной 20-минутной лекции

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

В SCORM видео оборачивают в отслеживаемую единицу, и когда слушатель досматривает до конца, записывается одно поле: completion_status = completed. LMS знает только одно: закончил слушатель или нет. Для SCORM это естественная единица учёта.

В xAPI с Video Profile те же 20 минут порождают поток утверждений. Допустим, Мария смотрит минуты 0–5, перескакивает на 18-ю минуту, дважды пересматривает 12-ю и останавливается на 19-й. Плеер отправит примерно следующее:

initialized              → 1 утверждение
played / paused / seeked → ~8 утверждений (старт, перескок, пересмотры, остановки)
completed (или нет)      → 1 утверждение, с duration + played-segments

Посчитаем вовлечённость. 20-минутное видео – это 1 200 секунд. played-segments Марии покрывают 0–300 с, 720–780 с (пересмотренная 12-я минута, для покрытия считается один раз) и 1 080–1 140 с, итого 300 + 60 + 60 = 420 секунд уникального материала.

Покрытие = уникальные секунды ÷ общая длина
         = 420 ÷ 1200
         = 0,35  → реально увидено 35% видео

SCORM записал бы «completed», если плеер отметил видео как пройденное. xAPI же показывает, что Мария увидела лишь 35% материала, а один фрагмент пересмотрела. Для преподавателя, который решает, работает ли лекция, это совсем другая картина. Разрыв между «отмечено как пройденное» и «реально просмотрено» – главная причина, по которой продукты видеообучения переходят на xAPI.

У такой детальности есть цена: около десяти утверждений на слушателя на каждое видео быстро накапливаются. Десять тысяч слушателей одного видео дают 100 000 утверждений, курс из 50 видео – миллионы. LRS, который их хранит и обслуживает запросы, – полноценная инфраструктура. Отсюда и вопрос «строить или купить».

Частые ошибки, на которые уходит время

Несколько ошибок с xAPI повторяются почти в каждом проекте. Их дёшево предотвратить и дорого исправлять задним числом.

Первая – воспринимать xAPI как прямую замену SCORM. Сами по себе xAPI-утверждения не задают цикл «запуск и отчёт» из LMS. Если контент должен назначаться и оцениваться внутри LMS, чистый xAPI не описывает, как курс и LMS об этом договариваются. Этот пробел закрывает cmi5: он встраивает xAPI в модель запуска из LMS. См. cmi5: мост между SCORM и xAPI.

Вторая – небрежные ID для verb и activity. Собственный verb там, где у ADL уже есть подходящий, или один ID activity на два разных видео незаметно портят все будущие отчёты. Используйте опубликованные verbs и создавайте уникальные ID в своём домене.

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

Четвёртая – трекинг видео без Video Profile. Самодельные утверждения «played», не следующие профилю, не сойдутся ни с одним стандартным отчётом или сторонним инструментом. Используйте профиль с первого дня.

Пятая – приватность «на потом». xAPI-утверждения часто содержат персональные идентификаторы (email в mbox) и подробный поведенческий след, а по 152-ФЗ это персональные данные. Если обработка идёт по согласию, с 1 сентября 2025 года согласие оформляется отдельно от других документов (ч. 1 ст. 9) [8], а за несовершеннолетних его по общим правилам дают законные представители. Операции с ПДн граждан РФ в базах данных за рубежом не допускаются (ч. 5 ст. 18) [9], поэтому зарубежный облачный LRS для российских учащихся не подходит. Решите, что вы собираете, зачем и как долго храните, до того как начнёте отправлять утверждения.

Строить или купить: держать ли свой LRS?

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

Отправка утверждений из вашего плеера или приложения – меньшая часть. Для большинства языков программирования есть зрелые клиентские библиотеки, а добавить xAPI-трекинг в видеоплеер – задача ограниченного объёма. Обычно её решают своими силами, потому что структура утверждений зависит от конкретного продукта.

Эксплуатация LRS – бóльшая часть, и над ней стоит подумать дольше всего. LRS, соответствующий стандарту, должен принимать утверждения через REST-интерфейс xAPI, хранить их неизменяемыми, обеспечивать аутентификацию и быстро отвечать на запросы, когда хранилище вырастет до миллионов утверждений. Строить его с нуля редко оправдано. Большинство команд берут проверенный LRS – коммерческий или open-source – и вкладывают силы в утверждения и отчётность, где и находится ценность продукта. Для российской аудитории это обычно собственное развёртывание (self-hosted) на своих серверах или в российском облаке: тогда требование о размещении баз данных в РФ выполняется на вашей же инфраструктуре. Для экспериментов хорошо подходит открытый LRS от ADL (лицензия Apache 2.0, обновлён под IEEE 9274.1.1), но сами авторы называют его стабильным прототипом (proof of concept) для небольшого числа пользователей [10]. Для продакшена с миллионами утверждений нужен LRS, рассчитанный на такую нагрузку. Писать LRS самим стоит, только если LRS и есть ваш продукт. В общем виде это решение разобрано в статье строить, купить или расширить готовую LMS.

Шаги по проектированию утверждений и подготовке LRS мы свели в одностраничный чек-лист, по которому можно проверить любое xAPI-решение: скачайте чек-лист готовности xAPI-утверждений и LRS.

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

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

Главное

• xAPI записывает обучение в виде утверждений «actor, verb, object» – «Мария завершила модуль 3».
• Утверждения хранятся в Learning Record Store (LRS); Tin Can – лишь название проекта.
• В отличие от SCORM, xAPI отслеживает обучение везде: в мобильных приложениях, офлайн, в VR и в видео по секундам.
• В октябре 2023 года xAPI стал стандартом IEEE 9274.1.1-2023; новые продукты стоит строить под эту версию.
• xAPI Video Profile – стандартная схема детального трекинга видео.
• Основная инженерная работа – LRS: если он не ваш продукт, возьмите проверенный и разместите его в РФ.

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

• SCORM: что это, что отслеживает и когда применять
• cmi5: мост между SCORM и xAPI
• Трекинг видео через xAPI: Video Profile и что отслеживать