| Both sides previous revisionPrevious revisionNext revision | Previous revisionLast revisionBoth sides next revision |
| en:create:personal-code [22.07.2019 20:05] – [Separate Text Input] admin | en:create:personal-code [22.07.2019 20:16] – admin |
|---|
| ====== Request of a Personal Code ======== | ====== Request of a Personal Code ======== |
| |
| The use of a "personal code" for printed questionnaires (pen 'n paper) has proven to be effective in multi-surface surveys. In the first questionnaire, the participant should create a code from the fragments of personal information. This could look like the following: | The use of a "personal code" for printed questionnaires (pen 'n paper) has proven to be effective in multi-wave surveys. In the first questionnaire, the participant create a code from the fragments of personal information. This could look like the following: |
| |
| * First digit: Last letter of month of birth | * First digit: Last letter of month of birth |
| * etc. | * etc. |
| |
| If the participant enters the same code in the second questionnaire, the two data sets can be matched. Above you can see only one illustrative example -- concrete examples can be found, for example, in the following: | If the participant enters the same code in the second questionnaire, the two data sets can be matched. The above example is only for illustration -- actual recommendations can be found, for example, in: |
| |
| > Pöge, A. (2008). Persönliche Codes „reloaded“. Methoden – Daten – Analysen, 2(1), 59-70. [[https://www.gesis.org/fileadmin/upload/forschung/publikationen/zeitschriften/mda/Vol.2_Heft_1/2008_MDA1_Poege.pdf|German version, online available]]. | > Pöge, A. (2008). Persönliche Codes „reloaded“. Methoden – Daten – Analysen, 2(1), 59-70. [[https://www.gesis.org/fileadmin/upload/forschung/publikationen/zeitschriften/mda/Vol.2_Heft_1/2008_MDA1_Poege.pdf|German version, online available]]. |
| |
| An advantage of this solution is that the code guaranteed high anonymity in times before the Social Web and functioned relatively reliably. However, this solution also has disadvantages: | An advantage of this solution is that the code functioned relatively reliably and provided high anonymity in times before the Social Web. However, this solution also has disadvantages: |
| |
| * One typo is enough to make the assignment more difficult. | * One typo is enough to make the assignment very difficult. |
| * The procedure involves a certain amount of effort for the participants, is sometimes perceived as "annoying" and the reference to personal data quickly raises concerns about data protection. | * The procedure involves a certain amount of effort for the participants, is sometimes perceived as "annoying" and the reference to personal data quickly raises concerns about data protection. |
| * If a participant reveals a lot about himself on social networks or if other data sources are available, parts of the personal code can be identified. In a limited population (e.g. students of one year) this is often enough to de-anonymise the data. | * If a respondent reveals a lot about themself on social networks or if other data sources are available, parts of the personal code can be identified. In a small population (e.g. students of one year) this is often enough to de-anonymise the data. |
| |
| ===== Alternatives in the Online Questionnaire ====== | ===== Alternatives in the Online Questionnaire ====== |
| |
| If an online questionnaire is used, further options are available for multi-wave surveys. Every solution is a compromise between data protection and convenience/reliability. The following options are arranged by data protection level, whereby the first and "worst" option already guarantees a good data protection level -- but not maximum data protection. For most purposes, serial mail is the method of choice. | If an online questionnaire is used, further options are available for multi-wave surveys. Every solution is a compromise between data protection and convenience/reliability. The following options are arranged by data protection level, whereby the first and "worst" option already guarantees a good level of data protection -- but not maximum data protection. For most purposes, serial mail is the method of choice. |
| |
| * Using SoSci Survey's [[:en:survey:mailing|mailings]] function, the program assigns a personal code to each subscriber and notes it in the record if the [[:en:survey:mailing#privacy mode|privacy settings]] allows this for the address entries. In the privacy setting "pseudonym" the researcher does not get any information about which code belongs to which address entry -- after deleting the address entries anonymity is reliably guaranteed. | * Using SoSci Survey's [[:en:survey:mailing|mailings]] function, the program assigns a personal code to each addressee and notes it in the data record, if not prohibited by the address's [[:en:survey:mailing#privacy mode|privacy settings]]. In the privacy setting "pseudonymous" the researcher does not get any information about which code belongs to which address entry -- after deleting the address entries anonymity is reliably guaranteed. |
| * With an open text input you can query the participant's e-mail address, on the following page you can use ''[[:en:create:functions:mailsend]]]'' to schedule the sending of the invitation to the second questionnaire and then immediately delete the e-mail address using ''[[:en:create:functions:dropvalue|dropValue()]]''. The return button (if allowed in the questionnaire) should be deactivated at least on this page using ''[[:en:create:functions:option]]'' to avoid accidental storage of the e-mail address. | * With an open text input you can query the participant's e-mail address, on the following page you can use ''[[:en:create:functions:mailsend]]]'' to schedule the sending of the invitation to the second questionnaire and then immediately delete the e-mail address using ''[[:en:create:functions:dropvalue|dropValue()]]''. The back button (if allowed in the questionnaire) should be deactivated at least on this page using ''[[:en:create:functions:option]]'' to avoid accidental storage of the e-mail address. |
| * With a question of type [[:en:create:questions:email]] at the end of the questionnaire you can send an individual link to the second questionnaire (using the placeholder ''%caseNumber%''). The participant has to enter his e-mail address, but it will not be saved. A disadvantage compared to the serial mail function is that the link cannot be sent time-controlled because the e-mail address would have to be stored temporarily. | * With a question of the type [[:en:create:questions:email]] at the end of the questionnaire you can send an individual link to the second questionnaire (using the placeholder ''%caseNumber%''). The participant has to enter their e-mail address, but this will not be stored. A disadvantage compared to the mailing function is that the link cannot be sent time-controlled because the e-mail address would have to be stored temporarily tto achieve this. |
| * Also possible is the [[:en:create:vouchers|display of a random code at the end of the first questionnaire]]. The participant must then note this code and enter it again in the second questionnaire. | * Also possible is the [[:en:create:vouchers|display of a random code at the end of the first questionnaire]]. The respondent must then note this code and enter it again in the second questionnaire. |
| |
| |
| |
| |
| ==== Open Text Input ===== | ==== Open-ended Text Input ===== |
| |
| The first variant is obvious and corresponds to the procedure in the printed questionnaire. You explain to the participant how to create the code and then use a question about [[:en:create:questions:text]] so that the participant can enter the code. | The first variant is obvious and corresponds to the procedure in the printed questionnaire. You explain to the participant how to create the code and then use a [[:en:create:questions:text]] question so that the participant can enter the code. |
| |
| To check at least the correct format, you can define a "regular expression" for the text input question. To do this, click on the input field on the left in the navigation and define a //regular expression// under //restrictions for the text input//. Regular expressions are complex search patterns with exciting possibilities ([[https://www.regular-expressions.info/|regular-expressions.info]]), but at first glance they also look somewhat complex. It's half as bad for the personal code: | To check at least the correct format, you can define a "regular expression" for the text input question. To do this, click on the input field on the left in the navigation and define a //regular expression// under //restrictions for the text input//. Regular expressions are complex search patterns with exciting possibilities ([[https://www.regular-expressions.info/|regular-expressions.info]]), but at first glance they also look somewhat complex. It's half as bad for the personal code: |
| |
| |
| ==== Separate Text Input ===== | ==== Separate Text Inputs ===== |
| |
| It is easier for the participant to query the individual components of the code separately. The format check is also easier. | It is easier for the respondent to fill in the individual components of the code separately. The format check is also easier. |
| |
| * Create a question "Open text input" and as many input fields as your code has components, e.g. an input field (item) "What is the last letter of your month of birth". | * Create a question "Open-ended Text Input" and as many input fields as your code has components, e.g. an input field (item) "What is the last letter of your month of birth". |
| * Click on the input fields on the left in the navigation to select the appropriate option, e.g. "Numbers", under // Restrictions for text input// in the selection //Defined characters//. | * Click on the input fields on the left in the navigation to select the appropriate option, e.g. "Numbers", under //Restrictions for text input// in the selection //Defined characters//. |
| |
| It is not really necessary to display the participant's personal code "en bloc" again, but if you want to do this, use a little [[:en:create:javascript|JavaScript]]. Assuming your text input question has the identifier "PC01" and contains 6 input fields, you would place the following HTML/JavaScript code under the question: | It is not really necessary to display the participant's personal code "en bloc" again, but if you want to do this, use a little [[:en:create:javascript|JavaScript]]. Assuming your text input question has the identifier "PC01" and contains 6 input fields, you would place the following HTML/JavaScript code under the question: |
