Privacy
Research tools hold other people’s answers. This page says what we keep, what we deliberately do not, and who can reach it.
Last updated 31 August 2026
Two kinds of people, two different answers
A researcher has an account with us. A participant does not, and never will — they follow a link, answer some questions, and leave. Almost every question about privacy here has a different answer depending on which one is being asked about, so the two are kept apart throughout.
What we collect from participants
When somebody takes part in a study, we store:
- their answers, and how long each one took;
- a pseudonymous participant identifier, generated in their browser rather than assigned by us — it links one person’s answers within a single study and means nothing outside it;
- a single device bucket: desktop, tablet or mobile, and the viewport size.
That is the whole list. We do not ask a participant for their name or email, and a study cannot be configured to collect one through us.
What we refuse to collect
These are constraints in the code, not preferences, and each one is enforced by a test rather than a policy:
- No IP address and no user-agent string. Not truncated, not hashed — not recorded. The coarse device bucket above is all we derive.
- No cookies on the participant surface, and no tracking pixels. Invitation emails are plain text with no images, because an image in an email reports when a named person opened it.
- No participant email or free-text answer in any log, on any path, including error paths.
- No cross-study or cross-site profile. We do not join a participant identifier across studies, and there is nothing to join it to.
Consent
Every published study begins with a consent step. It can be worded to suit the study, but it cannot be removed — a study that skips it cannot be published. The researcher running the study decides what they are asking for; we make sure they have to ask.
Where the data lives, and for how long
Each organisation chooses a region when it is set up, and research data for that organisation stays in it. Each organisation also sets a retention period — twelve months by default — after which responses are deleted.
Organisations may also point UX Viber at storage they control, in which case response data is written to their infrastructure and we hold none of it. That option exists because for some teams the honest answer to “where is our research data” has to be “ours”.
Who the data belongs to
Research data belongs to the organisation that collected it. We process it to provide the product and for nothing else. In particular:
- We do not train models on customer content, and we do not use a provider that reserves the right to.
- Where a feature sends text to an external model, emails, phone numbers, postal addresses, URLs and detected names are replaced with placeholders before the request leaves us, and the feature is off until an organisation turns it on.
- We do not sell data, and we do not share it for advertising.
Researcher accounts
For people with an account we hold an email address, a name if one is given, and the organisations and workspaces they belong to. Signing in with Google tells us the email address on that Google account and nothing else — we do not receive a password, and we do not read anything else in a Google account.
Session cookies are set for one hostname only and carry no Domain attribute, so a session on one organisation’s address is unreadable at another’s. The participant surface is served from a separate origin that never carries a session at all.
Getting data removed
An organisation admin can delete a study, which deletes its responses. Deleting an account or an organisation’s data in full, or acting on a request from a participant, is handled by contacting us — write to privacy@uxviber.com and we will act on it.
Because participant data is pseudonymous by design, a request about a specific person usually needs the researcher who ran the study to identify which records are theirs. We would rather that friction than hold the identifying data that would remove it.
Changes
If this policy changes in a way that affects what we collect, we will say so here and date it. The date at the top is the last time it changed.