A significant, yet common problem faced by researchers is that of “ghost completes” – incomplete surveys that register as completes, caused by ‘survey jumpers’ who manipulate the survey URL to jump to the “survey complete” page, bypassing the rest of the questionnaire.
To overcome this problem, Borderless Access has rolled out a quality-control mechanism in the form of Server-2-Server (S2S) Postback. This mechanism remedies the problem by ensuring a secure, real-time exchange of survey status information between the sample buyer’s systems and Borderless Access’ Panel Management System (PMS).
Read through the following FAQs to understand all about Borderless Access’ implementation of S2S postback and how you as a client can incorporate on your end.
What is S2S Postback?
S2S Postback is an ‘https-POST’ message that is triggered by the sample buyer’s survey set-up, to share status parameters with the sample provider’s set-up (in this context, the Borderless Access PMS). Tracking these parameters enables accurate monitoring of the progress of fieldwork, while also flagging what are commonly called ‘ghost completes’ or ‘survey jumpers’.
Why is Borderless Access implementing S2S Postback?
As a secure, server-to-server data exchange mechanism, S2S Postbacks represent the most reliable approach for tracking progress of fieldwork.
S2S Postback messages are not visible to human users, thereby removing the possibility of survey respondents manipulating survey URLs with the intent of claiming false completes.
What are the benefits of S2S postbacks?
S2S postbacks offer the following benefits:
- Secure, real-time reconciliation of survey status of respondents
- Real-time flagging of respondents who are likely to have completed a survey by manipulating survey URLs
S2S postbacks are increasingly becoming the industry standard mechanism for exchange of survey status parameters between sample buyer and sample provider.
How does S2S Postback work?
S2S Postback involves the sample buyer’s system firing an S2S POST message through an API call, with the respondent status parameters passed as values to the Borderless Access PMS. The S2S Postback connect happens in addition to the redirect.
The parameters tracked through these POST messages include completion status (‘complete’, ‘terminate’, ‘quota-full’ or ‘quality fail’), unique identifiers (‘panellist ID’) and other survey session specific parameters.
When implemented, S2S Postbacks enable the sample buyer’s systems to electronically confirm directly to the Borderless Access PMS that a respondent who lands on one of the end-pages of a survey, has actually gone through the survey within the bounds set by its design. This helps in distinguishing ‘jumpers’ from genuine respondents, resulting in high quality survey data.
More importantly, there will be no change in the way the redirects are set-up at the sample buyer’s end. If static redirects are already in place, these will continue to remain unchanged.
S2S postback implementation
Architecture:
The only change in the set-up is the API call triggered at the sample buyer’s environment to the Borderless Access PMS, with the associated workflow marked by the red dashed border.
Implementation:
The first step in the implementation of S2S postback is to include a code snippet in the respective survey end-pages (for ‘Complete’, ‘Terminate’, ‘Quota-full’ and ‘Terminate’) at the sample buyer’s end. When a respondent goes through a survey and lands on one of these end-pages, this code snippet invokes an API call to the Borderless Access PMS, and passes back the values of the progress tracking parameters.
The API URL, and the code snippet are captured below:
API Link: https://www.api.thepanelstation.com/api/surveys/poststatus
Method: Post
Request:
{
"apiKey":"apikey",
"uniqueId":"uniqueid",
"status": statusid
}
API Key (only for example): xZOzDGhMvTKT02UXBBnEFKlcrntsxfMu; datatype=String
Unique Id: <Panellist ID>; datatype = String
Status: 1 / 2 /3 /4; datatype = Integer
Status ID description:
- Complete
- Quota full
- Terminate
- Quality failed
Once the code snippet is included in the respective end-ages at the sample buyer’s end, the set-up is complete.
The actual postback happens in two stages:
When a respondent clicks on a survey: Whenever a user clicks on a survey from an email template or website, a Unique ID is generated. For S2S post back tracking, it is necessary to pass this Unique ID to the client system through the survey URL.
When the user reaches a survey end page: When the user completes a survey (or hits quota-full or is terminated), the client system passes back the value of this unique ID that was previously sent, via S2S POST message, along with the redirect, to confirm the status of the respondent.
In a scenario where a respondent tries to hit an end-page directly without going through the survey, no S2S Postback is generated.
Why would I still need redirects in addition to S2S Postback?
S2S Postbacks are required for exchanging survey status data between the sample buyer and the sample provider. However, redirects are in place to let the respondent know what happened to the survey that he participated in. In addition, panels providers typically use the redirect pages to further engage with respondents post completion of the survey (gamify, confirm the rewards points he/she received from their survey attempt, etc).
What next?
Setting up S2S Postbacks is easy. You may get in touch with your point of contact at Borderless Access for further assistance.
You could also write to:
techsupport@borderlessaccess.com
Kannan Sankaran: kannan.sankaran@borderlessaccess.com
Ashwin Anandram: ashwin.anandram@borderlessaccess.com
