Hello! My team and I are planning a big academic study that will include many participants.

When we tried to pre-test our survey, we found out it was too large to be activated. We now face a tough choice, and we would like help on what will happen when we make the final decision:

1st option: we split the survey in two in the middle, or in 3 parts, if it's still too big.

2nd option: we split it according to different profiles of the survey participants, which they initially chose by answering filter questions in the survey's introduction.

Our questions are :

1. How can we make the surveys linked to one another? For the moment, we want our participants to register before receiving a token to answer the survey. Could we make it so that the participants can fill the surveys sequentially without needing a new token or to register again? Other post on this subject didn't seem to have the same particularities as us. Should we just make the second survey open-access but add a link only for those who have filled the first part (in the end message, for example)?

2. If we do this, would their results still be associated with their created profile? We'd really need the data to be linked to the same participant..

3. Will our conditions update themselves if we split the survey in two? For example, will an answer selected in the first survey still have an impact on a related condition in the second survey?

Separating the survey in multiple profiles would fix this last issue, but require a lot of work: instead of the conditions we already built, we'd manually add/remove the relevant questions to each profile. We'd prefer the first option if it's not too complicated...

We are new to Limesurvey and are having issues understanding the advanced features we need to create our survey.

We are using Limesurvey 3.8.1 without plugins.

Thanks!

1) You can link the surveys via the End URL. Having said that, if you want registration in the first survey and also token restricted access to the subsequent survey(s), you will need to use the API to create matching tokens in the subsequent survey(s). The token can then be appended to the End URL for seamless access to the following survey(s).

2) Yes, assuming the surveys are non-anonymous, they will use the same token for all surveys which can be tied to the response sets for analysis.

3) No, the subsequent surveys cannot directly see data from the first survey. You will need to pass relevant answers to subsequent surveys by pre-filling hidden questions via the URL.

Some pertinent links...

- Prefill answers: www.limesurvey.org/manual/URL_fields/en#...using_GET_parameters
- End URL: www.limesurvey.org/manual/Text_elements
- RemoteControl 2 API: www.limesurvey.org/manual/RemoteControl_2_API
- API methods: api.limesurvey.org/classes/remotecontrol_handle.html
- add_participants(): api.limesurvey.org/classes/remotecontrol...hod_add_participants
- API code example: www.limesurvey.org/forum/can-i-do-this-w...-fly?start=15#158184

In addition to tpartner's answer you should really think of the structure of your survey. We are talking about roughly 1500 questions/columns for a table to reach it's limit, do you really have to ask all these questions? Can you split the survey so that the second or third one does not have to have conditions linked from each other?

I have done this myself, in 7(!!!!) linked surveys together, where participants could jump from part 1 to 5, part 1 to 7, part 1 to 3, part 3 to 5 etc etc based on conditions, and even though much of the questions where hidden due to conditions for most of the users the response rate of filling such survey will be bad, and it was bad, people will drop out.

Another note, passing data through URL is fine, BUT, an URL has a limit on how long it can be, some where around 2000 chars depending on the browser.

Seriously? Seven?

Seriously, yes. Without going to deep, I had a multiple choice question of 10-15 items, which had followup questions x10 in an array numbers layout with 10x6 or something. I would most likely have done this differently today with a bit more experience, but that was without any JS and only using LS.

yeah, those 1000 columns sound a lot and I always thought people have really huge surveys when they run into this limit. Until I had a survey with 5 questions. Five. Not possible with Limesurvey because I ran into the database limit. Yes, I could have made a few workarounds, split it into 2, 3, 4 or 5 surveys, but at the end I just used a different tool, because we did not have the time to fiddle around and wouldn't risk the client over this.

I hope in one of the next surveys LS makes it possible to join as many tables as necessary to allow more columns.

holch wrote: yeah, those 1000 columns sound a lot and I always thought people have really huge surveys when they run into this limit. Until I had a survey with 5 questions. Five. Not possible with Limesurvey because I ran into the database limit. Yes, I could have made a few workarounds, split it into 2, 3, 4 or 5 surveys, but at the end I just used a different tool, because we did not have the time to fiddle around and wouldn't risk the client over this.

I hope in one of the next surveys LS makes it possible to join as many tables as necessary to allow more columns.

I hope so too. But just to be clear. To run into this limit you will have to add a lot of questions, or, as in your case, a lot of sub answers, and it does not happen very often, the LS installation I am using has 1000+ surveys and I have only had this issue once or twice.

yes, I know. Which is why I said that I thought people were crazy when they ran into the limit. But then I had a not so absurd real life example and was surprised how quickly you can run into trouble.

My example: a total of 52 departments in a company (over several regions). First question was an array, so 52 columns gone. Next question was a array numbers with 7 answer options 52 subquestions, another 364 columns gone. Then 2 open ended questions with 52 different subquestions each, another 104 columns gone. So far we are at about 520, half of what should be safe. But now there should be about 4-5 loops of this and it should all be done in one survey. We could have simulated this via end url and additional questions, but I had an extremely complicated matrix for the token table, which would have totally exploded the whole thing. I guess the main problema was this matrix, where for each respondent we needed to determine for which of those 52 departments he/she can give responses, anyway. I think it would have been a headache in Limesurvey, if at all possible. So I passed the headache on to an external provider.

Thank you all for your answers! We indeed have a very large survey, and cannot remove many questions. Like holch wrote, we also have many answers for many subquestions, and cannot do without them (however, we don't have the time nor the will to reprogram the whole survey in another software before our deadline). It is why we decided to split our survey. This is our first survey with Limesurvey, so we didn't know what to expect.

Neither my team or I are great with code. I will try to figure out how to use the API to (if I understand the goal well) copy every token used for accessing the first survey as a token to participate in the second survey. If we keep both surveys with the ''token persistence'' option on, the data will all be tied to each token? I'm also guessing that the more surveys we try to link, the more complex the API code becomes?

Thanks again

If we keep both surveys with the ''token persistence'' option on, the data will all be tied to each token?

No, even with this enabled there is no data connection between surveys. Depending on your conditions/relevance, you still may need to pass answers between surveys via the URL and hidden questions.

I'm also guessing that the more surveys we try to link, the more complex the API code becomes?

Each extra survey should only be a couple of lines of code. I am not able to do so today but will try to give an example tomorrow.

tpartner wrote:

If we keep both surveys with the ''token persistence'' option on, the data will all be tied to each token?

No, even with this enabled there is no data connection between surveys. Depending on your conditions/relevance, you still may need to pass answers between surveys via the URL and hidden questions.

That's very useful info. I noticed that even when splitting our survey in two, the first part was still too large to be activated (it is quite an extensive survey). That, coupled with the need to create hidden prefilled questions that could potentially make the second half too large as well, made us choose the second option of splitting the survey according to each profile the participants fit (we tried to activate the profile with the most questions and it worked). It will also make the conditions programming a lot lighter. Considering this, I am even more relieved to see your second answer:

I'm also guessing that the more surveys we try to link, the more complex the API code becomes?

Each extra survey should only be a couple of lines of code. I am not able to do so today but will try to give an example tomorrow.

We'll have to build 9 different surveys branching from 1, so to read that it's only a few dozen lines of codes mores to program is truly a relief. I've started to explore the API in the meantime, it looks more user-friendly than I thought it would be! Thanks a lot for your help!