Privacy built around survey data, not respondent profiles.

Scope and account data

Research Rill is an online survey builder for survey owners and respondents. Owner accounts use an account name and passphrase; no email address is required for V1 account creation.

Account records store the normalized account name, an Argon2id passphrase hash, account/security state, and activity timestamps needed for authentication, retention, and administration.

Respondent data

Survey answers and survey-specific presentation state are stored so respondents can progress, resume when allowed, submit, and support accurate results.

• Response records do not persist respondent IP addresses, browser fingerprints, inferred locations, email addresses, or other identity fields.
• Network and hosting infrastructure necessarily processes normal request metadata. Security rate limits use transient, keyed/HMAC-derived source identities rather than storing raw IP addresses in application rate-limit keys.
• Response-session credentials are random capabilities stored in the browser; application tables retain hashes rather than retrievable raw credentials.

Invitations and recipient lists

Unlocked surveys may use single-use invitation capabilities. Possession of an invitation proves access to that invitation, not a person's identity.

• PostgreSQL stores hashes of invitation tokens, not retrievable raw invitation URLs.
• Generated invitation CSV delivery is retained only as an encrypted Redis artifact for 15 minutes so a dropped download can be recovered.
• Optional recipient identifiers are not stored in application tables. When used, the recipient-to-invitation mapping exists only inside that short-lived encrypted delivery artifact.

Payments and safety reports

Research Rill stores only the payment and safety metadata needed to process survey unlocks, reconciliation, and abuse triage.

• Ko-fi donor name, email, and free-form payment message are not copied into payment-event or admin-audit tables. Normalized provider/event identifiers, amount/currency, survey correlation, and processing status may be retained for reconciliation.
• A survey safety report stores the survey reference, one normalized reason category, status/disposition, and timestamps. The report form does not ask for reporter name, email, survey answers, response/session identifier, or free-text narrative.

Retention

Retention differs by data type and capability state; retention holds can suspend destructive deletion when required.

• Preview/test responses are retained for at most 30 days.
• For abandoned production attempts, answer/presentation payloads are deleted 30 days after abandonment and minimal abandoned-response metadata is deleted 90 days after abandonment when no hold applies.
• Revoked invitations and fully revoked invitation batches are retained for 90 days before eligible cleanup; completed invitation history follows completed-response retention.
• For free surveys, 180 days without authenticated owner activity automatically closes an open survey; at 360 days, eligible free survey content may be permanently deleted after activity and hold rechecks.
• Unlocked and restricted surveys are not subject to the automatic free-content inactivity purge in V1. They remain until owner deletion or another documented administrative/legal action; a separate automatic retention period has not been defined.

Deletion, backups, and recovery

Deleting data from the live database does not mean every existing backup copy disappears at that same moment.

• Production backups and point-in-time recovery are maintained for disaster recovery under a separate operational retention window and restricted operator access.
• An active retention hold blocks automatic destructive retention and owner-requested destructive deletion for the held scope.
• Deleted records may remain in pre-existing recovery media until that recovery window expires. A disaster restore can temporarily reintroduce older records, after which normal deletion/retention controls must be reapplied.

Analytics, indexing, and cookies

Marketing analytics are separated from application and respondent activity.

• GA4 may load only on public marketing pages when explicitly configured for the canonical production site. Marketing pages may also use a locale cookie to remember language.
• Survey-taking, invitation, results, export, account, Help, and admin surfaces are noindex and do not load GA4. Authentication and respondent flows use functional session/capability cookies needed to operate the service.

Controls and contact process

Owners can archive surveys and permanently delete archived surveys through the authenticated destructive-deletion flow, subject to recent passphrase re-authentication and any active retention hold.

• Because V1 accounts do not require email, forgotten passphrases cannot be recovered through an email reset.
• For a privacy or safety concern tied to a particular public survey, use the survey's “Report this survey” link; the report is category-only and does not request reporter identity.
• A separate operator contact channel is required for notices that need a reply or attachments, including formal copyright/legal notices. The production operator must publish that channel before public launch; this build does not invent an address or legal entity.