Data protection & participant privacy

Last reviewed: October 19, 2026

ThisStudy is a survey platform for academic research. This page describes, in plain terms, what happens to the data participants provide, so that researchers can describe it accurately in consent forms and participants can check it for themselves. It is a factual description of how the platform works, not a legal document.

ThisStudy is operated independently by Laurence Ashworth. It is not a service of Queen’s University.

What is collected automatically

When someone takes a survey, the platform records:

Their answers, with timestamps and per-page timing (used for data-quality checks, such as detecting inattentive responding), how many times the session timed out through inactivity and was continued, and the names of any values the study works out from their answers that changed because they went back and changed an answer.
Coarse interaction measurements, used for the same data-quality checks: whether text was typed or pasted and how many characters of each, how long was spent actively typing, how long it took to first click or press a key on a page, counts of clicks, key presses, copy events and times the study tab lost focus, how many of those key presses and pastes happened while the tab was in the background, how long the tab spent hidden, how often the pointer moved and how clicks were made (for example, with a mouse or by touch, and how soon after the pointer stopped moving), how many answers arrived in a field without any typing in it first (autofill, a password manager, or dictation), and the automation indicators the browser itself reports (navigator.webdriver, and whether answer fields were set by a script rather than typed). These are counts, durations, and yes/no values only. Measurement begins as soon as a study page loads, including the consent page.
Coarse device information: device type (desktop, mobile or tablet; “bot” when the browser identifies itself as automated software, and “unknown” when it cannot be told), browser family, and operating system family. These are derived from the browser’s user-agent string, which is itself discarded.
Two one-way codes derived from the IP address. The address itself is never stored or written to logs: before anything is saved, it is combined with a secret value, put through a cryptographic hash (SHA-256), and truncated. One code is made from the full address (to note duplicates). The other is made from only its network part (to note responses from the same network). Whether the IP address was IPv4 or IPv6 is also stored. The codes are not the address, and without the secret value they cannot be traced back to one. The secret value is kept confidential by the platform.
A coarse network category derived from the IP address: whether the connection is a home/business internet provider, a mobile carrier, or a datacenter/VPN. This category is used to spot automated or masked responses. Like the device information, it is derived at the moment of collection and only the category is kept. The IP address itself is still never stored, and the category is not a location.

The platform does not collect names, email addresses, location, or anything else from participants’ devices. It never records what was typed key-by-key or which keys were pressed, mouse positions or paths, where clicks landed, screen contents, or clipboard contents. When text is pasted into an answer field, the platform records that a paste happened and its length as a data-quality signal. The platform only observes events on the study page: it cannot see other browser tabs, other windows, other applications, or anything done in them. It does count how many times the study page loses focus or is hidden, and how long it is hidden, as a data-quality signal, but never where participants went or what they did there. Participants never create accounts. Study pages contain no analytics, advertising, or third-party tracking scripts. The fonts, styles and scripts a study page uses are served by the platform itself, not fetched from another company.

Media a researcher adds from elsewhere is an exception. A study can show an image, a logo or a video file hosted on another site, or a video embedded from YouTube, Vimeo or Loom. The participant’s browser fetches that media from its host, so the host receives the participant’s IP address and the usual details a browser sends with any request, and may set cookies of its own.

Cookies

Study pages set one cookie: a session cookie containing only a random identifier, used to keep a participant’s place in the survey and to protect against request forgery. It is HTTPS-only, inaccessible to page scripts, and expires after one hour of inactivity. The platform sets no third-party cookies. Media a researcher adds from another site, described above, comes from that site, which may set cookies of its own.

Where data lives and how it moves

All traffic between participants and the platform is encrypted in transit (HTTPS, with HSTS enforced). It reaches the platform through Cloudflare’s network, which stands in front of the hosting provider and filters out attacks. As with any website’s network providers, Cloudflare and the hosting provider process each request in order to deliver it: they see the visitor’s IP address, and the contents of the request pass through their systems on the way. What the platform itself keeps of the IP address is described above, under what is collected automatically.

Responses are stored in a PostgreSQL database hosted by Render, a cloud provider that encrypts data at rest and is SOC 2 Type II certified. Render’s own security practices are documented on its Security and Trust page. The database is in Render’s Ohio region, in the United States. Some ethics boards ask researchers to tell participants when data is stored outside their own country.

Within that encrypted database, responses are stored in readable form: the platform does not add a second layer of application-level encryption. Encryption at rest means that someone who stole the provider’s physical drives could not read the data. But anyone with legitimate access to the database (see below) can read responses, so what protects them is control over who has that access. An application-level layer would mean that even someone with database access could not read responses without a separate key. That mainly matters for highly sensitive data, such as health information. If your study collects that kind of data, raise it with your ethics board.

Who can see responses

Only the study’s owner (the researcher who created the study, or a researcher the study is subsequently transferred to) and their collaborators (researchers with whom the study is shared, and previous owners who stay as collaborators after a transfer). A platform administrator who is not one of these can open a study only through a time-limited grant that is recorded in an audit log, used for support and moderation. An administrator can also move a study to a different account (for example when its owner has left the institution). They can move it to their own account only when the platform has no other administrator who could make the move. Either way, the move takes effect at once, is recorded in the same audit log with the reason given, and both researchers are emailed. The platform’s operator also has technical access to the underlying database through the hosting account. ThisStudy itself never sells participants’ data, discloses it to anyone beyond the people described here and the hosting and network providers that store and deliver it on the platform’s behalf, or uses it for any purpose other than running the study. Researchers with access to a study can export its responses. What happens to an exported file is outside the platform’s control.

Who owns the data

Researchers keep ownership of the data they collect and the study materials they create. The platform’s operator claims no rights to either. The platform places no restrictions on how researchers use or share their data: that is governed by their ethics approval and their institution’s policies.

Retention and deletion

Data is kept until a researcher deletes it or their account is deleted. There is no set retention limit, but the platform does not promise to remain available indefinitely.

When a researcher deletes a single participant’s data, all participants’ data, or an entire study, the data leaves the study at once and is held in a restorable trash for 30 days. After that it is permanently erased within a day. Render retains short-term database backups for disaster recovery for 3 to 7 days, after which erased data is gone from backups as well.

A researcher can erase data from the trash straight away. This needs a code sent to their email, so that someone who has only their password cannot do it. For the same reason, no code is sent for 30 days after an account’s email address changes. Researchers honouring a participant’s request to have their data erased should use this option. Answers given before consent can also be discarded: those on pages before the consent page (a screening question, for example), and those on the consent page itself from anyone who did not go on to consent. This needs the same emailed code, and the deletion is immediate and permanent: these answers are not held in trash.

Deleting an account deletes its studies and their data after a holding period. A researcher can transfer studies and their data to another researcher prior to deleting their account. When a researcher asks for their account to be deleted, its studies stop taking new participants at once, and the researcher can cancel for 30 days. After that, the account, its studies and their data are permanently erased within a day. They are not held in trash first. A platform administrator can also schedule an account’s deletion, with the same 30-day hold, and can carry it out sooner, which needs a code sent to that administrator’s email.

If the platform is ever discontinued, researchers will be given at least 30 days’ notice by email, so that they can export their data first.

Beta software

ThisStudy is beta software, provided as is. It may contain bugs, change without notice, or be unavailable for a time. Data loss is possible, there is no guaranteed uptime, and support is best-effort. If you are running a study on it: run a pilot first, export your data regularly while you collect it, check an early export, and have a fallback plan.

If a study asks for identifying information

Researchers may choose to ask participants for identifying information (a name, an email address, a participant ID from a recruitment platform). The platform treats those answers like any other response: encrypted in transit, stored in the provider-encrypted database, open on the platform only to the people described under Who can see responses, and permanently deletable. But no internet-based system can guarantee absolute security, and this page makes no such guarantee. If your study collects identifying information, do not describe it as anonymous.

Sentences you can adapt, consistent with how the platform actually works:

For studies collecting no identifying information:

“Responses are collected through ThisStudy, a survey platform that does not record names, email addresses, or IP addresses. IP addresses are converted to one-way codes, which the platform uses to detect duplicate or automated responses.”

For studies collecting identifying information:

“Responses are collected through ThisStudy, a survey platform. Data are transmitted over an encrypted connection and stored in an encrypted, access-controlled database. As with any internet-based data collection, absolute security cannot be guaranteed.”

These sentences describe the platform only. Who sees the data, what happens to it once it is exported, and how long it is kept are for you to describe in your own words.

If your study shows an image or a video hosted on another site, add a sentence saying the site receives the participant’s IP address, which the first wording above does not cover.

Platform details: thisstudy.com/privacy