Tokens are basically a "password" or an "individual ID". So the survey is technically not anonymous, because you can connect the token with the email address. There is a setting, that allows anonymous surveys with tokens, but that means you can't really send reminders (or have to send them to everyone), because you don't know which token belongs to which email address and which links have been completed and which not. But for the "token based answer persistence" it should not matter whether the survey is anonymous or not.

There are various different settings for surveys with tokens and this can give you quite some flexibility.

1. With token based answer persistence: If someone stops the survey in the middle and returns later, they start where they left of
2. without token based answer persistence: when someone stops in the middle and then goes back later, they will start at the beginning again and you will have various (incomplete) entries for this person.
3. Uses left: This can be used with 1 and 2. You can allow people to complete the survey more than once. Standard is "uses left" set to 1 for every participant at the beginning. When a respondent completes the survey, it goes down to 0. Once the uses left count reaches 0, the respondent can not answer anymore with this token/link. So default is 1, which means everyone can only answer once.
Now if you want people to answer more than once (probably not your case), you can set the uses left to a higher value. Every time a survey is completed with a specific token the count for this token goes down by 1. When it reaches 0, this token / link can not be used anymore by the respondent.

holch wrote: … … There is a setting, that allows anonymous surveys with tokens, but that means you can't really send reminders (or have to send them to everyone), because you don't know which token belongs to which email address and which links have been completed and which not. … …

No,

With token + anonymous : the 2 database are separate : you can't join one with the other.
But : token are “taggued” as completed . When user submit survey : we have the related token value in session (we need it to be sure user have access), and when submitted : completed columns are set to "Y".

No,

With token + anonymous : the 2 database are separate : you can't join one with the other.
But : token are “taggued” as completed . When user submit survey : we have the related token value in session (we need it to be sure user have access), and when submitted : completed columns are set to "Y".

We mean the same thing, I might not have explained myself very clear.

you don't know which token belongs to which email address and which links have been completed and which not.

I think this is the part that was unclear. Of course you know which token was completed. But as you don't know which email the token belongs to, you can not send reminder emails to only those that have not completed yet. You will have to send reminder emails to everyone. That is what I wanted to highlight.

holch wrote: Of course you know which token was completed. But as you don't know which email the token belongs to, you can not send reminder emails to only those that have not completed yet.

Isn't the participants list containing the token, the email-address and the response status?

This should not be the case for anonymous surveys, otherwise it wouldn't be anonymous. But to be honest, I never use the anonymous mode. Anonymous for me is more a internal organization than a technical setting. Would need to check, but I expect that for anonymous surveys the token is separated from the personal data. Because if the token is separated from the results, the token system wouldn't work (you would not be able to control if a token has been used or not).

OK, so I just did a test and the token is always in the participant table. This is a real problem, because the so called "anonymous" survey is not that anonymous at all!

With low response rates it will be pretty easy for a survey admin to find out which response belongs to which token!

You just need to check responses on a regular basis and see which ones are new. Then you go to the particpant table and check which ones have recently gone to "uses left" = 0 and you know who gave the answer.

This is why I think it is important to consider "anonymous" rather an internal process/rule than a technical process. Even with the current technical approach it should be fairly easy, for someone who wants to find out who answered what, to do so. Of course, if you have surveys with responses every few minutes/seconds it might be difficult, but especially for employee surveys, where I think the anonymous part is even more important, it should be relatively easy. If you are evil, you could even send the invitations in very small batches to keep volume deliberately down.

I am not sure if we can actually call the current approach technically anonymous at all. But maybe I am seeing it wrong.

One other thing: even if you can not connect answers directly to a person via my approach described above, even knowing who participated and who did not might already a breach of "anonymity". Especially in small companies you might be able based on responses to determine who answered what, e.g. if you know the area they work in and there are very few people working there.

I am not impressed!

I always thought, that the token would be totally separated from the personal data in this case. I get why it might have been done the way it was done (to be able to send individual reminders). But in my opinion, if you can actually do this, then the survey is not as anonymous as it suggests. At the bare minimum you know who filled in the survey (which according to ESOMAR is already an issue and you should not pass this information on to the end client, for example).

holch wrote: I am not impressed!

You're expecting too much. Just think about how many surveys a LimeSurvey developer has conducted? The average might be a bit over zero.

We should all stay away from big words like "anonymity". Without knowing the questions and the answers you cannot ensure anonymity. Your example with small samples are correct. Asking a question like age and gender can kill anonymity with ease. With the amount of third party data available every question can be the key to identify people in bigger results.

ESOMAR codex won't help. The demand for raw data is killing the research industry ethos. Market research is already seen as marketing by several courts in Europe. So ESOMAR, ADM will no longer have a purpose. The special status of market research is gone.

But to refocus on LimeSurvey:

Instead of assuring anonymity, we will have to explain what and how data is handled. People have to judge for themselves.

LimeSurvey is NOT saving the token inside the results. That's it.

You want to have the TOKEN and/or email removed from the participants table?
The email can only be removed after the invitation is sent.
The token can only be removed after the participant visited the survey or the survey is closed.
Removing the token from the list, contains the same information as currently with "Completed".
Allowing to use external SMTP server under your own control will allow you to save TOKEN and E-Mail-Address.
Some SaaS survey providers are offering certain assurance to respondents that research won't see certain infos.
E.g. www.questionpro.com/security/raa.html

That cannot be implemented if selfhosting is used. But for LimeSurvey GmbH there might be room for improvement.

I'm not sure, if removing an E-Mail-Address after the invitation is sent will be good enough.

As a SaaS provider I would ensure, that people have to use my SMTP-server and hide the status, if a TOKEN is used.
As a reseacher I would never sent invitations via the survey tool. I would always use complete separated systems. That way only a token is in the participants list.

Good idea of separating the email/personal data by sending emails with another tool.

It would be great if we could generate a csv file with token links. Of course you can do it by hand (as I described in the workaround section), but creating a bunch of dummy tokens and then export the links would be great.

holch wrote: Good idea of separating the email/personal data by sending emails with another tool.

It would be great if we could generate a csv file with token links. Of course you can do it by hand (as I described in the workaround section), but creating a bunch of dummy tokens and then export the links would be great.

When needing real anonymous token : i always do like this. Never use information user on token.

One time : token distribution was done with little paper in a hat …
And final client din't have access to database. I‘m the only one with access to DB.

Currently in France : you have to register IP and keep it one year in your log, and what action is done. Then : looking at the id of the response table + log : you have the IP who start to answer to this question … even without token. It's the prooff thet nothing is anonymous … if you host data yourself.

You're right about “it is important to consider "anonymous" rather an internal process/rule than a technical process.“ And a hoster must do exactly the same think than questionpro : Get token completed/not completed in token table, but disable access of this token table to final user …

EDIT : there are an issue in questionpro : “ If the respondent requests his response data to be removed from the servers as a result of the breach” then there are a link between data and email … this link didn't exist in limesurvey even with databreach …

Once the personal data is completely separated from the survey data you will not be able to delete the survey responses, because there is no way to know what there response is. But I think this is OK with the GDPR, because it is no personal data anymore. Of course, if you ask personal data in the questionnaire that can identify the respondent, then you will have to delete the entry manually.

Overall, I think if you don't store personal data for long, if you have the consent of the participants, etc. the chance that someone is asking for deleting personal data is probably pretty low.

holch wrote: But I think this is OK with the GDPR, because it is no personal data anymore. Of course, if you ask personal data in the questionnaire that can identify the respondent, then you will have to delete the entry manually.

GDPR was created with Facebook, Google and Co. in mind. All the other "little" everyday cases are often not really fitting well. Will take time to get the playbook.