S2S is a more secure method of transferring information.
To use this feature:
Cint has provided premade tools that you can utilize.
-or-
You can develop your own API.
See below for more information.
What is an S2S redirect?
A server to server (S2S) redirect is made between two servers, as opposed to the redirect within the respondent’s web browser. With S2S redirects your server can communicate with Cint server and register the final status of respondents.
How is S2S more secure?
Browser (Generic or Project-Specific) redirects as a method of transferring information may not be fully secure because the panellists can manipulate and change the link.
With S2S, the actual redirect is only used for transporting the browser session - everything else (assigning the final status to the respondent) happens “behind the scenes”. The final status of a respondent (e.g. complete, screenout, etc.) is done with an API call which happens directly between Cint and your systems.
This way this information is never exposed to the respondent and as a result, they can’t intervene in the flow.
How is it configured?
For S2S to work with your projects, you will need to have an API key with the right permissions to set the statuses from Cint. You can get the key details and more information by contacting your Cint representative. The process consists of 2 actions:
1. Redirect respondent’s browser back to Cint
The return URL is always the same as it is only used to return a respondent. It will also contain the respondent’s GUID (instead of using respondent cookies) that will be used to identify a respondent once they come back to Cint.
2. Make an API call to register the respondent’s status (e.g. complete, screenout, quota full, etc.)
This way the tokens for completes can no longer be manipulated. The fraudsters will not be able to see the token in the browser and therefore will not be able to manipulate them to score complete (therefore preventing the “ghost completes” and other system cheating approaches).
Will S2S work if I use unique links?
Yes. In order for S2S to work correctly, the Cint Respondentguid must be passed through the API. This will work regardless of unique or dynamic links:
-
Dynamic links: Same URL syntax used ("username/password" or "survey tool GUID" are the same for each link) and just add respondentguid
-
Unique links: Each link has unique "username/password" or "survey tool GUID". We can still add out respondentguid to the URL.
Make sure when you upload the links that you can add an additional variable that the survey tool captures and passes on in the S2S call back to Cint.
How can I use this feature?
There are two options to set up and start using secure redirecting:
1. Use one of the Cint system compatible surveys tools, which support this feature. You will not need to develop anything on your side and still have the opportunity to use S2S redirects without building any API connections. You may need to pay a license fee to use this as part of the survey tool contract. A few example survey tools that already support this:
- Confirmit (instructions pending)
- More to be added...
2. You can choose to develop your own API. You don’t need to develop the whole API, but instead can only build the part for the “Fulfillment” part. More details can be found on our developer's portal: https://cint-demand-api.readme.io/docs/respondents-response-statuses
Please reach out to your Cint representative for more information.
Comments
0 comments
Please sign in to leave a comment.