xAPI Tracking

Overview

Creator can report learner activity as xAPI (Experience API / Tin Can) statements to any standards-compliant Learning Record Store (LRS). Every relevant interaction — answering a question, finishing a game, passing a quiz, completing a lesson or the whole course — becomes a statement like "Alex answered Question 3 (correct)".

xAPI tracking is available in three delivery modes:

ModePackageHow the LRS is reached
SCORM + xAPILMS (SCORM) export with the Register xAPI events toggle onLRS endpoint and credentials embedded at export time; the package keeps reporting SCORM to the LMS as usual
Web + TinCan launchWeb export with xAPI enabledEndpoint, credentials and actor arrive as query parameters in the launch URL (TinCan/Rustici style); embedded values are the fallback
xAPI packageThe dedicated xAPI (Tin Can) export formatShips a tincan.xml manifest so LRS-backed platforms (e.g. SCORM Cloud) can import and launch it; launch parameters take priority over embedded values

What gets reported

Statements are generated from per-brick templates, with sensible defaults by category:

  • Evaluation bricks (single choice, match, fill in the blank…) — answered with the result (correct/incorrect). On by default.
  • Casual games (wordle, memory, hangman…) — attempted on first interaction, completed with the outcome. On by default.
  • Media (video, audio) and interactive collections (accordion, tabs, carousels…) — experienced / interacted. Off by default — enable them per brick where the signal matters.
  • Structure — always reported while xAPI is active: course initialized / completed / terminated, lesson completed, and quiz passed / failed with the score from the quiz engine.

Per-brick customization

Open a brick's edit panel and find the xAPI tracking section (available on evaluation, game, media and collection bricks):

  • Report statements — Default (category), Enabled, or Disabled for this brick.
  • Verb — pick from the standard ADL verb list, or choose Custom verb… to provide your own verb IRI and display name (for organizations with their own xAPI profile).
  • Activity name — the human-readable name shown in LRS reports (defaults to the brick type).

Previewing statements

The editor's Preview runs the full xAPI engine against a built-in mock LRS. Open the xAPI statements panel in the preview and interact with the content: every statement the exported package would send appears live — no LRS or network required.

Activity IRIs

Statements identify what was acted on with hierarchical IRIs frozen into the package at export time:

{app-url}/xapi/content/{contentId}                     ← course
{app-url}/xapi/content/{contentId}/lesson/{lessonId}   ← lesson
{app-url}/xapi/content/{contentId}/lesson/{id}/brick/{brickId}

Bricks reference their lesson and course via contextActivities, so LRS dashboards can group activity per lesson and course. These IRIs are a stable contract: re-exporting the same content keeps the same IRIs, and LRS reporting stays continuous across versions.

LRS credentials

When you embed an LRS endpoint and credentials at export time, they are written into the package (content.json) and are readable by anyone who can open the zip — this is inherent to client-side xAPI packages, and the standard practice of every major authoring tool. Protect yourself by:

  • Using write-only LRS credentials (statements in, no reads).
  • Preferring the TinCan launch mode where the hosting platform injects short-lived credentials per learner.

Learner identity

The actor in each statement is resolved in priority order:

  1. The actor from the TinCan launch URL (provided by the hosting platform).
  2. The SCORM learner id from the LMS session (SCORM + xAPI mode), reported as an account identifier.
  3. A persisted anonymous id unique per browser — used when a web package is opened directly.
xAPI Tracking