Data & Security
How Nabad handles session and participant data: written for the questions procurement teams ask.
Last updated: 2 October 2026
1. Where session data is stored
Application data (accounts, sessions, questions, and participant responses) is stored in a managed PostgreSQL database (Neon). Live vote tallies during a session are held in a managed Redis cache (Upstash). The application runs on DigitalOcean. Our current data region is the United States (AWS US-East). Customers with a regional data-residency requirement can contact us to discuss options.
Who at Nabad can see your sessions
To run Nabad, our admin view shows basic account information, session titles and how many people took part. We don't read your questions or participant responses, and we never use what you create for marketing.
2. What we collect from participants
Participants do not create accounts. For each participant we process:
- A random device identifier generated in the browser and kept in its local storage. It is used to count each participant once, to prevent double-voting, and to keep one participant’s answers and name together within a session. It is not linked to any real-world identity.
- Their answers: a vote, a word, a short text response, a ranking, or a rating.
- A display name, depending on what the host chose for the session: optional (the default: each participant can type a name or stay anonymous), required (a name is needed to answer), or off (no name is asked for or stored). When a name is given, the host sees it with the response.
We do not ask participants for an email, phone number, or login, and we use no advertising cookies anywhere. No analytics or tracking script runs on the pages a participant sees: the join page, the voting page and the presenter screen carry none. Our public marketing pages use Cloudflare Web Analytics, which counts visits without cookies. Browser local storage is used only to remember a participant’s device identifier, the name they typed, their chosen reading language and which questions they have already answered. Those pages also offer Google Analytics, which stays switched off unless a visitor accepts it on the consent banner.
Nabad is made for audiences of every age, school classes included. When a session is run for young students, the teacher or school decides what is collected; with names off, answers carry no name at all. Under Quebec law, personal information from a child under 14 may be collected only with the consent of a parent or guardian, so we recommend names off for those classes unless the school already has that consent.
3. Retention
| Data | Retention |
|---|---|
| Session results & participant responses | Kept until the host deletes them. Closing a room does not delete it, so a host can reopen the results sheet later, on any plan. We do not run an automatic deletion schedule today; if your organisation needs a fixed retention period, contact us and we will agree one in writing. |
| Deleted sessions (Trash) | Kept 30 days so the host can restore them, then removed for good with all their responses. |
| Account data | Kept while the account is active. Deleted immediately when the host deletes the account, together with every session and response, the analytics and AI records of those sessions, messages sent through our contact form and the mailing-list entry. Stripe keeps its own record of past payments, as the law requires. |
| AI inputs and outputs | Kept up to 90 days to measure the quality of translations and themes, then deleted. |
| Results cache (Redis) | A copy of each session’s results is cached so the room and the results sheet load quickly. It is removed when the session is deleted for good or the account is deleted. |
4. Subprocessors
We share data with these providers only to deliver the service. We do not sell data.
| Provider | Purpose | Data |
|---|---|---|
| Neon | Primary database | Accounts, sessions, responses |
| Upstash | Results cache (Redis) | Live vote tallies and a cached copy of results, which can include answer text and display names |
| Google (Gemini API) | Spam check of Q&A and open-text answers (any plan); AI room insights, recap and translation for participants (Pro sessions); translation when a host requests it (any plan); spelling a participant’s name in Arabic or Latin letters (any plan) | Participant open-text, Q&A and word-cloud answers, and a participant’s name when it is spelled in the other script (see section 5) |
| Stripe | Payments | Host billing details: card data never touches our servers |
| Google (Analytics) | Marketing-site analytics | Page views on our public pages. Not loaded on the join page, the voting page or the presenter screen. |
| Resend | Email to hosts | Host email address and the emails we send to it, including session recaps that summarise participant answers; messages sent through our contact form |
| Sentry | Error monitoring | Stack traces and request context from server errors, which can include a session identifier |
| DigitalOcean | Application hosting | Application traffic |
| Cloudflare | Domain name (DNS) and cookieless visit counts on our public pages | Visits to our public pages, including IP addresses. No session, answer or account data |
| Google (Fonts) | Typefaces on our pages | Your browser downloads fonts from Google, which sees its IP address. No session, answer or account data |
| Google and Microsoft (sign-in) | Signing in with Google or Microsoft, when a host chooses it | The host’s email address and account identifier, sent to us by the provider |
5. AI processing
Participant text reaches Google’s Gemini API in these four situations, and no others:
- Spam check: any plan. Q&A questions and open-text answers are checked for spam and off-topic content, so the host can hide them before they reach the screen. Only answers not yet checked are sent.
- AI room insights and recap: Pro sessions only. In a session owned by a Pro account, answers to word-cloud, open-text and Q&A questions are sent while the session is running, to read sentiment and group similar answers into themes, and once more when the session ends, to write the recap emailed to the host. Sessions owned by Free accounts are not sent for this. Accounts created before 1 September 2026 keep the AI they signed up with, so their sessions are still sent.
- Translation. On any plan, when a host asks to translate participant answers on the presenter screen, the answers being translated are sent for that translation. In Pro sessions, answers are also translated automatically into the languages participants are reading in, so each phone can show them in its own language.
- Name spelling: any plan. When a participant types a name in Arabic letters, or in Latin letters in a room that uses Arabic or Persian, that name is sent to suggest how it is written in the other script, which the participant can accept or refuse. Only the name is sent, with nothing else from the session.
Text is sent for that processing only. It is not used to build a profile of any participant, and display names are sent only in the name-spelling case above. Institutional customers can request our current data-processing and retention terms for this provider.
6. Security controls
- All traffic is encrypted in transit over HTTPS (TLS).
- Passwords are stored only as bcrypt hashes; we never see the plaintext.
- Session identifiers are unguessable, and every read of a session’s results is authorised against the owning account, server-side, on every request.
- Each signed-in browser is a separate record on the server. The browser holds a random key, and only a hash of it is stored. The record keeps the browser type (for example, Chrome on Windows), an approximate country, and when it signed in and was last active, never the IP address. Signing out ends the record on the server, not just in the browser. Hosts can see and sign out each device on their Account page. Expired and signed-out records are deleted after 30 days.
- Participant text is escaped wherever it is displayed, and response length is capped on the server.
- The 6-digit join endpoint is rate-limited to prevent code guessing, and voting is rate-limited per participant.
- Access to production systems is restricted to the core team.
7. GDPR and Quebec law
For host account data, Nabad is the data controller. For participant responses, the host running the session is the controller and Nabad is the processor acting on their behalf. Our lawful basis is the legitimate interest of the host in running their session and the performance of our contract with the host. A data processing agreement is available to institutional customers on request.
When you create an account, we use your IP address to find your approximate country and save it with your account, so we know where our users come from. The lookup happens on our own server, using IP2Location LITE data.
Under Quebec’s Act respecting the protection of personal information in the private sector (Law 25), the person in charge of the protection of personal information at Nabad is Scarlett Myriam Jebara, reachable at info@nabad.live. Data is stored in the United States, outside Quebec.
8. How to request deletion
A host can delete any session (and all of its responses) from their dashboard at any time, and can delete their entire account from their profile. For any other deletion request, including a participant asking to remove a response, email info@nabad.live. We action verified deletion requests within 30 days.
9. Breach notification
If we become aware of a personal-data breach affecting your data, we will notify affected customers without undue delay and, where required, within 72 hours of becoming aware: describing what happened, what data was involved, and the steps we are taking.