Collecting Data From Redirects

This article offers guidance and resources to help you configure redirects effectively, enabling you to collect essential data for tracking performance, incentivizing respondents, and enriching your profiling.  

Please note: This article has been updated to reflect our latest pricing model, replacing cost per interview (CPI) with revenue per interview (RPI) metrics. We will be working closely with our Supply Partners to transition them to the RPI model. If you have not yet migrated to RPI and require access to documentation containing CPI details, please contact your Account Team, who can provide the relevant materials.

Overview

All respondents, that do not abandon their session or encounter a load error, will be returned on one of five redirects set by the supplier.

• DefaultLink

• SuccessLink

• FailureLink

• OverQuotaLink

• QualityTerminationLink

The redirect assigned to a respondent session is based on the outcome within the Cint Exchange (formerly Lucid Marketplace). To determine which redirect applies to each outcome, refer to the "Redirect to Supplier – Standalone" column in the articles below.

• Cint Exchange (pre-screener) Response Codes

• Client (in-survey) Response Codes

Profile and qualification responses collected during the pre-screener, along with additional session activity data, can be appended to the redirect.

The specific data included in the redirect is determined by the values set by the supplier when making a “Create a Link” or “Update a Link” request for the survey.

The following SupplierLinks model properties can be used to define the data returned in the exit link query string for a given survey. Note: There is a 2,999-character limit for these properties.

​​​​​​If values for these properties are not specified when making the “Create a Link” call, the redirects will be reverted to the default redirects provided by the supplier. To make adjustments to your default redirects, either place a submission through the Cint Supplier Portal Redirects Form, or reach out to a member of your Account Team.

Collecting Session Data

The example below shows the format to be used when posting the redirects data you would like to receive. The parameter name is custom and can be selected by the supplier. The parameter value is a “Variable Name” from the table above, encapsulated by square brackets and percent signs.

Collecting Profiling Data

Cint will store all Cint Exchange pre-screener question and response pairs that pass through our system for up to 30 days. This data is collected via the respondent answering a pre-screener question or the data passed in by the supplier on the entry link.  To enrich their profiling, suppliers can request that this data is appended to exit links.

If you are setting your redirects when Creating a Link, in our developer documentation you'll find an example of the request body used to post redirects for a particular survey. The example shows the format to be used when posting the redirects data you would like to receive. The parameter name should be the question id defined in Cint's Questions Library and the parameter value is the question name defined in the Questions Library, encapsulated by square brackets and percent signs.

Please inform your Account Team of any additional question ids you would like us to add to your default redirects.

Multi-Punch Formatting

Multi-punch question responses are returned as a single parameter and value. In this format, a '1' in the string represents a selected option, while a '0' represents an unselected option. The position of each number in the string corresponds to the order of the precodes listed in the Show Question Options response.

Example:

639=10010000000 (for the STANDARD_PETS question, the options cat and fish were selected).

Collecting and Validating the Hash Signature

All redirects returned to our Supplier Partners will include a hash signature appended to the URL, generated using the Suppliers secret key. It is crucial for our Supplier Partners to validate the hash signature on all redirects, as an incorrect signature may indicate potential fraudulent activity.

Before soft launching your integration, we require our Suppliers to be able to validate hashing on redirects and appropriately handle invalid hash signatures. For detailed guidance on this process, please refer to the Link Security section of our Partner Security Guide. Additionally, you can learn more about URL hashing in our SHA-1 Hashing article.

Example Complete Redirect with Hash Signature:

https://example.com/success?PID=123456&MID=123456-987456&RPI=1.2&LOI=5&INITIAL_STATUS=3&CLIENT_STATUS=10&SURVEYID=4125512&42=30&43=1&45=90210&hash=F_9ZEbqio6VoM5jFMeb3qpNeTi4

Best Practices

• The PID, MID, and RID identifiers are added to all redirects. Collecting these parameters will facilitate respondent tracking and streamline troubleshooting.

• It is recommended that the InitialStatus and 'ClientStatus' session parameters are collected. They are useful in determining if a respondent has been terminated in the Cint Exchange pre-screener or the client survey. This can be useful in monitoring termination rates at a more granular level.  

• Collecting the TermedQuotaId and TermedQualificationId is recommended. These properties can provide additional insight into the reason a respondent was terminated which can be useful when troubleshooting.

• When selecting the parameter name you would like to use do not include any special characters other than - or _ to avoid breaking a URL.  Additionally, we recommend using a parameter name that requires minimal characters to allow for the maximum amount of data to be collected within the character limit for the property.

• Because of the character limit of 2,999, for the redirect properties, you will want to be strategic about what data you choose to append. Consider prioritizing the most commonly used data points for which you are not already profiling your respondents.

Updating Redirects

If you wish to update your redirects there can be several changes required:

1. Cint will need to update the default redirects stored in our system.  Please inform your Account Team of the required changes.

2. Changing the default redirects will not automatically update survey redirects that have been set prior to the change. The Update Links call will need to be made for any active survey where the redirects have already been set via the Create Links call.

3. Amend any custom redirects you are specifying within the payload of the Create Links call for a survey.