Why Surveyee never stores your respondents' IP address by default

IP addresses are useful for abuse controls and duplicate-submission checks, but storing a raw IP also creates another identifier that can be associated with a response. Under the GDPR, IP addresses can be personal data. For a survey that promises respondents anonymity, collecting more identifiers than the task needs is the wrong default.

Surveyee therefore starts new surveys in anonymous mode. Raw IP storage is something a survey owner has to choose, not something respondents silently inherit.

What "anonymous by default" actually means here

When a survey is in anonymous mode (the default for new surveys):

• The respondent's raw IP address is not persisted with the response. The submission path derives a survey-scoped, salted one-way hash that can support duplicate-submission checks without retaining the raw address in the database.
• IP-derived country lookup is skipped for anonymous/no-IP-tracking surveys. When country lookup is enabled for a survey that does track IP-derived location, Surveyee uses a local GeoIP database rather than sending the respondent's IP to a third-party geolocation API.
• Anonymous mode also strips the response metadata that the product describes as identifying metadata, rather than merely hiding it from the survey owner's UI.
• If a survey owner explicitly configures the survey to retain IP information, the raw IP can be stored. That is a deliberate privacy-setting choice rather than the default.

This behavior is enforced in the response write path. It is not just a sentence in a policy page: the server decides whether a raw IP, a survey-scoped hash, or neither should be written before the response is persisted.

A hash is privacy-preserving, but it is not magic anonymity

It is worth being precise here. A one-way hash of an IP is not the same thing as keeping the raw IP, and Surveyee's survey-specific secret salt makes the stored value unsuitable as a simple cross-survey identifier. That meaningfully reduces what the database contains.

But "anonymous" also has a legal meaning that depends on the full context and the reasonable means available to identify someone. European data-protection guidance distinguishes anonymisation from pseudonymisation: data that can still be attributed to an individual using additional information can remain personal data even when the obvious identifier has been replaced.

So we do not claim that hashing one field automatically transforms every survey dataset into legally anonymous information. A small-team survey can still become identifying through department, role, free text, timestamps, hidden fields, or combinations of answers. The survey owner still has to design the questionnaire with those risks in mind.

Why not retain raw IPs just in case?

For many ordinary feedback surveys, a raw IP is not needed for the purpose of the questionnaire. Avoiding it has straightforward advantages:

• Less identifying data to protect. A breach or export cannot reveal a raw IP that was never stored.
• A more defensible respondent promise. The product's anonymous setting corresponds to a real storage decision instead of a display-only label.
• Duplicate controls can still work. A survey-scoped hash can be compared for repeat submissions without retaining the original address. It is an abuse-control signal, not proof of a person's identity: shared networks, VPNs, changing addresses, and other network behavior limit what any IP-based check can establish.
• Data minimisation becomes the default. If the survey does not need a raw identifier, the safer baseline is not to collect it for future convenience.

What Surveyee does around that default

A few concrete product properties matter alongside IP handling:

• Survey-scoped hash-based duplicate detection. The hash is salted with a secret and the survey ID, which prevents it from acting as a simple shared identifier across unrelated surveys.
• Anonymous-mode metadata stripping. Anonymous mode is treated as the stronger instruction when deciding what identifying response metadata to keep.
• No third-party analytics on respondent-facing survey pages. The respondent experience is kept separate from the product analytics used on owner/marketing surfaces.
• Optional end-to-end response encryption. Survey owners can opt into client-side response encryption when the content warrants a stronger confidentiality model. It is an optional feature, not the default.

For the deeper technical and policy details, see Security and the Privacy Policy.

If you're building a survey and want to inspect the privacy settings yourself, start one at /create. You can build and preview it locally before creating an account to publish.