holch wrote: If the survey is not extremely long, I would just not offer this option. I think this only really makes sense when the survey is pretty long.

Sadly, it is - takes around 70-90 minutes to complete and includes a task that should be done on a larger screen than a mobile phone (which we point out in the invitation mail, but how many people really read that one?). Therefore, we want to give our participants the chance to stop and resume later, be it becaus eof time constraints or to switch to a device with larger screen (ideally a pc).

holch wrote: I guess, this pretty much depends on the eye of the beholder. When is putting an email* and a password a registration, when not? *I know that the email is not necessary, but still. It is there and people can put it.

To be on the save side I would consider it a temporary registration, deleted after a certain time. But as I said, this depends very much on how the GDPR defines "registration".

If the email adress is not given, it appears to me that this "pseudo registration" includes no personal data and therefore should not be a problem, correct?
Because we already have the participants' email and their consent to use it for the purpose of contacting them (e.g. for the invitation mail) and matching their data from different surveys (longitudinal design) together.

I'm thinking about wether this could save us the trouble of putting the registration section in our policy (as they do not give us any additional/"new" personal data) - especially because I don't know how to comply to the regulation that users have the right to change their registration data. I have no clue if this is even possible, and, if it is, how.
Does anyone know this? If I'm able to complete that section with all neccessary information (possibility of changing is the last one missing), I'd probably include it then, just to be on the safe side.
Because sadly my research on definitions of "registration" led to no avail, which could've clarified whether this counts as registration or not...

DenisChenu wrote: I spoke for LimeSurvey settings : manual.limesurvey.org/Notifications_%26_data

Ah, I see! I'm pretty sure those are all switched off in our survey (except for "may save and resume later", obviously), but I'm going to find out before uploading the policy and starting the survey.

Wow, 70-90min is a lot. I assume you have a good relationship with those people or you pay them a lot of money to do this. Of course, in this case the save and resume makes sense.

However, if you invite them via email and use tokens, you could solve this via token as well. If they stop at a certain point and then come back, if you have made the right settings (I think you need to use "token based answer persistents" or what it is called), then they just click on the link again and will start from the last page they submitted.

We do hope so - in the previous iteration of the project, this went actually pretty decent.

Hm, I haven't thought about using tokens, as I did not know what they are/do - but this sounds very useful. I'm going to ask our survey admin when he returns from holiday whether we use individual invitation links (which I guess is needed for this, otherwise it would not be possible to continue on another device). In that case, token based answers sound very helpful - if we do not open another pandora's box with this?

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.