Skip to main contentSurveys represent available survey opportunities for which a respondent may attempt to complete.
Constructing Entry Links
The first step in creating a survey is to construct the link to which a respondent will be redirected when entering your survey. Typically this is a direct link to the survey platform (Qualtrics, Alchemy, 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.
Additional respondent qualifications and session data can also be passed via the entry link query string. All qualifications returned by the Qualifications endpoint can be appended to the entry link using the following format:
variableName=[%QUALIFICATION_NAME%]
where “variableName” can be customized, and “QUALIFICATION_NAME” is the name 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=[%AGE%]&respondent_gender=[%GENDER%]&respondent_ethnicity=[%ETHNICITY%]
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=1&respondentGender=2&respondentEthnicity=7
where the qualification values represent the ID of the qualification option as detailed in the Qualification endpoint.
It is highly recommended to append all qualifications to the respondent entry link which are being used as targeting criteria for the survey. In order to optimize the respondent experience, and therefore respondent conversion, it is highly recommended to forgo asking respondents to answer similar qualifications questions within the survey, and instead utilize the values passed in the entry link.
Implementing Redirect Links
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. 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. SAME AS SECURITY
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.
Creating Surveys
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.
Soft & Full Launching
It is highly encouraged to implement a standard soft launch mechanism to your survey creation workflow. Soft launches typically consist of setting the survey to Live with quotas defined as 10% of the desired quotas. It is encouraged to poll the API every 10 minutes to compare respondent entries and completed sessions with those reported by the survey platform. Additionally, it is encouraged to analyze quota attribution during the soft launch.
If problems are identified at any time during the soft launch, the survey may be updated to a non-live status using the available PATCH method to prevent respondents from entering during the troubleshooting process.
Once the survey is determined to be properly functioning by automated or manually processes, the PATCH method can be used to update the survey quotas to the full number of respondents desired.
Analyzing and Updating Surveys In-Field
The Research Desk Demand API represents half of a marketplace, with the other half being integrated panels which match their respondent to your survey opportunities. In an effort to ensure positive respondent experiences, panels make matching decisions based on a balance of survey length, incidence rate, required qualifications, and compensation being offered. It is encouraged to poll the API every 10 minutes to monitor the number of respondents entering your survey and determine if entry frequency meets expectations. If not, and the cause is reasonably determined to be a function of compensation being offered to respondents, it is encouraged to increase the compensation in increments of $0.25.
Closing Surveys
Once a survey has completed fielding, it is encouraged to update the survey status to “Complete” using the available PATCH method for the Surveys endpoint. After data analysis, insufficient survey responses can be reconciled using the available PATCH method for the Responses endpoint; if required, the survey quotas may be increased and the survey can be set back to Live in an effort to obtain additional responses. 