Hello,

I am using Lime Survey Version 3.22.15+200505. We want to collect contact details from respondents such as (E-Mail or postal adress) and also answers to the survey itself. Is it possible with Lime Survey to collect email or postal addresses (e.g. to provide bargains or special prices) in a different dabatabase to avoid the consolidation of this data with that of the questionnaire dataset?

In brief, we want to separate contact details from the rest of the survey answers, so that the survey answers are anonymous. Thanks in advance.

Token + Register + anonymous

Thank you for reply. Could you please explain a bit more, that would help!
Do you mean yes it is possible to collect separately email from other survey data using a token...
Is there available somewhere in the manual or any other place a detailed explanation about this?

To explain Denis' short answer.

Create a token based survey with user registration and set it to anonymous.

Joffm

Thanks @Joffm ,

and for @ksemmler : maybe you can click on the link ?

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 allocated in the survey participants 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 survey participants 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.

We do a manual, i give the link … but did you read ?

Thak you so much Denis.
Thank you also to Joffm.

I did a click on "Register" and I understand that tokens are very useful to control who answers the survey and therefore protect the data collected by making sure you only get answers from those who were invited. You control the access to the survey.

In my case, the issue goes in the direction of data security. We want to collect some data such as E-Mail, Name and Postal Adress, which is not and cannot be anonymous, and we also want to collect other data from the survey itself. You can see this as a survey in two parts. We want to separate the first part from the second one and keep the second one as anonymous. Is this possible with Lime Survey?

Other software tools enable to do this, that means "to store email addresses in a different database with no possibility to consolidate the address with the original questionnaire dataset".

This is still unclear for me.

It's exactly what anonymous survey with token, allowing register do …

Just add the postal code attribute, and it's done …

See : www.limesurvey.org/manual/Participant_se...Anonymized_responses

As Denis says:

Tokens + register allow the collection of some data during the registration process. This data is not stored in the response table but in the token table. So, the first step is done, but you can still connect the response data with the registration data.

Therefore you set the token based survey to anonymous. So the respondent needs to register his data, but then the data that is registered in the token table can not be connected to the responses in the response table. Exactly what you want.

Only problem: You can't position the questions with the personal data where you want to. It needs to be at the beginning, during the registration process.

Another option would be to create two surveys and one survey redirects to the other survey via END URL. Then you could position the collection of data also at the end.

But, anonymity is not necessarily a purely technical construct. 100% anonymity WITH collecting persona data is very difficult (if not impossible) to achieve.

For years we have run anonymous surveys in market research, but we had personal data of the respondents, e.g. to invite them via email, or to send them incentives, etc. What we do is to separate the personal data from the response data when it comes to analyzing the data, thus the data is analyzed anonymously.

Thank you Denis for the link and for your confirmation.

Thank you so much for this detailed explanation Holch. It is really helpful. I appreciate very much the support I got from this Forum. I totally agree 100% anonymity is nearly impossible. What you explain at the end is exactly what we want to do (separate those 2 types of collected data).

PS: According to the GDPR: "If data is in any way identifiable, or can be connected to the user (directly or indirectly), the data collection process cannot make the claim of being anonymous".

According to the GDPR: "If data is in any way identifiable, or can be connected to the user (directly or indirectly), the data collection process cannot make the claim of being anonymous".

That is why we only claim the analysis to be anonymous, because obviously there is a way to connect the personal data with the response data if someone maliciously wants to do so.

However, there are many solutions that claim "technical anonyous data collection", but there are often ways to get around this.

Especially with smaller data samples it is especially dangerous. Open ended questions are also a danger zone, because depending on the answers you can often know who the person is that answers. Or if you ask people from smaller groups within the sample.

So now you know that there are 2 people in a specific department. One of them gives a low rating for the office temperature and as HR manager you already know that Mrs X is always complaining about the office being too cold, while Mrs Y has previously been very happy with the office temperature. From now on you can be basically 99% sure that those answers come from Mrs X, rather than Mrs Y.

Or you send the invitation out in batches. Let's say batch 1 is sent at 1pm and batch 2 is sent at 5pm. Now you know, that all responses between 1pm and 5pm are from batch 1. Depending on the batch size, answers, etc. you can make a lot of assumptions and "de-anonymize" data that seems to be anonymous.

I just wanted to say that even processes that claim total anonymity can be misused, if there is maliscous intention. Therefore anonymity is also always connected to trust. If you take the definition that you posted very literal, I am sure many, many solutions that claim to collect data anonymously are lying. Because with a little bit of effort, often you can find ways to connect response data with a specific person.

But you are totally right: in the case that I described in my previous post, we can't (and don't) claim that the data can not be connected, we can just promise that the personal data will never be connected with the response data, even if we could.

Hello Holch,

I totally agree and thanks again for your detailed feedback.

I am wondering how to get around to conduct follow-up studies if we develop a token based survey. If we set the second survey anonymous, can we still connect the data collected to the respondent to make a second study based on the responses of the first one?

ksemmler wrote: I am wondering how to get around to conduct follow-up studies if we develop a token based survey. If we set the second survey anonymous, can we still connect the data collected to the respondent to make a second study based on the responses of the first one?

If you do this : it's not anonymous …

As Denis says, if you could pass some kind of code in the invitation to connect survey 1 with survey 2 you have breached the "technical annoymity", because you are able to connect persona data (the email) with response data.

There are some ideas that technically would allow you to do what you are trying to do, but in practice I think they won't work.

E.g. you could create a code for each respondent in survey 1 and present it to them at the end and tell them to store /save it somewhere for the second survey. But you know that a lot of people will not find the code or will not even bother to search for the code anyway, so in theory this could allow you to connect the two response tables without connecting it to personal data. But in practice it won't work.

Maybe you could allow them to create a codeword themselves that is stored in survey one and then they need to put it also in survey 2. The chance that they remember it is probably slightly higher than for a random code, but it is probably more difficult to match later and there is a certain risk that the same codeword appears more than once in the first survey. So also not a good solution.

If you need to connect responses from survey 1 with survey 2, I don't see much alternatives than to "break" technical annonymity and promise to analyze anonymously.