Participant token permissions and settings at the survey level

The following settings are found under the Token panel when you select Survey Properties->General Settings & Texts.

The settings change the handing of participants/responses, when you are use participant management:

  • Anonymized responses?: This allows you to determine whether responses to your survey are matched up with information from your surveys tokens table, or kept 'anonymous'. The default is 'No'. If you choose 'Yes' then your survey is set to radically anonymize responses - there is really no way to connect answers and participants. Even the admin can't link response data and participant/token data. However you will always be able to specifically view each response entered by your participants in the survey. Thus individual, but anonymous, statistics is still possible to do.

    Note:
    : If this feature is activated the response submission date and the token completed date are always set to 1980-01-01 00:00, no matter of other settings. Why? Invalidating the submission date ensures no match with web server logs where the token key might show up when a survey is started. Invalidating the token completed date makes sure that you can't align the order of submitted responses to the order of the token date/time.
  • Enable token-based response persistence: If your survey uses tokens and your responses are not anonymized, you may want to enable this feature. If you turn this on, your participants will be able to leave the survey and resume later at any time without using the 'Resume later' function - for example if they get distracted or their browser crashes. Upon clicking the invitation link again, they will find their survey answers still in place when they return to the survey, and will even find themselves on the same page where they were before leaving.
  • Allow multiple responses or update responses with one token?: Default: No. If you activate this setting, participants will be able to return to their survey by clicking the invitation link, even if they have already submitted the survey. If the survey is anonymous or "Enable token-based response persistence" is set to NO, this will add a new response. If the survey is not anonymous and "Enable token-based response persistence" is Yes, the user will update the existing responses.
  • Allow public registration: If you use tokens to control access to your survey, the only people who can use the survey are those who have an entry and a unique token from the token table. If you would like to use tokens, but also allow public registration, set this to "Yes".  The "Yes" setting will allow a visitor to register his name and email address. The script will create a new entry in your tokens table for this person, then send them an invitation email. The script will ensure that only one person per email address can complete your survey.
  • Use HTML format for token emails?: When set to yes, all emails sent by the token management interface (invite, reminder, confirmation) will be formatted as HTML. You'll then be able to use rich formatting for this emails. Default is Yes at survey creation. Caution, when you switch on/off this feature, you'll have to double check that your email templates are still displayed as you want.
  • Set token length to: Usually you don't need to change this, the default setting of 15 digits (max. supported value: 35) is fine. If changing this setting please enter a number (X) which should be greater than 5 (if the number entered is <5 it will be converted to the default value of 15). When generating tokens all tokens will use a length of X digits.
Also, found under Publication & access control are several options that control survey access:
  • List survey publicly: WIll show the survey on the landing page of your survey account (like http://demo.hostedincanadasurveys.ca)

  • Start date/time: If a participant uses your survey link prior to this date/time, they will not be able to start the survey

  • Expiry date/time: If a participant uses your survey link after this date/time, they will not be able to start the survey

  • Set cookie to prevent repeated participation: This will prevent a participant from participating in the survey more than once. Note you need to be aware that if you are testing your survey, participants may not be able to test your survey more than once unless they delete their cookies associated with your survey domain

  • Use CAPTCHA for survey access: Requires participants to complete a CAPTCHA prior to starting the survey

  • Use CAPTCHA for registration: Requires participants to complete a CAPTCHA when they register to access your survey (when you have Public registration enabled under Tokens)

  • Use CAPTCHA for save and load: Requires participants to complete a CAPTCHA opt to save their response and return late.
246 of 517 people found this helpful.   




Powered by LiveZilla Customer Support Software