Skip to main content
Version: 2025-05-27

Understanding the respondent journey and status management

This article provides a conceptual overview of how respondents navigate between the Cint Exchange and your survey platform, and how their statuses are securely managed using redirection and status feedback loops.

What is the respondent journey?

The respondent journey describes the entire flow a survey participant takes. When you launch a target group and it's status changes to live, respondents that make it through the prescreener (by matching your specific profiling requirements) are sent to your survey platform of choice. Once they complete your survey (or terminate), they are redirected to the Cint Exchange. All along the way information is shared across platforms.

This journey is managed primarily through:

  • Redirection: Participants progress via HTTP redirects to different webpages.
  • URL Query Parameters: Respondent and session-specific information is passed through URLs using query parameters.
  • Session status: The final outcome of a respondent's survey attempt is securely communicated back to Cint.

A diagram of the respondent journey

Through this process, we can ensure:

  • Accuracy in Invoicing: Only qualified and valid completes are billed, by allowing you to remove poor-quality respondents.
  • Data Integrity: Reliable data on respondent outcomes.
  • Supplier Quality Improvement: Cint utilizes this feedback to continuously enhance supplier quality and improve automated security tools.
  • Risk Mitigation: Secure methods reduce risks associated with:
  • "Ghost completes" (respondents falsely marked as complete).
  • Manipulated URLs.
  • Interference from browser plugins affecting redirects.
  • Internet connection issues during client-side redirects.

Key components of respondent status management

Respondent identification (RID)

Every respondent is assigned a unique session identifier by the Cint Exchange before being redirected to your survey. This identifier is known as a response ID (RID).

  • How it's passed: The RID is typically included as a query parameter on the survey entry URL.
  • Syntax: We use the following syntax: https://www.example.com/survey?rid=[%RID%].
  • The [%RID%] syntax is a placeholder that Cint automatically replaces with the actual, unique response ID (e.g., a 36-character alphanumeric UUID) when the respondent is sent to your survey. There are other parameters that can be used to transmit additional information to your survey platform.

Mandatory return redirects and statuses

Upon completion of the survey or once a participant reaches a determined outcome within your survey, it is necessary to redirect them back to the Cint Exchange. These redirects use a set of standard URLs and are associated with four possible survey end conditions:

  • Complete: The respondent successfully finished the survey and met all criteria.
  • Terminate: The respondent was screened out (e.g., did not meet qualification criteria) or dropped out of the survey.
  • Overquota: The respondent qualified, but the specific quota for their demographic segment within the target group was already filled.
  • Quality terminate / security terminate: The respondent was flagged for poor quality, suspicious behavior, or other security reasons.

Secure status transmission

The final status of a respondent must be transmitted back to Cint through a secure method to ensure accuracy and prevent tampering. There are two primary secure methods for this:

  • Secure hashed redirect: A method where the status information is included in the redirect URL along with a cryptographic hash to ensure its integrity. For details on implementation, including code samples, please review https://hash.lucidhq.engineering/.
  • Server-to-server (S2S) API call: A direct, secure communication between your server and Cint's server, where the status update is sent via an API call before the respondent is redirected. This is the recommended and most robust method.

Your Integrations Consultant will provide guidance and support on the specific implementation and testing of the respondent flow that best suits your setup.