Collect Datainterviewer
Data Storage and Safety
Interviewer keeps all of your research data on the device it runs on. This page answers the operational questions a field team needs: where interview data lives, what protects it, what can destroy it, and how to keep it safe.
Where your data lives
Everything Interviewer stores — protocols, interviews, and settings — stays on the device, with no cloud sync or server component. The Network Canvas team never receives, transmits, or stores any participant data, and no participant data leaves the device unless you export it. The optional anonymous usage analytics contain no participant data — network data, responses, case IDs, protocol contents, and asset files are never collected — and can be turned off at any time in Settings → Privacy.
One documented exception to the local-only model: on stages using the Geospatial interface, map tiles are fetched from the third-party Mapbox service during the interview, and anything a participant types into its search box is sent to Mapbox's search API. Factor this in when planning studies where locations are sensitive.
Interviewer stores its data in your web browser's storage on the device you use. All of it should be treated as potentially sensitive:
- Protocols — alongside the structure of your interview, a protocol can embed any datasets needed to conduct it, such as a participant roster.
- Session data — participant response data, plus metadata such as the date a session was conducted.
- App configuration and metadata — application settings and protocol metadata.
Good to know:
Interviewer Classic stores its data within the app on the device instead, and does not encrypt its data store — device-level encryption is its only protection at rest. See IRB and Security Best Practices for guidance covering both versions.
What protects your data
When you set up an app lock during first-run setup — a PIN, passphrase, or biometric — the on-device data is encrypted at rest with a key derived from your credential, and the same authentication that unlocks the app releases the key used to decrypt it. While the app is locked, the lock screen reveals nothing about what is stored — no protocol names, session counts, or other details. Interviewer locks itself automatically after a period of inactivity and when the app is closed, and you can additionally require re-authentication when entering an interview, exiting to the dashboard, or exporting data. See Security and locking for how to set all of this up.
If you chose No security during setup, there is no app-level protection, and your data relies on the device's own protections alone.
Either way, app-level security is a layer to use in addition to device-level protections, not a substitute for them. Enable full-disk encryption on the device, use strong user authentication and screen lock timeouts, and restrict physical access — see the security best practices for the full list.
What can destroy your data
Because your data lives only on the device, several things can permanently remove it:
- Losing your credential. A forgotten PIN or passphrase cannot be recovered — the data it protects is permanently inaccessible on that device. Biometric setup also enrolls a mandatory recovery passphrase: if you lose the authenticator alone (for example on replaced hardware), unlocking falls back to that passphrase, and only losing both means permanent loss.
- Revoking the device lock. Re-enrolling a replacement PIN or passphrase (after proving your current one) preserves access to your data, but changing to or from biometric requires revoking the device lock, which erases all protocols, sessions, and stored credentials on the device. The Revoke / Reset device option in Settings → Security does the same, returning you to first-run setup.
- Clearing browser data or removing the app. Interviewer's data lives in your browser's storage, so clearing the browser's stored site data — or uninstalling the browser or the installed PWA in a way that removes its data — takes your protocols and interviews with it. Treat clearing browser data on an interview device as deleting your research data.
- Deleting a protocol. Removing a protocol from the device also removes any interviews recorded against it. Interviewer asks you to confirm first, since this cannot be undone.
- Losing the device itself. A lost, stolen, wiped, or broken device takes its data with it.
Take Care!
The common thread: export your interviews regularly, so that losing — or re-securing — a device never means losing your data.
Keeping data safe in the field
Since interview data exists only on the device until you export it, exporting is both your backup mechanism and the most vulnerable step in the workflow. We recommend that you:
- Export regularly. Export sessions from the Data view as you collect them, rather than letting data accumulate on field devices. The export process packages your selected sessions into a single
.ziparchive. - Minimize the time data stays on field devices. Upload exports to a designated secured storage location as regularly as possible, and then delete the sessions from the device. This limits the risk from a device being lost or stolen.
- Organize and back up your exports. Follow the data organization and backup best practices — a copy in one cloud location is not a backup.
- Rehearse your export pipeline before collecting real data. Use the Synthetic data feature in Settings to generate fake sessions and run them through your full export-and-backup workflow, so the first time you depend on it is not with real participant data.
For the wider security picture — including your responsibilities as the holder of the data — see IRB and Security Best Practices.