Safety & privacy for communicating with participants
There are two key ways that participants can be exposed to individual researcher or research operations emails and names:
Email Privacy
For all emails that Ethnio sends (Pool, Scheduling, and Incentives), you can enter any email or name you'd like at your organization's domain to make sure participants cannot harass or contact researchers or research operations team members:
Please note if you use an email outside of your domain (e.g., acme.com), it will break DKIM, if that's enabled as part of your Enterprise plan.
Integration Privacy using Google and Zoom
It gets a little tricker to safeguard your identity if you're using the GCal or Zoom integrations in Ethnio, but a popular approach is to create multiple individual emails at your organization you can use for the integrations:
- Create multiple generic emails like research1@acme.com, research2@acme.com. etc as individual Google Accounts, and use those to connect with Ethnio. You cannot use aliases or Google group accounts to do this, due to Google's security model.
- Similarly, create Zoom accounts using those same emails to be able to create dynamic Zoom meetings from Ethnio.
- Add your individual email as a collaborator to receive calendar invites for confirmed participants directly on your own calendar. Alternatively, you can enable GCal calendar sharing for any individual email to be shared with other Google emails at your organization, but that is a fancier version of collaborator events that may not be necessary.
Standalone Gmail Addresses
You can also use any generic gmail address like acme_research@gmail.com because DKIM does not govern calendar invites or Zoom meetings. With integrations, it's Google or Zoom that communicates with your participants, not Ethnio. You basically just give permission for Ethnio to have those tools send emails or events directly.
Be aware that scheduling emails are saved by team member
One gotcha is that each team member can have their own sender identity on the same screener. What this means is that you could have scheduling invites from Mary (mary@acme.om) and then Jane logs in to the same screener, and invites a participant, but that sender identity by default will be Jane (jane@acme.com).
This allows multiple team members to invite participants on the same project/screener and still keep their own identity, but if you prefer that all invites have the same sender identity. Not a problem, just make sure your team members know to verify that it is the same when they login. So in this case, Jane would have to edit the from/reply-to to say Mary (mary@acme.com)
This doesn't apply to Pool because it sits on top of all screeners and saves sender identity per distribution or automation.