xAPI vs SCORM: what freelancers actually need to know

SCORM still wins for packaged modules

LMS admins know how to ingest SCORM. Completion and score reporting are well understood. For most corporate gigs, SCORM 1.2 or 2004 packages remain the default currency.

SCORM 1.2 is the safest bet when you do not know the client's LMS. It works on Cornerstone, Docebo, Moodle, Absorb, TalentLMS, and practically every other platform released in the last 15 years. The trade-off is limited data: you get completion status, a single score, and basic bookmarking. For most compliance, awareness, and onboarding courses, that is enough. If the client asks "will it track completion?" and you say "yes, SCORM 1.2 with a quiz pass gate," the conversation moves to design instead of infrastructure—and that is where you want it.

SCORM 2004 adds sequencing rules, multiple SCOs with navigation control, and richer status reporting (passed, failed, completed, incomplete as separate fields). Use it when the course structure demands enforced paths—like a certification program where Module 2 unlocks only after Module 1 passes—or when the client needs to distinguish between "completed" and "passed" in their LMS reports. Storyline 360 and Captivate both export SCORM 2004 3rd and 4th Edition; confirm which edition the client's LMS supports before you publish, because mismatches cause silent failures in sequencing.

The practical packaging workflow is the same for both versions: export from your authoring tool, unzip to verify imsmanifest.xml and asset paths, test in a local SCORM player like SCORM Cloud or Rustici's test environment, then hand the ZIP to the LMS admin with a one-page README noting completion criteria, minimum browser versions, and any known quirks. Keep a copy of the published package with a version label—Client_Module_v1.3_SCORM12.zip—so you can roll back without re-publishing from source if something breaks after an LMS update.

When a client asks "should we use SCORM or something newer?" answer based on their reality, not industry hype. If their LMS is Cornerstone and their IT team has a 90-day change-request queue, SCORM is the right answer because it ships without new infrastructure. If their L&D team is already piloting an LRS and wants to track simulations across mobile and desktop, then the conversation shifts to xAPI—but only after you confirm they have the budget and the governance to maintain it. Do not upsell xAPI when SCORM solves the problem; you lose trust when the recommendation serves your resume more than their timeline.

xAPI when experience data matters

If stakeholders want richer analytics—branching paths, simulations, performance support across tools—xAPI statements can tell a fuller story. You will need LRS alignment and governance.

xAPI shines when you need to track learning that happens outside a traditional SCORM module. If your program includes a mobile job aid, a VR simulation in Unity, a video series, and an in-person workshop, xAPI can stitch those experiences into a single learner record. Each component sends statements—"learner attempted scenario," "learner completed video," "learner attended workshop"—to a Learning Record Store like Learning Locker, Watershed, or Yet Analytics. The LRS becomes the single source of truth, and you build dashboards or reports from there.

The governance question is real: who defines the statement vocabulary, who maintains the LRS, who owns the data, and who builds the reports? If you are a freelancer proposing xAPI, you need to answer those questions in the SOW or the client will assume you handle all of it forever. A clean split looks like this: you define the statement structure and instrument the authoring-tool side; the client's IT team provisions and maintains the LRS; a data analyst or BI developer builds the dashboards. If the client does not have an IT team willing to own the LRS, xAPI is a hard sell—you will end up as unpaid infrastructure support.

Start small with xAPI: instrument one module with custom statements that track decision points in a branching scenario. Use a profile like cmi5 if the client's LMS supports it—cmi5 is essentially xAPI with SCORM-like launch and completion semantics, so it feels familiar to LMS admins while giving you richer data under the hood. Storyline 360 supports cmi5 export natively; for custom xAPI beyond cmi5, you will need JavaScript triggers that send statements via the xAPI wrapper library.

Price xAPI work separately from SCORM packaging. A SCORM module might take you 60 hours to build; adding xAPI instrumentation with custom statements, LRS configuration, and a basic reporting dashboard can add another 20–40 hours depending on complexity. If you bundle those hours into a single flat fee, the client never sees the value of the data layer and will not budget for it on the next project. Itemize it: "xAPI instrumentation and LRS setup: $X. Reporting dashboard build: $Y. Ongoing LRS maintenance is the client's responsibility after handoff." That transparency builds trust and sets expectations for the next engagement.

What to say in proposals

Translate standards into risk: "SCORM package with completion tracking" vs "xAPI instrumentation for multi-device practice." Clients care about maintenance and who owns the data.

In your proposal, describe SCORM and xAPI in terms the client already understands. For SCORM: "We deliver a packaged module that your LMS imports like any other course. It tracks who completed the training and who passed the assessment. Your LMS admin handles upload; no new infrastructure required." For xAPI: "We instrument the learning experience to capture detailed interaction data—which decisions learners made, where they struggled, how long they spent on practice activities—and send that data to a dedicated analytics platform. This requires an LRS, which your IT team provisions and maintains."

Frame the choice as a trade-off between simplicity and insight. SCORM gives you binary signals: done or not done, passed or failed. xAPI gives you behavioral signals: which path they chose, which resources they accessed, which practice scenarios they repeated. If the client's primary need is "prove everyone completed the training for the audit," SCORM is the right tool. If the need is "understand where new hires struggle so we can improve the program," xAPI earns its complexity. Write that trade-off explicitly in your proposal so the client makes an informed decision rather than defaulting to whatever sounds more modern.

Address maintenance in the proposal. SCORM packages are relatively low-maintenance: if the content does not change and the LMS does not upgrade, the package keeps working. xAPI has ongoing costs: LRS hosting fees, statement storage that grows over time, dashboard maintenance when reporting needs change, and someone who understands the data model when stakeholders ask new questions. If you do not mention these costs upfront, the client discovers them six months later and blames you for the surprise.

Include a recommendation, not just options. After describing both standards, write one paragraph that says: "Based on your current LMS environment, team capacity, and reporting needs, I recommend [SCORM/xAPI] for this project because [specific reason]." Clients hire you for judgment, not just execution. If you present two options without a recommendation, you are asking them to make a technical decision they are not equipped to make—and they may choose the wrong one. Your recommendation, backed by your portfolio proof of similar projects, is what justifies your rate.

Portfolio presentation

Host SCORM for interactivity. Summarize xAPI designs with architecture sketches if you cannot expose data. Clarity beats acronym density.

For SCORM projects, host the package on TrainingOS so reviewers can click through the actual learning experience. A playable demo is the strongest proof you can offer—it shows completion behavior, navigation logic, assessment flow, and responsive layout in one artifact. Label the demo with the SCORM version and the authoring tool: "Branching compliance scenario—Storyline 360, SCORM 2004 4th Edition." That label tells technical reviewers you made deliberate packaging choices.

For xAPI projects, you usually cannot share the live data, but you can share the design. Create a one-page architecture diagram showing the flow: authoring tool sends statements to LRS, LRS stores data, reporting tool visualizes patterns. Annotate it with the specific verbs and objects you defined: "attempted," "completed," "scored," plus custom extensions like "selected-path" or "time-on-decision." That diagram proves you understand the pipeline even when the data itself is confidential. Export it as a clean PNG or SVG and attach it to your case study.

Write the xAPI section of your case study in plain language first: "We tracked which escalation path each learner chose, how long they spent weighing options, and whether they self-corrected before submitting. That data showed us that 68 percent of learners initially chose the wrong escalation tier, which led us to add a decision-support job aid in v2." Then add the technical layer: "Statements used the ADL vocabulary with custom extensions for path selection and dwell time; data flowed to Learning Locker and was visualized in a Tableau dashboard shared with the Ops team." Both layers serve different readers.

If you have both SCORM and xAPI projects in your portfolio, group them intentionally. Put SCORM projects first—they are the bread and butter that most clients need—and position xAPI projects as evidence that you can level up when the business case demands it. A reviewer who sees three strong SCORM case studies followed by one thoughtful xAPI case study thinks "this person ships reliably and can go deeper when needed." That ordering serves you better than leading with xAPI and making SCORM look like an afterthought.

SCORM still wins for packaged modules

xAPI when experience data matters

What to say in proposals

Portfolio presentation

Related articles