I am designing an interactive experiment on oTree and need guidance on integrating it with Qualtrics responses. Participants will first complete a Qualtrics survey with several questions. At the end of the survey, they should be redirected to an interactive oTree experiment, where they will be paired with a partner who meets specific criteria based on their Qualtrics responses. Is there a way to implement this real-time automated matching function between Qualtrics and oTree, ensuring participants will be dynamically paired without waiting too long? Any insights or suggestions would be greatly appreciated!

To assess whether your desired features are realistic, more information is needed.

(1) Why do you want the first part to be implemented in Qualtrics instead of oTree?

(2) How many different matched groups do you intend to implement in oTree?

Just for example, let’s assume that you would like to partition participants into four groups: (female, ≤ 30 years), (female, > 30 years), (male, ≤ 30 years), (male, > 30 years). In this case you could set up four different rooms in oTree, one per group. You could display the room-specific URL in Qualtrics, conditional on your participants’ responses to the questions on sex and age.

Within the oTree room, you could use “group by arrival time” (see https://otree.readthedocs.io/en/latest/multiplayer/waitpages.html#group-by-arrival-time) so that the pairs are formed as quickly as possible (if you are fine with fast participants being paired with other fast participants, and slower participants being paired with other slower participants).

(3) You wrote, “ensuring participants will be dynamically paired without waiting too long?” Well, this depends, of course, on the following: Can you make sure that all participants will start the experiment at roughly the same time, that is, within a couple of minutes? And, of course, it depends on your definition of “too long” and the number of participants in your study.

(4) If you would like to implement the entire study in oTree, eliminating Qualtrics, https://www.otreehub.com/forum/1315/ might be of help. The general structure there seems similar to me: You have a first stage in which participants answer questions, followed by a second stage in which the grouping is conditioned on the responses to the questions from the first stage.

PS: If moving the pairing “with a partner who meets specific criteria based on their Qualtrics responses” to oTree is an option, also https://github.com/aufi01/stratification might be of help.

Thanks for your detailed response! Moving the entire experiment to oTree is definitely an option I am considering. However, the main challenge is that the matching criteria in my study are not based on a single categorical variable like gender or age. Instead, pairing depends on participants' specific responses across multiple questions.

For example, a participant who chooses 'Yes' for Q1 and 'D' for Q2, will be paired with a participant who chooses 'No' for Q1 and 'A' for Q2. Because of this structure, setting up fixed rooms in oTree (e.g., one per predefined group) wouldn’t work well, since the number of possible pairings is dynamic rather than static. 

This complexity may also lengthen potential wait times. We plan to recruit participants from MTurk or Prolific, and based on our experience, a sufficient number of participants should begin the survey around roughly the same time. We just do not want them to get disengaged due to long waiting time.

Well, in that case, it seems reasonable to me to move everything to oTree.

You wrote,

> We just do not want them to get disengaged due to long waiting time.

Well, the waiting time depends on participants’ speed, on the requirements of your matching algorithm, and on your ability to force participants to start the experiment simultaneously and to finish the survey simultaneously.

What I would do is mention in the Prolific/MTurk “study description” that participation is only possible on a particular day at a particular time, and that subjects are allowed to sign up for your study only if they are certain that they will be available at the indicated date and time.

At the BonnEconLab, this step is usually followed by what I describe on https://www.otreehub.com/forum/1235/:

1. We set up a room via the settings.py file.

2. We send participants the room-wide URL (usually including “?participant_label=SomeParticipantSpecificCode”) and tell participants to open that URL a minute or two before the experiment is scheduled to begin.

3. In the minutes around the experiment’s scheduled beginning, we monitor how many participants are present via the room’s admin page.

4. When the experiment is scheduled to begin, we open the room with the very number of participants present. This way, we avoid that there are any missing participants whom we would have to advance manually.

5. This ensures that all participants will begin your experiment simultaneously.

6. If you include a timeout in your initial survey, you can also ensure that everyone completes the survey at (approximately) the same time.

You can then treat everyone who does not complete the survey in time as a drop-out.

Among all those who complete the survey in time, you can now calculate your “pairing matrix” based on your participants’ responses (https://otree.readthedocs.io/en/latest/multiplayer/groups.html#set-group-matrix). This can be done using a wait page with after_all_players_arrive (see https://otree.readthedocs.io/en/latest/multiplayer/groups.html#shuffling-during-the-session and https://otree.readthedocs.io/en/latest/multiplayer/waitpages.html#after-all-players-arrive).

Hence, the structure would indeed be the same as described in https://www.otreehub.com/forum/1315/ (wouldn’t it?) — with the addition of your more complicated pairing algorithm.

Thank you so much for the step-by-step breakdown of how to synchronize participant arrival and pairing! Your advice is so helpful! Moving everything to oTree does seem like the best approach. I now have a much clearer sense of how to move forward with the design.