Data Deletion Policy
What deletion removes, what is retained and why, how long it takes — and the one case where we cannot help you, stated plainly rather than papered over.
This document exists because deletion is a store requirement with a public URL attached, not only a GDPR right. Apple requires apps supporting account creation to offer account deletion from inside the app; Google Play's Data Safety declaration requires a route to request deletion and asks whether data is deleted on request, and the answer given in that form has to match what the app actually does. Play's review reads the URL. A policy that overstates deletion is a false Data Safety declaration, which is an app-removal risk and not merely a compliance one.
1. The routes
| Route | Who it is for | Requirement it satisfies |
|---|---|---|
| In-app: Settings → Delete everything | Anyone using the app, account or not | Apple's in-app account-deletion requirement; the suite's own self-serve, unconditional commitment |
| This public page | Anyone, including someone who has already uninstalled | Play's data-deletion declaration; the store-required deletion URL |
| Email to the named inbox | Anyone who prefers to write, and the only route for a request needing manual handling | Art. 17 GDPR; DPDP grievance route |
Three properties are non-negotiable and are commitments already made elsewhere in this suite:
- Unconditional. No reason required, no retention flow, no "are you sure you don't want to just pause".
- Never gated on billing state. A lapsed or non-paying user deletes exactly as easily as a subscriber.
- Never routed through support. Deletion that requires contacting a human is the same anti-pattern as cancellation that requires contacting a human, and the monetization standard forbids that one by name.
2. What deletion removes
On confirmation, and covering both the account and any anonymous session on the device:
| Category | Apps | Note |
|---|---|---|
| Profile and account record | All | Including the auth identity itself |
| Birth date, birth time, birth place | Vedic, European | Including derived coordinates and the resolved historical timezone |
| Age band, country of residence | All | See section 3 for the one age-gate artefact that survives |
| Check-in history, streaks, levels, points | All | Progression is gone. Say this before confirming — it is the thing users regret |
| Journal entries and mood fields | Crystal | Including their separate consent records |
| Quiz-derived weights | Crystal | Deleted, not flagged. Raw answers were never stored, so there is nothing else to delete |
| Reading and report content, and its intake | All | The generated artefact and the inputs to it |
| Push tokens, notification preferences | All | Deletion must also deregister the token, or a deleted user keeps getting pushes |
| Anonymous session rows and their contents | Crystal | See section 5 |
Deletion is a purge, not a soft-delete flag. A row marked deleted still contains the birth date. Where an immediate hard delete is impossible — a running backup, an in-flight job — the record is put beyond use and destroyed on the timeline in section 4, and the reason is written down rather than left implicit.
⚠ This list must be generated from the schema, not maintained by hand. It is the same failure mode as the quiz-entrance enumeration: a list written from memory was exhaustive until the next feature landed. A field added later that nobody adds to this table is a field that survives deletion. A test that enumerates persisted personal-data fields and fails if any is unreachable by the delete path is the only version of this list that stays true.
3. What is retained, and why
Stating this is not a loophole — Art. 17(3) permits retention for legal obligations and for legal claims, and a deletion policy claiming everything goes is inaccurate in a way a regulator can check.
| Retained | Why | How long | Contains identity? |
|---|---|---|---|
| Transaction and billing records | German commercial and tax retention duties (§ 257 HGB, § 147 AO) apply to records with accounting relevance | ⚠ Statutory period — counsel to state 6 or 10 years per record type; do not guess | Minimum needed for the record. We never hold card details — Apple and Google are merchant of record |
| Subscription state at RevenueCat and the stores | Held by them, keyed to the store account, not to our user record | Their retention, their terms | Store account, not our profile |
| Age-gate block flag | The anti-retry provision. A gate a user can re-answer is not a mechanism a COPPA posture can rest on | Device-local, cleared by uninstall | No. Non-identifying, device-local, and no date of birth is stored with it |
| Deletion audit record | Evidence the request was honoured, which is the point of being able to demonstrate compliance | ⚠ Counsel to set. Minimal — a request identifier and a timestamp, without the deleted content | — |
| Aggregate counts | Non-identifying totals that cannot be resolved back to a person | Indefinite | No |
| Backups | Operational, rolling, overwritten on a cycle | Section 4 | Until the cycle completes |
Fraud and abuse — stated narrowly on purpose. There is one anti-abuse artefact in this suite and it is the age-gate block flag above. There is no shadow suppression list, no retained identifier for abuse scoring, and no "we may keep data for fraud prevention" clause. That clause is standard boilerplate and it would be false here, and a false retention clause is worse than a narrow true one. If a real anti-fraud need appears later it is added here with its own basis and its own retention — not covered in advance by vague words.
4. Timelines
| Stage | Target | Status |
|---|---|---|
| App reflects deletion | Immediately. The user is signed out and the local store is cleared before the confirmation screen closes | Build commitment |
| Server-side purge | ⚠ [PLACEHOLDER] — stated intent: within 30 days, the Art. 12(3) outer bound. Whether it is same-day, queued nightly or batched depends on the delete implementation, and no database project exists yet | Blocked on provisioning |
| Backup expiry | ⚠ [PLACEHOLDER] — deleted data can persist in backups until the cycle rotates. The window must be stated as a number, not as "a short period" | Blocked on provisioning |
| Processor propagation | ⚠ Each processor's own deletion SLA, from its DPA. No DPA is signed yet | Blocked on provisioning |
| Email request acknowledged | [target] | Blocked on the inbox existing |
| Email request completed | One month (Art. 12(3)), extensible by two further months for complex requests, with the user told why inside the first month | Standard |
Every timeline in this table is currently a placeholder or blocked, and that is the true state. They can only be filled once the backend exists, because a published timeline is a promise about a system, and there is no system yet. Invented numbers are not published here to make the page look finished — an unmet published deletion timeline is a documented breach with a date on it.
5. The anonymous-session gap
Stated plainly, because it is real and it is not fixable by wording.
Crystal deliberately places authentication after the value moment. Until an account is created, the app holds a session with no identity attached to it. That is a good product decision and it produces a genuine, unavoidable limit on data rights:
If you have never created an account, we cannot identify your data as yours.
You can still delete everything from inside the app at any time, and that works completely — the app knows which session is on this device and the server executes the deletion.
But we cannot send you a copy of your data, and we cannot confirm what we hold, because there is no way for us to verify that the data is yours. Anyone could claim any anonymous session. If you lose your device before creating an account, that data is unreachable — by you, and by us on your behalf. It is deleted automatically after a period of inactivity, and until then it sits there identified by nothing.
Why we do not solve this with a device identifier. Authenticating a subject-access request against a device ID would mean anyone holding the device could obtain the data, and it would require creating a durable identifier for a population that currently has none — making the privacy position worse in order to make the rights position look better. It is refused deliberately.
What actually limits the exposure:
- Account creation is forced at the first of: opening the paywall, or a defined tenure. Both are before any money moves and before a trial can start. Nobody can be a paying customer with no identity.
- Anonymous rows with no linked account and no activity are deleted automatically after a set period. No exception, no manual step. ⚠ That period is currently marked as invented and needing a balance pass, and it needs a counsel sanity-check on defensibility, not only a product one.
- In-app deletion is unconditional and works for anonymous users, device-initiated and server-executed.
⚠ Open question 2, carried forward from the privacy policy and unresolved. Whether the disclosed gap is acceptable under Art. 15 and Art. 20, and whether the automatic-deletion period is defensible. The two live options — force account creation at a defined point, or accept and disclose the gap — are both real, and counsel picks. This document does not pick. What it does is refuse to describe the app as offering full data-rights self-service when for part of its population it does not.
Vedic and European do not have this gap in the same shape, because both collect birth data at onboarding into a profile. If either later adds an anonymous-first path, it inherits this section.
6. Deleting your data does not cancel your subscription
This is said on the confirmation screen, in the app, before the user confirms — not only on this page.
Subscriptions are held by Apple or Google against your store account, not against your profile with us. Deleting your data here removes your profile; it does not cancel a subscription, and you can keep being billed by a store for an app whose account you deleted.
- Cancel first, then delete. One tap, in the app, through your platform's native subscription controls.
- If a trial is running, cancelling before it ends means no charge.
- Trials are once per store account, and this does not reset it. Deleting your data and signing up again does not get you a second trial — a platform rule we cannot vary. The deletion confirmation screen is one of the places this has to be said, because "delete and start fresh" is exactly what a user would reasonably assume.
- Refunds are the stores'. See the support policy.
⚠ Deleting the profile while an entitlement is live is a state the build must handle deliberately. Silently revoking a paid entitlement, or leaving a paid non-consumable unrestorable, is a refund driver and a review-rating driver. All three apps sell a one-time non-consumable whose restore path is part of the launch gate. Deletion followed by re-purchase-restore is a scenario that gate must cover, and it is not currently written into it.
7. India — DPDP
⚠ Open question 4, carried forward and unresolved. DPDP 2023 appears to define a child as anyone under 18 and to require verifiable parental consent. If that reading holds, the India storefront moves to 18+, and the erasure and grievance mechanics change with it. The statutory text has not been read by anyone in this process.
What is already committed and stands regardless of that answer: a real purging delete, a published grievance officer with contact details, and a store-required deletion URL live at first release.
8. Contact
Infoash UG (haftungsbeschränkt)
·
[registered address]
·
[data-rights inbox]
Supervisory authority:
[competent Landesdatenschutzbehörde — insert per registered seat]
⚠ The deletion URL is a store-submission blocker: Play's Data Safety form requires it and review reads it. It cannot go live pointing at an inbox that does not exist, and it cannot state timelines for a backend that has not been provisioned.