xAPI gives us incredible visibility into learning — from LMS modules to simulations, mobile apps and beyond.
But with that visibility often comes personally identifiable data (PII).
If you’re capturing xAPI statements, you need to ask yourself:
Are we protecting our learners’ privacy while collecting meaningful data?
What Counts as PII in xAPI?
PII is any information that can directly or indirectly identify an individual.
In xAPI, it’s usually in the actor field. Common examples:
- Name (e.g.
"name": "Julian Davis") - Email address (
"mbox": "mailto:julian@example.com") - Employee IDs or student numbers
- Any custom extensions that store personal details
These fields make your statements meaningful for reporting — but they also make them sensitive.
Why Does PII Matter in xAPI?
Under privacy frameworks like:
- Australian Privacy Principles (APPs),
- GDPR (EU),
- and similar global regulations,
you are responsible for:
- Only collecting what you need,
- Storing it securely,
- Limiting access, and
- Being transparent with learners.
If your Learning Record Store (LRS) or data pipelines leak PII, you could be in breach of these laws and erode learner trust amongst other issues.
How to Manage PII in xAPI (Practical Steps)
Here are proven, doable strategies used in real xAPI ecosystems:
1. Minimise the Data You Send
Ask: Do I really need a name or email in this statement?
For analytics, a unique non‑identifiable ID is often enough.
2. Use Pseudonyms or Hashed IDs
Instead of sending an email address, send a consistent pseudonym or a one‑way hashed identifier.
Example:
"actor": {
"name": "Learner_12345",
"account": {
"homePage": "https://your-org.com",
"name": "d9c8f6e21b" // hashed ID
}
}
✅ Your internal system keeps the lookup table.
✅ Your LRS never stores raw PII.
3. Secure Your LRS
- Use HTTPS for all data transmission (LRS should reject a statement if not server over https).
- Enable authentication and API keys.
- Apply role‑based permissions (only certain users can see raw data).
- Audit access regularly.
4. Plan for Data Retention & Anonymisation
xAPI statements are immutable — once stored in an LRS, they can’t be changed or updated. The only built-in mechanism is voiding, which marks a statement as invalid but doesn’t remove it from the record.
If you need to manage PII in older records, here are your options:
- Voiding: Use statement voiding to flag data as no longer valid, while keeping a full audit trail.
- Retention Policies: Many enterprise LRSs support retention rules that can delete or purge statements after a set timeframe.
- Anonymisation Scripts: Some LRSs may allow you to run scheduled jobs to strip or replace PII fields (such as names or emails) once the data is no longer needed for reporting.
Align these practices with your legal and organisational compliance obligations (e.g. GDPR, APPs, or internal data governance policies).
Real‑World Example
Without PII management:
Your Moodle plugin sends actor.mbox: julian@example.com to your LRS.
With PII management:
A middleware or plugin setting replaces it with actor.account.name: 82d9f2c93e (hashed ID).
You still see activity trends and completions, but no personal email leaves Moodle.
Helpful Resources on PII and Privacy
Here are some trusted references you can link in your article or blog:
- OAIC – Australian Privacy Principles (APPs)
- GDPR – EU General Data Protection Regulation overview
- ADL xAPI Spec – Actor and Authority fields
- xAPI.com.au articles on data handling
Final Thoughts
xAPI unlocks powerful insights, but with great data comes great responsibility.
By minimising PII, pseudonymising actors, and securing your LRS, you can stay compliant while still getting the analytics you need.
💬 How are you managing PII in your xAPI ecosystem?
Share your thoughts — let’s help each other build privacy‑ready learning environments.
Need help implementing these practices?
Reach out at xapi.com.au — happy to help you design an xAPI setup that’s both powerful and privacy‑safe. 🚀
Written in collaboration with AI