Description of the problem: I am currently trying to put a delay experiment on to Pavlovia, but am having an issue with figuring out how to link the experiments properly; while counterbalancing.
The experiment chain will go:
SONA Part 1 → Experiment 1
(1 hour delay)
SONA Part 2 → Experiment 2
(24 hour delay)
SONA Part 3 → Experiment 3
My main question is how can I make it so each SONA participant receives the same ID for each experiment and the same counterbalance condition for each experiment.
i.e. SONA participant #5 goes to experiment 1 and gets assigned id #5 and counterbalance condition 1; how can I make it so that same SONA particiapant is logged as id #5 and gets counterbalance condition #1 in Experiments 2 and 3?
Please check it to confirm but I think that the SURVEY_CODE is unique for each participant, so the same participant in different online studies will be assigned the same value.
You might need to try both No and Yes to the question in the study configuration since I’m not sure whether No means they can’t be identified at all or Yes means that the identifier is random instead of associated with their account.
Wakecarter, as always thank you for your amazing service to this community!
I assume that would mean I would pass the SURVEY_CODE only to Pavlovia and not daisy chain something like VESPR for participant id and counterbalance?
Thank you.
Daisy chaining requires the experiments to be consecutive without a break.
There are threefour parts to this problem.
-
How do you plan to get the participant to do experiment 2 one hour later and experiment 3 the next day. Can you use Sona to send follow-up emails or will you do that yourself? Pavlovia cannot send emails to participants. Qualtrics can send emails on survey completion. I do have a tool for this but is doesn’t involve delayed emails an was set up in terms of 24 hour periods: https://moryscarter.com/vespr/followup.php
-
How can you ensure that each participant’s data can be identified at each stage? If the Sona SURVEY_ID is fixed for a participant then great. Otherwise it will need to be coded into the follow-up URLs.
-
How can the participant be assigned to the same counterbalance condition at each stage. There are two options here. You could assign conditions using the modulus of the participant ID, if it’s a number or you could use the counterbalance component or VESPR Study Portal to assign a group in experiment 1 and then store that value in the URL or on the shelf assigned to the participant number for experiments 2 and 3.
What would I do? Since I have access to Qualtrics then I might do Sona → Qualtrics (for PI, demographics, assigning to group, allocating responseID and setting up a daisy chain to Pavlovia for experiment 1 plus email triggers with a 1 hour and 24 hour delay containing links with the participant and group numbers) → Pavlovia experiment 1. Then I wouldn’t have to worry about the SURVEY_CODE being unique or accessing the Pavlovia shelf.
- How are the students credited? You could have an automatic credit link back to Sona at the end of experiment 3. Alternatively, the email triggers could send the participant to Sona to launch the next phase, in which case the shelf might be needed, along with a constant SURVEY_CODE.
- SONA can implement multi-part studies that have set times links are sent to participants, so timed delay for Part 2 and 3 can be implemented via a multipart SONA study.
- I am currently emailing SONA tech support to determine if SURVEY_ID is held constant from part to part in a multipart SONA study (I would imagine it should from a logistic perspective, but I will follow-up in this chain with their response.). The other choice I could do is, if the SURVEY_ID is constant for each part, have a code component in each experiment that takes the SURVEY_ID and based on the number assigns to 1 of 4 conditions.
- This is where issues can enter. If SURVEY_ID is held constant, I take it I can use the Pavlovia shelf (which seems to be difficult from your reply).
- Crediting is simple, as participants are credited for completion of each part of a multipart SONA study, so that will be a simple redirect to SONA for each parts experiment.
If the SURVEY_ID isn’t constant, I agree that your path from SONA to Qualtrics seems to be the best route. Appreciate all your help here!
From SONA tech support:
In most cases SONA SURVEY_ID numbers will remain constant for each participant across a multipart study; though this can depend on system configuration.
I had an idea to simplify the process to a single experiment. Do you think the following would work?
Single experiment with loops determining if you do Part 1, 2 or 3 based on a session variable (this is how I ran the experiment in person). With how SONA works, I can make unique url links with each parts link predefining the session # (i.e. for Part1 “https:…?session=T1?id=SURVEY_CODE”).
Then I can make two shelves. One shelf (Condition_Tracker) would log [SURVEY_CODE, Condition] pairs. The other shelf (Counterbalance) would assign counterbalance conditions (essentially following the procedure shown in the YouTube tutorial for Pavlovia Counterbalancing found here) if the SURVEY_CODE is not already logged in the Condition_Tracker shelf.
So, if this works how I think it will, I will have an initial routine that:
Checks if SURVEY_CODE is in Condition_Tracker shelf.
If yes: Condition = the assigned value
If no: Make new pairing and add it to the Condition_Tracker
In principle this should work – since counterbalance is a routine without routine settings, rather than a component, you will need to skip if using a loop with nReps = 0 if SURVEY_CODE is in the Condition_Tracker.
URLS can only have one question mark and I recommend that you stick with “participant” instead of id. So your URL should be more like:
https:…?session=T1&participant=%SURVEY_CODE%
Excellent! Yes, based on the session # in the URL, I will set the nReps for the different Part loops to be 1 or 0. (1 if that is the Part they are currently on.)
Thank you for the URL insight, that would have probably driven me up a wall for a few hours figuring out! Is there any reason for keeping participant rather than id? Is participant just baked into a lot PsychoPy/Pavlovia functions?
participant is baked into the names of online data files. Locally you can customise them.
