How respondent activity exclusions work
Respondent activity exclusions prevent respondents from entering a target group survey based on their activity in related surveys. This keeps each wave of respondents independent. When enabled, the Cint Exchange evaluates a respondent's history automatically at the point of entry. If their recorded activity matches your exclusion configuration — by default a Complete, or other statuses you configure — the Exchange blocks them before they reach the survey.
How the exclusion check works
Respondent exclusions are configured at the target group level. You specify which projects or target groups should contribute to the exclusion, and the Exchange checks every incoming respondent against that list at the point of entry.
By default, the Exchange blocks a respondent if they recorded a Complete status in any of your excluded projects or target groups within the configured exclusion duration. You can also target other respondent statuses, such as screenouts and over-quota terminations — see targeting specific respondent statuses. The exclusion uses a rolling window calculated at the moment of entry:
If the respondent's completion falls within the configured duration, they are blocked. Once the duration elapses, that respondent becomes eligible again.
Don't confuse this with live concurrent checks, where the In Client Survey status applies instead — preventing a respondent from participating in two surveys at the same time. See exclusion rule hierarchy for details.
Exclusion rules are evaluated at entry time and reflect your current configuration.
Targeting specific respondent statuses
By default, only a Complete status triggers the activity history check. If you need to exclude respondents who reached other outcomes, such as screenouts or over-quota terminations, you can set which statuses each exclusion targets with the respondent_statuses field on each item.
Each item in your exclusion list carries its own set of statuses and its own duration, so a single source can drive several independent rules. The Exchange treats each entry as one policy, keyed on the combination of type, id, and respondent status, and evaluates them independently at entry time. A respondent is blocked if any rule finds a matching status within its window — the rules never cancel each other out. A respondent blocked by a screenout rule is blocked even if a separate completes rule for the same project would have let them through.
This is how you express different windows for different statuses: list the same source more than once, pairing each entry with a distinct set of statuses and its own duration.
Example: completes block for 90 days; screenouts and over-quota respondents block for 14 days
{
"respondent_activity_exclusions": [
{
"type": "project",
"id": "01KGEYS73VB65016EYR76BWMTP",
"duration": "P90D",
"respondent_statuses": ["Complete"]
},
{
"type": "project",
"id": "01KGEYS73VB65016EYR76BWMTP",
"duration": "P14D",
"respondent_statuses": ["Terminate", "OverQuota"]
}
]
}
When an item omits respondent_statuses, it defaults to ["Complete"], so existing configurations behave exactly as before. On read, each item returns its respondent_statuses explicitly, with one entry per distinct duration carrying the statuses that share it.
For the full list of supported statuses, how to configure them, and the account access requirement for non-complete statuses, see setting up respondent activity exclusions.
If you update the exclusion list while the target group is live, the change applies only to respondents entering after the update. Respondents who entered before the change are not affected.