Separate Paid and Credit Sites or Combined? Comparing Advantages
Published January 2, 2024
There are many good reasons to have multiple Sona sites. It could be that different departments or even different labs need their own sites. A frequent and more fundamental reason to have a single Sona site vs. two concerns two different types of participant pools: Paid/Community pools and credit-based pools.
This may not seem like much of a distinction. In truth, sometimes it isn’t. After all, every site can be configured to add both paid and credit studies. When both compensation types are enabled, every time a researcher adds a study they select “Paid” or “Credit” on the Select Study Type page (which is the first step in adding a new study). It’s clearly possible, then, to have a single Sona site that offers participants both paid and credit studies.
Possible, yes. In fact, sometimes it’s even the best option (“how” is the subject of this post, while the “when” and “why” details we’ll cover in upcoming posts). For example, when a department relies mostly on credit-based compensation and the occasional paid study, then there’s likely no problem. Handling large numbers of paid participants while handling large numbers of students participating in exchange for course credit is something else altogether. Nor does everything come down to compensation type. Whether to add another Sona site or not is only indirectly related to compensation. It’s more about different types of participant pools. Offering paid studies to participants in a credit-based pool isn’t the same as having a paid participant pool (even if the participants are all students!).
As with most things in life, there are no hard and fast rules for when two pools are better than one. Also as with most things in life, there are pluses and minuses to both options. Many of these can be more nuanced than you might expect, and we’ll address some of those nuances in later posts. For simplicity, here we want to provide an at-a-glance look at some of the major advantages of having separate Sona sites and some of the potential pluses to having a combined site. We’ve also snuck in some additional details for a more in-depth look (in case you want more than a glance).
Advantages to having separate sites
When managing two participant pool types, having two sites better allows for the growth and diversity of both pools while making the management of each easier. In short, it improves research productivity and participant experience!
There are many disciplines, from engineering to computer science, that increasingly conduct human participant research. Even among more “traditional” disciplines, the growth of online experiment capabilities, the complexities and diversity of lab research, etc., often translate into changing needs.
Imagine a university with a “standard” student participant pool. For years, they’ve had the same credit requirements for the same courses. However, over the years more and more scientists in different fields have asked about using the existing site. It starts out fairly small, with some faculty wanting to add an occasional paid study to the site. Maybe this is possible or maybe not, but it doesn’t take long until other faculty members and other departments want to make regular use of Sona to list paid study opportunities. Some need non-student participants, others would prefer paid student participants, and still others prefer to recruit as widely as possible.
Very quickly, whatever flexibility this “traditional” student participant pool would allow simply isn’t enough. It’s one thing to add additional courses with extra credit opportunities to a Sona site that previously only included courses with credit requirements. It’s another thing for this same site to include paid studies alongside new extra credit courses. And that’s without factoring in community participants!
It works the other way as well. A university with a community participant pool and a single Sona site can fairly easily add a course allows students enrolled in it the opportunity to earn extra credit in exchange for research participation. But it doesn’t take too many courses for this to become unmanageable.
A single community site can easily grow if additional participants are community participants, even if they are recruited from across the globe or are differ radically in other ways. Likewise, a single student site can easily grow to accommodate more courses with different credit requirements.
But growth and diversity are stymied whenever attempts are made to manage a combined pool with a single Site. Having two sites for two different pool types makes meeting the needs of both participant pools as well as researchers (and administrators!) much easier.
Finally, even when growth, changes, adaptivity, etc., aren’t factors, managing two participants pools with two sites is often simpler than with one. Credit-based pools operate on a course-based schedule. Often, in order for students to meet research requirements, there’s additional emphasis on ensuring participant opportunities. Even when participants are compensated only via extra credit, it’s still going to specific courses. Such pools usually mean that data, if not users, can be refreshed every semester.
Paid participants operate on a fundamentally different schedule. These differences count for more than one might think…unless one has tried to handle two different participant pool types (community/paid and course credit) using only one site.
Imagine asking undergraduates about home ownership and retirement plans. Then consider introducing non-student participants to your site with prescreen questions about study habits for classes they aren’t taking, grade averages for degree programs they aren’t in, and day-to-day campus life in a university they don’t belong to. This is why it pays to have the right prescreen for the right participant pool, something that having separate sites allows.
The prescreen questionnaire is a powerful method to both ensure researchers invite only eligible participants AND ensure that there are sufficiently many such individuals in the pool to begin with. Often, though, community pools include or consist of screened participants meeting certain demographic or other criteria (married couples, pre-college teachers/educators, right-handed individuals with 20/20 vision, retirees, etc.).
To give a more concrete example, consider education research. If researchers are conducting studies on educational psychology with a focus on evidence-based practices and teacher education, they likely wish to know how long participants have been teaching, what grade, level, or age(s) they teach, the extent of their graduate education, etc. In short, they’d want to know the answers to questions that would not apply to most students.
Likewise, if a community pool includes many older adults, questions aimed at understanding substance use among youth are likely inapplicable. Indeed, what constitute basic demographic questions for undergraduates, such as choice of major, goals after graduation, expected graduation date, etc., don’t apply to non-students. Bottom line: There are often important questions for student participant pools that make no sense for non-student participants, and vice versa!
Having two Sona sites makes this issue quite easy to address. Two Sona sites allows you to have two prescreen questionnaires, one for each site.
Courses end and students graduate, while community/non-student participants have no such fixed schedules. This can make End-of-Semester Maintenance, handling data, and other routine (and otherwise easy-to-handle) tasks much more complicated.
For combined paid/credit pools, even or especially those with paid student participants (who may also participate in studies for course credit), having separate sites for the paid/community pool and the course credit pool can make participant management much, much easier.
When all participants are in actual courses that end each actual semester, all participant accounts and data can be handled using the Advanced End-of-Semester presets to handle the entire process with a few clicks:
On the other hand, if you have non-student/community participants in your pool, this otherwise optimal strategy can have drastic consequences. Community participants typically remain longer. They don’t have requirements to meet or courses they are enrolled in. Trying to handle their participation records, sign-up activity, etc., as if these were all semester-based is not just impractical, but problematic!
The best solution is to treat participants who leave courses and even graduate altogether using the tools that work for students, such as the above-mentioned Advanced End-of-Semester presets, and a separate site that allows community/non-students participants to remain as long as they want and participate when they want.
Otherwise, it inevitably becomes something akin to the old problem of fitting square pegs in round holes.
If your Sona site has community participants, then requiring SSO authentication isn’t an option.
Even if your site offers, but doesn’t require, SSO authentication, complete SSO integration is still not possible.
To see why, the first thing we should probably explain here is the “complete” part. Not long ago, SSO-enabled sites treated all users the same. SSO authentication could be required from all users (not just participants) or no users. These options are still available. What’s changed is a newer feature that allows administrators to treat account approval differently for SSO users than for non-SSO users: “Partial” Automatic Account Approval.
The reasons for the qualifier “partial”, and indeed largely the reason for the feature itself, comes back to certain limitations of using a single Sona site for a combined paid/credit pool (particularly when the paid pool includes non-students). Complete SSO integration, which would require SSO authentication from all users is a great way to ensure community/non-student participants can’t access their accounts.
The solution? Two sites: Complete SSO integration for students using one site, and have a separate non-SSO site for non-student/community participants.
Having separate sites for paid vs. credit studies makes it easier for researchers to recruit the participants they need, easier for participants to find the studies they wish, and easier for everybody to avoid problems with accidental sign-ups or confusions.
If your pool contains both paid and course credit participants, researchers have to determine whether their studies are paid or credit studies when they start the “Add a Study” process. For studies requiring more participants, researchers may have to add the same study twice: once as a paid study, once as a credit study. All studies must be one or the other, not both.
Having a combined paid/credit participant pool can present other issues that two sites would not. There are plenty of ways to ensure that community participants or paid student participants can’t enroll in credit studies. But this has to be taken into account each time such a study is added. It’s far simpler for participants and far easier for researchers and administrators if paid studies are available only on the separate, paid site.
It’s also much easier for participants to track progress or payments separately, whether this means a singe account in one of two Sona sites or being a participant in both. Likewise, it’s easier for researchers and administrators to track compensation separately when paid studies are listed on a paid site and course credit participation is handled via the other site.
Advantages to a single, combined site
Having both a paid/community site and a course credit site can be beneficial in more ways than we can cover here, but it still means paying for two sites. Whether this ends up saving money depends on other factors, but the simple fact is that having a single site means a single cost.
There is an important caveat to this, however, and one that isn’t based on nuances such as administrative workload (among other factors). Two Sona sites means two subscriptions, but there are times when two can don’t cost more than one. This is particularly relevant when considering adding another site. A combined site usually means more participants signing up for more studies, which means more sessions. This in turn typically means that the only pricing plan possible is Ultra (unlimited sessions). On the other hand, this may be more than you need if you opt for another site instead. Even if both participant pools require Advanced plans, this would have all the benefits of two sites and cost the same as the Ultra package!
Doubling the sites doesn’t mean doubling the workload, but it can mean increasing it. Running a Sona site does require some work. Good use of Sona’s features minimizes this, of course, but there are still administrative tasks to perform.
Even supposing the amount of work were to remain relatively constant, there’s a lot to be said for having all the tasks in one place. It may be that a single site adds complexities because some participants are paid and others operate on a semester-based schedule (participating in exchange for course credit). Adding another site, however, means keeping track of two sets of tasks and having to login to two Sona sites to accomplish them. This is particularly true for things like generating reports, troubleshooting user problems, and other tasks that administrators may have to do regularly and which are made more difficult when split among two sites.
Ultimately, of course, a certain amount of individual preference comes into play. For some, having two different participant pools handled by completely different Sona sites adds ease, not complexity. For others, having to login to two different systems is a greater burden. Different approaches to organizing tasks mentally adds a subjective element.
Nonetheless, a single site means administrators can handle all tasks using a single account. Single might not mean easier, but it does tend to mean simpler, and hence counts as an advantage here.
Using two Sona sites, one paid and one credit-based, offers clear advantages when there is little or no need to list the same study on both sites. In certain contexts, though, such as when a large portion of participants have course credit requirements to meet and participant demand is high, there is actually an advantage to using a combined site. This is especially true if many of the paid participants are students (some of whom likely need to meet credit requirements or wish to take advantage of extra credit opportunities).
Whatever the underlying reasons,
Many participant pools managed using Sona start out mostly as one “type” easily managed by our platform. These pools may be community pools with no courses (and thus, no credit requirements or extra credit for compensation). Or they may start out entirely credit-based with one or more eligible courses participants must be enrolled in. One nice thing about Sona is how easily it can handle increases in research productivity. Increased research productivity means more studies, which means a greater need for more participants. This tends to make researchers want more courses eligible for extra credit via Sona. Growing from a participant pool of students enrolled in sections of one course with a credit requirement is simple. Administrators can reconfigure the site with a few clicks on the Settings page. From there, adding multiple courses with both credit requirements and extra credit opportunities is a simple matter of adding the course sections to Course Listings.
There’s another way a single Sona site can help increase research productivity: Growing a “seed” participant pool. How to do this is something we’ll cover more thoroughly in a later post. For our purposes it’s enough to point out that if you don’t have a community participant pool, you can use a single Sona site to start one. If it grows enough, then you can add a second site. If it doesn’t work out as expected, all you need do is delete the “course” these community participants belonged to along with there accounts.
Similarly, a Sona site may initially consist entirely of paid participants. Later, if some department or college wants to encourage more students to participate in research using research credit requirements or offering extra credit, this can be done within the same Sona site. And once again, this combined participant pool site can be used to grow the course credit pool until a second site is warranted.
As you can see, particularly if you expanded some of the sections above, the extent or value of some of the advantages depends upon your particular situation. It may seem obvious that running two Sona sites must at least add work compared to having just the one site. It isn’t obvious. At least not always. Scanning the advantages to separate sites shows that adding a second site can mean less work, not more. It depends on the situation. In a future post, we’ll look in more detail at how the different situations can change an advantage into a disadvantage. The above, though, gives an overview of the major advantages.
Perhaps equally importantly, if you’ve never asked this question but have wondered about whether or not there may be a better way to handle paid participants in your site, the above provides guidance and a way of approaching this question. For more details, including a guide to building a community pool in an existing site, see our upcoming posts!
