Anonymous survey design starts with a data inventory, not a checkbox

billy6go — Thu, 30 Jul 2026 05:23:02 +0000

“Anonymous” is often implemented as a missing name field.

That is a start, but it is not a design method. A survey can omit a name and still connect an answer to an account, invitation token, IP address, cookie, device identifier, tiny team, or revealing free-text detail.

The useful engineering question is:

Which identity paths does this task actually need, and what happens if we remove each one?

Here is the checklist we used while building CandorKit, a short-lived survey probe.

1. Inventory the data path before writing the form

List every value that can enter, leave, or persist in the system:

survey title and questions
response choices and free text
timestamps
account or invitation identifiers
network and device metadata
analytics events
exported files and copied summaries
administrative secrets

Then label each item as required, optional, or prohibited for the specific task. “The framework collects it by default” is not a requirement.

CandorKit’s application database stores survey text, answers, timestamps, a hash of the private owner key, and an expiry timestamp. It does not attach names, account IDs, IP addresses, user agents, or cookie IDs to answers.

That statement is narrower than “nobody can identify a respondent.” Network providers still process ordinary requests. Question wording, small groups, unique events, and free text can reveal a person even when the application omits identity columns.

2. Split respondent access from owner access

A public response URL and a private results URL serve different trust roles. Reusing one bearer link for both makes accidental disclosure easier.

CandorKit creates a private owner secret and places it in the URL fragment. Browsers do not send fragments in the normal HTTP request path. The server stores a hash rather than the raw key.

This design has a cost: there is no recovery workflow. If the owner loses the private link, the service cannot reconstruct access. That trade-off should be visible before the survey is shared, not hidden in support documentation.

3. Give retention an executable boundary

“We delete data when it is no longer needed” is not an operational rule.

An executable rule needs:

a known expiry timestamp;
rejection of new reads or writes after expiry;
a cleanup process;
visible user wording;
a statement about copies outside the system.

CandorKit assigns each survey a seven-day database expiry, rejects expired access, and runs scheduled cleanup. CSV exports, screenshots, copied analysis, and other downstream files are outside that automatic deletion boundary.

4. Keep analytics away from sensitive payloads

An analytics event should describe product behavior, not survey content. Do not send titles, questions, answers, owner keys, or private links into session replay or event properties.

The same rule belongs in logging and error reporting. A masked UI is not enough if a request body or exception payload copies sensitive text elsewhere.

5. Design the questions as part of the privacy model

Infrastructure cannot rescue a survey that asks respondents to identify themselves in prose.

For sensitive feedback:

avoid asking for names, exact locations, employee IDs, or unnecessary demographics;
warn people not to name themselves or others in free text;
avoid combinations that isolate one person in a small group;
choose multiple-choice or ranges when exact values add no task value;
do not use a lightweight anonymous survey for emergencies, regulated reporting, or protected whistleblowing.

The practical lesson is that anonymous survey design is subtractive. Remove identity paths, shorten retention, separate privileges, and name the remaining limits.