Cookies are pieces of text sent between the server and respondent's device. The text is stored in a file on the respondent's device in a folder reserved by the browser for storing cookie information. By default, Lighthouse Studio does not write cookies to respondents' devices. However, you can turn cookies on using this dialog, and if respondents do not block them (through their browser configuration settings), they can be used to restart incomplete questionnaires. The cookie will also keep a respondent from completing more than one survey (unless, of course, the respondent disables cookies or deletes the cookie).
If cookies are enabled within your Lighthouse study, when the respondent accesses the survey, a cookie is written to the respondent's device that records the respondent's internal respondent ID and starting time. The cookie never expires. If a respondent logs into a survey and Lighthouse Studio cannot uniquely identify this respondent (because of passwords with Max Respondents>1, or because the study doesn't use passwords), the cookie information is read by Lighthouse Studio to identify and restart the respondent (or to determine that this respondent has already completed the survey). If all your passwords are unique per respondent (Max Respondents=1), then there really is no sense in turning cookies on, as they would never be needed to identify a respondent.
Remember, cookies cannot guarantee that respondents can restart an abandoned survey or that respondents cannot complete multiple surveys from the same device. Respondents can disable and block cookies. Some respondents may have configured their devices (or anti-virus software) to warn them when there is an attempt to write a cookie to their hard drives. Such respondents may be negatively inclined or even suspicious of your survey if they receive such a warning.
This option lets respondents create their own password(s) to access the survey. All respondents are allowed into the survey, and returning respondents will be able to restart their survey where they left off if they provide the same password.
You can employ User-Defined Passwords in addition to pre-defined passwords within the same study.
To enable User-Defined Passwords, from the Questionnaire Access and Passwords dialog, Settings tab, check Allow respondents to define their own passwords.
Min Size (characters) lets you control the minimum number of characters that may be specified for User-Defined Passwords.
If you specify a minimum number of characters, you should warn respondents in the login instruction text regarding the minimum characters required. Also, you should modify the default Invalid Login error message that currently says: "Invalid Password/User Name. Access denied." to include a tip that the passwords must have at least a certain number of characters (edit the error message from the Survey Settings | Error Messages tab). Otherwise, respondents trying to access the survey may not know why they are receiving an error message.
•Numeric user-defined passwords may not be larger than 999,999,999.
•Numeric user-defined passwords may not begin with a 0.
•Numeric user-defined passwords may include a single decimal point.