Introduction to Passwords

Top  Previous  Next

Posting your questionnaire online gives anyone connected to the Internet potential access to your survey.  The potential imposter/repeater problem is well-known.  By default, Lighthouse Studio's password functionality is turned off, meaning that respondents may access the survey as many times as they want.  You can limit or control this problem by assigning passwords within the Questionnaire Access and Passwords dialog.

 

Password Fields

You can require the respondent to type a single or multiple passwords (Lighthouse Studio supports up to 255 characters per password).  You can also specify how many times each password combination may be used to access the survey.  Most of the time, each password combination is specified for single use (Max Respondents=1).  This has two benefits: each respondent may only take the survey once, and if respondents return to an incomplete survey, Lighthouse Studio can restart them at the point they left off.  Restarting is not allowed for a password where Max Respondents permitted is greater than 1 (unless you use Cookies).  Providing respondents with passwords permits them to access just their survey; it does not give them access to other aspects of your Web server, including the stored data.

 

Merged Fields:  Sometimes you already have some respondent data prior to fielding a survey (such as descriptive data for online panelists) and you want this information to be available during the questionnaire to display certain prior-known information or to execute skip patterns.  Lighthouse Studio lets you supply up to 250 Merged Fields (variables) in addition to passwords that will be automatically merged into each respondent's record upon accessing the survey.  Both the Password Fields and the Merged Fields are stored within the same database file.

 

Pass-In Fields:  It is common to "pass-through" data into the survey on the URL link that respondents click to start the survey.  For example, you might be launching a Lighthouse survey from a third-party application and want to pass-through the respondent ID# to be stored as well in the respondent's record in Lighthouse Studio.  You define these Pass-In Fields within the Passwords area.  The number of pass-in fields is only limited by the constraints on length of URL strings imposed by browsers.

 

Cookies:  By default, we do not write cookies to respondents' local drives.  However, you can turn cookies on 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 the cookie).  If you ask Lighthouse Studio to write cookies, they will be used when the respondent could not otherwise be uniquely identified by the password specified to start the survey (e.g. passwords with Max Respondent>1, or no passwords in place at all).

 

User-Defined Passwords:  When this option is enabled, if the password that the respondent uses is not found, the respondent is still permitted to take the survey and the password(s) the respondent used are stored (so that the respondent could restart the survey at a later point if needed).  Case sensitivity is ignored with User-Defined Passwords.  You can employ User-Defined Passwords in addition to pre-defined passwords within the same study.

 

You can use the Questionnaire Access and Passwords dialog to generate thousands or even millions of random passwords, or you can import passwords (as well as Merged and Pass-In fields) from text files.

Page link: http://www.sawtoothsoftware.com/help/lighthouse-studio/manual/index.html?hid_web_passwords_intro.html