Skip to main content
A Survey represents a specific fieldwork configuration within a project. Each survey links to one survey URL with one specific country and language target. Also defined at the survey level are the sample specifications, specific audience targeting, quotas, etc.

​
Creating a Survey in Research Desk

A number of parameters are required when creating a survey, and constrained parameter options are returned by the Definitions endpoint. For surveys being created as a result of user action, it is encouraged to create the survey in a non-live state and present the user with a final verification of the survey details before defining a status of Live. Quotas must be defined when creating a survey, and are constructed using the available qualifications as returned by the Qualifications endpoint. Respondents which meet all of the qualification criteria will be counted toward the defined quota upon completion of the survey. Please note that it is possible to create combinations of qualifications which prevent respondents from entering your survey, such as requiring a respondent to be unemployed while having a job title. Please see the Create Survey section for an example of a survey setup API call.

​
Constructing Respondent “Entry Links”

The first step in creating a survey is to construct the link to which a respondent will be directed to in your survey platform. Typically this is a direct link to the survey platform (SightX, Qualtrics, Alchemer, Decipher, etc) but may also be defined as any solution your company may be using. When defining a respondent entry link, the Response ID must always be appended to the query string and serves as a session identifier. The variable for Response ID is “[%RID%]” and can be placed anywhere within the query string. This variable value must be captured within the survey and returned when redirecting the respondent back to the Research Desk system.

​
Appending Qualification data to the Respondent Entry Links (optional)

Respondent Qualification data and session data can also be passed via the entry link query string. This step allows your survey platform of choice to consume and store the incoming respondent data. All qualifications returned by the Qualifications endpoint can be appended to the entry link using the following format:
  • &variableName=[%Q_<qualification_id>%]
In the above example “variableName” is a variable that can be customized in your Programming Platform to receive and store the data we pass to you, and “qualification_id” is the ID of the qualification as returned by the Qualifications endpoint. For example, the following URL represents an entry link which would redirect a respondent to a Qualtrics survey with age, gender, and ethnicity appended: https://qualtrics.com/survey/123?responseID=[%RID%]&respondent_age=[%q_1%]&respondent_gender=[%q_2%]&respondent_ethnicity=[%q_8%] The above example could result in the following generated entry link for a specific respondent entering your survey: https://qualtrics.com/survey/123?responseID=xxx-yyy-zzz&respondentAge=18&respondentGender=2&respondentEthnicity=7 where the qualification values represent the answer ID of the Qualification question option as detailed in the Qualification endpoint. In order to optimize the respondent experience, and therefore respondent conversion, it is generally recommended to forgo asking respondents to answer similar qualifications questions within the survey, and instead utilize the values passed in the entry link. After creating a survey using the Surveys endpoint, respondent redirects will be generated by the Research Desk Demand API and returned in the response body. These links serve as the destination for the respondent after the survey session has ended, and represent the following session statuses:
  • Complete: when a respondent is redirected back to the Research Desk platform using the Complete URL, the respondent session will be stored as having successfully completed the survey and thus costs will be incurred. This redirect is required to be implemented.
  • Standard Termination: when redirected using the Standard Termination URL, the respondent session will be stored as terminated for generic reasons (e.g. screening questions). This redirect is required to be implemented.
  • Quality Termination: this redirect signals that the respondent is of poor quality and helps Research Desk panels provide higher quality respondents moving forward. Although implementation is encouraged, this redirect is not required.
  • Security Termination: this redirect signals that the respondent is suspected of cheating or other unacceptable behavior. Implementation is encouraged but not required.
  • Overquota Termination: this redirect signals that the respondent was attributed to a quota which has since been met. Implementation is encouraged but not required.