Aggregate results and anti-inference controls
Heads up — Two numbers matter: 3+ responses before poll-wide charts unlock, and 5+ in a filtered cohort before a slice unlocks. Demographic cohorts has the full picture.
Threshold and locked UI
- Aggregate analytics stay locked until at least three responses exist for the poll. Below that, the admin UI shows a locked state without exact counts—reducing small-group inference.
- Authorized admins see only aggregates in the results experience—never one row per submission.
- No timestamps, submission order, or per-response metadata are exposed in admin results views.
- When unlocked, encrypted submissions are shown to authorized admins in a way that does not reveal who answered first or last from list order alone.
The unlock threshold is 3 responses (the same minimum you’ll see suggested when setting minimum recipients on a new poll).
Poll design note: The minimum recipients field is your distribution guidance (“don’t target a smaller group than this”). It is related to responsible rollout but separate from the unlock threshold above.
Cohort slicing
If your poll collects optional demographic dimensions, the admin UI can filter aggregate charts by those dimensions. A second threshold applies: you need at least five responses in the filtered cohort (after results are unlocked for you) before the UI shows that slice. Below that, the cohort view stays locked.
The poll wizard’s Anonymity Coach explains that adding multiple dimensions increases combination counts; many combinations may fall under that minimum—by design.
Defense in depth
Anti-inference is built into the product: admin views and exports stay aggregate-only, without per-person timelines or submission ordering that could identify individuals.