SquareCat
Miles Corran · 
Every piece of learner data an app stores is something to secure, explain in a privacy policy, declare in an app store form and delete when someone asks. The cheapest data to look after is data you never collected.
This post is about product decisions, not law. It isn’t legal advice, and nothing here says a product complies with any regulation. If your product serves children or schools, specific rules apply, and you should get legal advice early.
Start from what the learning needs
For each thing you plan to store, ask which feature uses it and what the learner gets from it. If the answer is “we might want it later”, leave it out. Adding a field later is a small change. Explaining why you’ve held data for years without using it is harder.
A diagnostic that needs no account and stores nothing
CertBrain, our exam prep app, starts with a free diagnostic quiz that shows which exam domains a learner is strong in and which need work. Asking for an account before someone has seen any value is a lot to ask, so the diagnostic needs no sign-in. Once we’d decided that, we decided it shouldn’t store anything either.
On the web, the browser gets a fixed set of questions, scores the answers itself and shows the results straight away. Nothing about the attempt is saved to our database. The only record is an anonymous analytics event with the per-domain scores, so we can tell whether people find the quiz useful.
We considered saving results so we could email them later. That’s real infrastructure, and a real privacy question, for a feature nobody had asked for, so we left it out. The Android app does the same: it fetches the questions from the server, scores on the phone, and doesn’t send the answers anywhere.
An app that needs no account at all
Some learning apps don’t need a server. The Money Isles Android app has no accounts, no analytics and no ads, and doesn’t connect to the internet. Lessons read, quiz reviews and the daily streak live in a database on the phone.
The trade-off is that the app’s progress stays on that one phone, with no way to carry it to another device except Android’s own backup. Knowing which of your learners need sync, and which would rather not sign up at all, is a useful question to answer before deciding.
When you do store, store only what features use
Most learning products need accounts, and then the question becomes what to keep.
- Keep what a feature reads. Our apps keep a log of answers because progress pages and readiness scores are built from it. We don’t track how long a study session lasts, so nothing shows time spent.
- Show aggregates in public. Braineos public profiles show cards studied, cards mastered and days studied, but no deck list and no per-deck scores. Which decks someone struggles with isn’t something they agreed to share.
- Keep analytics thin. Each of our apps sends two custom events beyond what PostHog captures automatically: a sign-up and a first meaningful action. Each app has its own analytics project, so events never mix.
- Keep products apart. Each product on our platform has its own database and sign-in, so users of one never appear in another.
Plan deletion from the first release
If learners can create an account, they need a way to remove it. Braineos has self-service account deletion, and features built later follow the same rule: saved cards are deleted along with the learner’s account. On Android, Google Play asks for deletion inside the app and on a web page for people who’ve already uninstalled it.
The practical lesson is to decide, for every new table, what happens to its rows when an account goes. It’s a short conversation when the feature is designed and a long one when someone asks two years later.
Write the privacy wording for learners
A privacy policy is read by learners, parents, training managers and app reviewers, not only lawyers. A few habits help:
- Lead with a short version. Money Isles’ policy opens with two sentences saying what the app does and doesn’t do with data, before any detail.
- Say where data lives. On the device, on your server, or with a named third party. Learners understand those three places.
- Describe what the app actually does. Google Play compares its Data safety form with the app’s real behaviour, including bundled SDKs. List every third-party service the app talks to before writing a word.
- Update it when the app changes. A new feature that stores something new means a new paragraph and a new date.
Collecting less makes all of this shorter. A diagnostic that stores nothing needs one sentence. An account system with analytics, AI features and shared profiles needs several sections, and each one is a promise to keep.
If you’re planning a learning product and want to work out what it really needs to store, get in touch and we’ll go through it with you.
