What the SDK sends
Every field, what never leaves the device, and what this portal shows you. This page is the disclosure: the SDK shows no dialog for anonymous telemetry, and asks the learner only before sharing a recording.
Anonymous telemetry, on by default
Sums and histograms per UTC day, at most 32 KB a report, kept on the device for at most 7 days while offline. SDK 2.0.0 sends each day once it is over; from SDK 2.0.1 the SDK sends what was added since its last report several times a day, each report with a random id used only so that a report sent twice is counted once:
| SDK and app | the product (Android, Apple, web, native), platform, SDK version and app version |
|---|---|
| Device, coarse | the model family (for example Pixel 8 or A17), the chip family, the OS major version and a memory tier (under 2, 2 to 4, 4 to 8, 8 to 16, 16 GB or more) |
| Model | the model revision, the context in use, the engine that actually ran (Neural Engine, NPU, CPU) and every fallback with its reason, self-test results, thermal throttling counts |
| Speed | histograms of cold start, model load, latency per chunk and real-time factor |
| Use | sessions, minutes, sessions that ended early, and per surah how many ayat were scored that day (no ayah numbers, no order, no text) |
| Settings | the preset and word level in force, how many mistake types are overridden, which checks were on |
| Results, as sums | per mistake type how many sounds were checked and flagged, words scored and flagged, madd counts, and histograms of confidence, margin and the share of sounds flagged per session |
| Downloads | bytes, successes, failures and resumed downloads per model revision |
| Recitation, as sums (SDK 2.0.1) | ayahs completed, and per surah how many (no ayah numbers, no order, no text); words scored; per tajweed rule how many were checked and flagged; app launches; how often the sharing sheet was shown, and how many answers were Share or Not now |
It carries no personal data, which is why it needs no consent. Quran Lab can switch it off for every app from the server, and you can switch it off in your app's code (analytics: off in each SDK's own spelling); the SDK never asks your users about it.
What it never sends
Audio (unless the learner agreed to share, below), recognised text or sounds, verdict lists, device, install, advertising or user identifiers, account details, locale, network type, location, or any time finer than the day. IP addresses are used for a minute by rate limits and never stored as addresses (see security signals below); the country is summed per app and day before it is stored.
Issue reports
When something fails: the kind and code of the error, the engine, the model revision, the device class, OS version, SDK and app version, and source locations inside the SDK. Never a message from your app, a file path or a stack with data. Reports of the same fault are grouped under Issues.
What you see here
Totals per app and day. There is no row per person. Any group of fewer than 10 installs is hidden: a quiet day shows no values, and a revision, device or setting used by too few installs is folded away. Apps set up with a development key are never counted. While the analytics page or the Overview is open, today's and yesterday's totals refresh every few seconds: they are still day totals under the same floor, and nothing is read per install or by the time of a check-in. Minutes shared by your learners appear as one total per app, once at least 10 learners have shared.
Your own account
We keep your Hugging Face user id, username and display name, the answers you gave on the access form, your keys (the id, never the secret), the coding assistants signed in as you (their name and last use, never their token), and your email address (below).
Your email address
What we keep. The address Hugging Face gives us at sign-in and whether Hugging Face verified it, refreshed at each sign-in; if you do not share it with us there, we delete the copy we had. A different contact address, if you set one on your Profile, used only after you confirm it with a code we email to it. For product news: each time you opted in or out, with the wording you saw and where you did it. A log of each email we tried to send you: its kind, the time, the address and the result, never its content.
What we use it for. Service emails about your account and apps: decisions on your access request, security notices (a key revoked, suspected abuse), changes to the licence or the terms, model releases, deprecations and breaking SDK changes that affect your apps, and decisions on raw-weights requests. They are part of using Quran Lab, as the access terms say, and need no separate consent. An organisation's emails go to its owners and admins. Product news (newsletters, launches, events) is separate: only if you ticked the box for it, and you can stop it with one click from any news email or on your Profile. We never sell your address or use it for anyone else's marketing.
Who handles it. Quran Lab stores it on Cloudflare, which also delivers the service emails. Product news may be sent through a newsletter tool that receives only the people who opted in.
How to change it. On your Profile: set a different contact address, remove it, or turn product news on or off. To change the Hugging Face address, change it on Hugging Face and sign in again. To have your address or account deleted, write to mostafa@quranlab.ai.
How long we keep it. Your address, for as long as you have an account. The record of your product news choices, for as long as you have an account, because it is our proof of what you agreed to. The send log, 400 days. Confirmation codes, a day after they expire.
Security signals
To protect the service, Quran Lab processes device integrity and security signals: failed integrity checks, signs of tampering, misuse of keys, and refused or probing requests. These signals never include audio or personal identifiers; an address is kept only as a truncated, salted hash, and they are deleted after about 90 days.
For your store listing
App Store privacy: with telemetry on, declare Diagnostics (performance and other diagnostic data), not linked to the user and not used for tracking. Where Quran Lab offers sharing in your app, also Audio Data, collected only after consent, not linked to the user's identity, for improving Quran Lab's models.
Google Play data safety: App info and performance (diagnostics), collected, not shared, processed ephemerally into daily sums. Where Quran Lab offers sharing in your app, also Audio (voice or sound recordings), optional, shared with Quran Lab, deletable by the user. Check the current wording of each form when you fill it in.