Can a Requester share Poll results? Can a Respondent share Survey results?
Anyone with a valid private access key can share the matching report.
Our philosophy
If it’s your data, it’s your data.
Every Poll and every Survey peer group report is protected by a private access key.
If a link is shared, anyone with that key can view the report.
If a key is abused, we can revoke it — but control over sharing always starts with the participant who owns the link.
Poll-level sharing
Only Requesters receive access keys for Poll reports (the aggregate view across all Survey peer groups).
If a Requester shares their private Poll report link, anyone with that link can view the aggregated results.
If you’d like a refresher on how these layers relate to each other, see
How do Polls and Survey peer groups work together?
Survey-level sharing
Survey peer group reports are shared intelligence between Respondents and Requesters.
Both parties can share their report links if they choose.
When a Survey peer group closes, we remove all Requester identifiers.
Reports display only anonymized, aggregated data — never who launched the Survey.
Naming Polls and Survey peer groups (internal only)
To help Requesters stay organized, both Polls and Survey peer groups can be given custom titles.
These names are strictly internal:
- They do not appear in survey forms
- They do not appear in public or shared reports
- They are never visible to Respondents
For example, if a Requester names a Survey peer group “Top MBAs”, while another survey peer group is called "Safety school MBAs" (ouch!!) -- Respondents will never see that label. It’s entirely up to the Requester how (or whether) they describe the peer group when inviting participants.
To ensure reports remain safe to circulate, we also assign a generic system name to each Survey peer group (for example, “Survey #2”).
This generic label is what appears wherever a report needs a title in default public views.
Requester-only report enhancements
When you’re logged in as the Requester and open a report from your dashboard, you may notice a slightly richer experience.
Those report links include:
- Your requester secret key (which unlocks the standard public report)
- An additional URL parameter:
?scope=requester
That scope=requester flag triggers a separate, authenticated request to retrieve requester-only metadata — such as your custom Poll title or Survey peer group names.
This data is only returned if:
- You are logged in, and
- You are verified as the owner of that Poll or Survey
If both conditions are met, your report view includes your internal titles to make navigation and review more comfortable.
Why this design
Reports are intentionally context-free.
We assume reports may be shared beyond the original participants, so no identifying or sensitive information is ever embedded directly in report data — including requester identity, internal naming, or Trust Circle details.
We also assume Requesters may make sampling decisions they don’t want (or need) to justify.
Those decisions — including how peer groups are defined or labeled — are never exposed in reports.
It’s just data: safe to circulate, privacy-preserving by construction, and respectful of everyone involved.
Technical addendum: sharing safety for requester-only fields
Even if you share a full report URL that includes both your private access key and the ?scope=requester parameter, requester-only fields will not leak.
If the viewer is not logged in as you, the requester scope quietly fails and the report just loads in its standard public view.
You can verify this yourself:
- Copy a report URL with
?scope=requesterappended - Open it in an incognito window while logged out
- You’ll see the public report, without your custom titles
Technically, this works because:
- Public report data is served exclusively from our
/public/*API surface - All sensitive or requester-specific fields live behind authenticated
/manage/*endpoints. This is a completely separate 'call' to our platform. - Ownership is always verified before any requester-only data is returned
The report UI simply adds requester-only fields when they are safely available — but its default experience is that they are not available so we can always degrade gracefully.
The public experience is always safe by default.
Anything extra exists purely as an authenticated, requester-only add-on, and it is structurally separate.