Lag in survey using loop & merge | XM Community
Solved

Lag in survey using loop & merge

W
Badge +1

Hi XM Community, 

My collaborator and I have found a way to use Loop & Merge to implement an attention-based work task from psychology within a Qualtrics survey. In short, we have a 5 blocks, where each block contains a set of 300 images that are presented in a random order to the participant using Loop & Merge. It seems to work well in most ways EXCEPT that it seems to be the case that the lag on the survey gets longer and longer as the survey progresses. 

Has anyone else had issues with this? We assume it’s some issue where Loop & Merge caches some data and thus lags more, but that truly is just a guess  -- does anyone who understands how Loop & Merge works in the backend have a hunch on what might be happening and how this might be fixed? 

Thank you!

icon

Best answer by ahmedA 8 May 2024, 13:28

View original

2 replies

A
Rank
Userlevel 7
Badge +21

You can’t fix this. Using Loop and Merge for anything more than 50 loops makes it slow, especially if you have randomization enabled. Each time a person responds to a question in the loop, the frontend makes a roundtrip to the server to get the new page, sending all the previously answered responses with it. This causes the delay.

Another issue that I’ve encountered sometimes is that that some stimuli are repeated, i.e., while we’ve programmed for only 200 loops, the respondent sees 201 stimuli. I found this out because we were recording data using our own backend and some respondents came back with more loops than others.

 

There are a few ways of getting around this:

  1. Break your loops into smaller chunks, so instead of 300 in one, have 5 with 60 stimuli.
  2. Create 300 questions, one each block and put them in a randomizer.
  3. Use a custom frontend to display your question

 

 

 

W
Badge +1

Thank you for your response! Super helpful to know a bit more about the backend.

One follow-up question: It seems our survey slows down quite a bit across blocks as well. Is that potentially just a generic consequence of having so many data points saved, or do you think having smaller chunks (suggestion 1) might help with the across-block lags as well?

Thanks again!!

Leave a Reply


Terms & Conditions