What Communities Is and Why It Exists
Most research platforms are built around the assumption that you need a panel. Communities was built for teams that already have one.
If your team runs regular surveys to a proprietary group of consumers - an opted-in panel you have built and maintain - you have probably been managing that workflow across several tools. The contact list lives in a spreadsheet. The survey goes out through a separate email tool. Participation is tracked manually, cross-referenced after each wave, and updated before the next one. Communities replaces that chain of external dependencies with a single workspace inside Standard Insights platform, where the respondent list, the survey, and the distribution history all live together.
The feature serves two primary use cases. The first is teams running recurring external consumer surveys to a proprietary panel - brand trackers, quarterly sentiment studies, product feedback waves. The second is teams running internal surveys, such as HR pulse surveys or employee research, where the audience is a known, fixed group rather than a recruited sample. In both cases, the audience already exists. Communities is where you manage it from.
Setting Up Your Community - Uploading and Managing Respondents
Your Community starts as an empty contact database. Respondents can be added in two ways: manually, by entering individual contact details directly into the platform, or in bulk via CSV import for teams migrating an existing list.
Each respondent in the Community has an individual record. The record holds their personal information, their current status, any tags applied to them, and their full survey history within the platform - every survey they have been invited to, whether they completed it, and when. The status field reflects their current standing in the Community, including whether they have opted out. If a respondent opts out, they are flagged as such on their record and will not receive further survey invitations. The record is retained so the team's historical participation data remains intact.
Tags are the most important concept in the respondent record. A tag is a label applied to an individual respondent - "frequent buyer," "London office," "cohort 2024," whatever classification is meaningful to the research programme. Tags are how segmentation works inside Communities. There are no separate group-creation steps and no separate group objects to manage. The tag is the group. Apply the same tag to fifty respondents and those fifty respondents are a group, available for targeting as a unit in any future survey distribution.
A well-tagged respondent list is a segmented respondent list. The time spent tagging respondents at setup is what makes group distribution fast later - rather than rebuilding a distribution list for each survey wave, the team selects a tag and the right respondents are already there.
Organising Respondents with Tags and Groups
Because tags are the segmentation mechanism, the way to think about organising a Community is to think about the tags the research programme will need - not about creating groups separately.
A team running quarterly surveys to a panel of 300 consumers might tag respondents by purchase frequency, by region, or by how long they have been on the panel. Those tags then function as the targeting layer for every subsequent survey: send this wave to frequent buyers only, send this one to the full panel, send this one to the regional sub-group. The tag structure the team builds at setup is the distribution logic for every survey that follows.
Individual targeting and group targeting serve different purposes. Individual targeting - selecting a named respondent directly - is useful when following up with someone who did not complete a previous survey, or when a specific respondent needs to be added to a wave they were not originally included in. Group targeting, by selecting a tag, is how the team reaches a defined segment at scale: all respondents tagged as "London office," all respondents tagged as "lapsed buyers," all respondents tagged as belonging to a specific research cohort.
The tag applied at the respondent level is the group used at the distribution level. There is no intermediate step.
Distributing a Survey to Your Community
When a survey is ready to go to a Communities audience, four distribution options are available: link, QR code, embed, and direct invite.
Link and QR code generate a shareable URL or scannable code pointing to the survey - useful when the team wants respondents to access the survey through their own channel, such as an email newsletter or a printed card at a physical location. Embed allows the survey to be placed directly inside another web page or internal portal. The team controls how the link reaches respondents through whichever of these three channels fits the workflow.
Direct invite is the Communities-specific distribution method and the one most teams will use for managed panel surveys. It sends the survey invitation directly from the platform to named respondents. The team can invite individuals by name, selecting specific respondents from the contact list, or invite by tag, sending to every respondent carrying a particular label in one action. The respondent receives the invitation and accesses the survey through it. Their response is tracked against their individual record automatically.
Every survey sent to a respondent is recorded against their profile - who was invited, when, and whether they completed it. This is the feature that removes the manual tracking problem. The participation record the team would previously have maintained in a separate spreadsheet is built automatically inside the platform as each survey wave runs.
The distribution is one action. The tracking is automatic. The spreadsheet is no longer part of the process.
Common Use Cases and When Communities Is the Right Tool
A brand insights team runs quarterly purchase sentiment surveys to a proprietary panel of 300 opted-in consumers. Before Communities, that workflow involved an exported contact list, a bulk email send through a separate tool, and a spreadsheet updated after each wave to track who had responded and who needed a follow-up. With Communities, the contact list lives in the platform, the survey goes out through direct invite by tag, and participation is tracked automatically against each respondent's record. The quarterly wave is a matter of selecting the right tag, attaching the survey, and sending.
An HR team runs monthly pulse surveys to employees across three offices. They tag respondents by office location. Each monthly wave goes to all three tags simultaneously or to individual offices depending on the survey topic. Response rates by office are visible in the participation records without any manual aggregation. The HR system export, the separate distribution step, and the response-rate tracking document are all replaced by a single workflow inside the platform.
Communities is the right tool when the team already has respondents. It is built for teams managing a known, defined audience - whether that audience is an external consumer panel or an internal employee group. If the team does not have an existing respondent pool and needs to recruit one, the Standard Insights panel is the correct starting point. Communities and the Standard Insights panel serve different needs. They are not interchangeable.
Frequently Asked Questions
Is there a limit on how many respondents I can add to a Community?
No. There is no respondent cap. Communities can hold as many contacts as the team's research programme requires.
Can I have multiple Communities under one account?
Each account has one Community. Segmentation within that Community is handled entirely through tags - a tag applied to a sub-group of respondents functions as a distinct audience for targeting purposes. Teams running multiple research programmes, such as a consumer panel and an employee panel, manage both within the same Community using separate tag structures.
What happens to survey history if I delete a respondent?
Deleting a respondent removes their record and all associated data from the platform, including their survey history. If retaining participation history matters to the team's research programme, archive or export the respondent list before deletion rather than removing records permanently.
Can respondents opt out, and what happens when they do?
Yes. If a respondent opts out, they are flagged as opted out on their individual record and will not receive further survey invitations. Their record and survey history are retained - opting out does not delete the respondent from the Community.
Is Communities available on all plans or Enterprise only?
Communities is an Enterprise feature.
Can I export my respondent list and survey history data?
Yes. Respondent lists can be exported from the platform.