Choosing an exclusion method
The Cint Exchange offers three exclusion methods, each suited to different scenarios. They are not mutually exclusive — all three can be active on the same target group simultaneously. This page helps you decide which method fits your use case.
| Method | Complexity | Scope | Time-bound? | Best for |
|---|---|---|---|---|
| Exclude within this project | easiest | Project | No | Deduplicating across target groups in the same project |
| Respondent activity | intermediate | Account | Yes (90 days) | Rolling window deduplication across target groups in the account |
| Individual ID | advanced | Exchange | No | Granular, ID based control |
Exclude within this project — easiest
Use this when your project contains multiple target groups that represent distinct, non-overlapping populations and you need to ensure each respondent only completes one of them.
Use case: Deduplicating respondents across target groups within the same parent project — for example, separate demographic cells in an ad-hoc study or tracker waves that live in the same project.
The Exchange handles deduplication automatically. The Exchange blocks any respondent who records a complete status in any other target group in the project from entering this one. You don't need to maintain a list or configure a time window.
This method has no time bound — a complete in any other target group in the project triggers exclusion regardless of when it occurred.
See how to exclude within this project to learn how to configure this on your target group.
Respondent activity exclusion — intermediate
Use this when you need to deduplicate respondents across surveys that live in different projects, or when you want a rolling time-based window to govern eligibility.
Use cases:
- Brand trackers where each wave needs fresh respondents, and the waves live in separate projects
- Sequential research where participants in Phase A shouldn't appear in Phase B
- Any design where repeat exposure within a rolling window would compromise your data
You configure a list of projects or target groups to exclude against. At entry, the Exchange checks the respondent's participation history against that list using a 90-day rolling window.
How statuses are applied
The Exchange evaluates status at the target group level, even when an entire project is excluded. The status used depends on the state of the target group at the time of the check:
| Target group state | Status evaluated | Effect |
|---|---|---|
| Live | in_client_survey | Blocks concurrent participation — prevents the respondent from being active in two surveys at once |
| Paused or complete | complete | Triggers the 90-day history check |
Projects themselves do not have respondent statuses — only target groups do. This is why exclusion is always resolved at the target group level, even when a project is the exclusion target.
For configuration steps, see setting up respondent activity exclusions.
For a deeper explanation of how the logic works, see how respondent activity exclusions work.
Individual ID exclusion — advanced
Use this when you need granular, list-based control over specific respondents — regardless of their participation history.
Use cases:
- Excluding respondents who completed a relevant survey more than 90 days ago, outside the activity exclusion window
- Preventing known bad actors or flagged respondents from entering any target group
- Applying a shorter deduplication window than 90 days by manually managing a list
You supply a list of respondent IDs. The Exchange blocks any ID on that list from entering the target group, regardless of status or recency. This exclusion is permanent until you remove the ID from the list.
See exclude respondents by respondent ID to learn how to configure this.