Hi everyone,
I've been going around in circles, so I thought I'd check in with the community on my particular Qualtrics challenge...
Short version: after being added to a panel through survey contact triggers, is it possible to automatically provide panel members their RecipientID in some manner (e.g. email)? And can RecipientID be used as the required token in survey authenticators?
If so, could someone please point me to resources and/or examples? If not, there's no sense in reading on... either way, any input would be greatly appreciated!
Much longer version: I'm involved in research assessing a group training course, delivered via a network of (currently unknown) facilitators, with multiple surveys completed by participating group members over the training duration. Currently, as groups come on board the associated facilitator sends me a list of member emails along with additional info (group name, facilitator name, etc) and I manually upload this info into a Contacts list. I then supply the facilitator with links to the course surveys, which are generic so facilitators can release the urls to members on their own timeline. The surveys use an authenticator for log-in (member email address) as well as embedded data fields to capture various panel fields for tracking and binning (e.g. RecipientID, group name, facilitator name).
It works, but is clunky and not really secure since the authenticator is based on entering an email address (which can be widely known). As a result, I'd like to automate the process as much as possible and make it more secure... is something like the following possible in Qualtrics?
1) facilitators first register themselves via a _separate, generic, facilitator-intake survey_ and are added to a "Facilitator" panel upon completion (via contact trigger),
2) then facilitators are automatically emailed their panel RecipientID, which constitutes an anonymous and unique Facilitator ID, and this is to be saved for,
3) registering each group under their facilitation via a _separate, generic, group-registration survey_ (which contains Facilitator ID and Group Name fields), upon completion of which,
4) the facilitator then receives an email containing a link to (yet!) another survey, with Facilitator ID and specific Group Name appended to the url via piped text, to be distributed to relevant group members as a _member intake survey_,
5) and as group members complete the intake survey they are added to another panel with the proper group membership and facilitator ID (via embedded data and contact trigger), and finally...
6) the participants themselves (group members) are automatically emailed their own panel RecipientID to be saved and used in subsequent survey authenticators?
Entirely different ideas are welcome as well :)
Ian
Page 1 / 1
Hi @ifmacdonald,
Phew , that was long
So the problem is to save and send a RecipientID ?
You can send them the ResponseID for facilitators as responseID is unique for each respondent.
You can save the responseID in contactlist with the email and use an email trigger to send this ID.
For the Group of people that facilitator adds
similarly for group you can provide them there responseIDs
Hope this helps
Phew , that was long
So the problem is to save and send a RecipientID ?
You can send them the ResponseID for facilitators as responseID is unique for each respondent.
You can save the responseID in contactlist with the email and use an email trigger to send this ID.
For the Group of people that facilitator adds
similarly for group you can provide them there responseIDs
Hope this helps
Yes resipent Id can be used in authenticator, after the first survey you can send a link using contact list trigger and send them to input recipient is to access it. But make sure to add recipient Id as external datareference or under email as authenticator take values from these variables only.
I had some time to play around with your suggestions and it seems to be working as I'd like. Much appreciated!
Edit: one potential wrinkle in this setup is people talking the registration surveys multiple times. Is there an iron-clad way to prevent such (i.e. not just relying on 'preventing ballot box stuffing'?)
Edit: one potential wrinkle in this setup is people talking the registration surveys multiple times. Is there an iron-clad way to prevent such (i.e. not just relying on 'preventing ballot box stuffing'?)
Hi @ifmacdonald
You can use authenciator in your survey before adding them to your contact list to check if they are already on the contact list .
You can use authenciator in your survey before adding them to your contact list to check if they are already on the contact list .
Thanks for suggestion, @NiC ... I may be missing something simple here, but how does the authenticator do this, and where would it go, when a respondent needs to complete the survey _before _being added to the authenticated list?
Hi @ifmacdonald
You can accomplish this in multiple ways . So basically what authenciator does is it searches for a given data row (by a provided data) in the given contact list, now most appropriate position would be after you have asked for email, prefill the authenciator and set the number of attempts one. Now if they enter an email which is previously entered you can show a message that this email is already present in the contact list and ask them if they want to renter. If yes then redirect them using an end of survey element to the same survey (allow multiple completes for this to work) and if they select no Just end their survey.
You can accomplish this in multiple ways . So basically what authenciator does is it searches for a given data row (by a provided data) in the given contact list, now most appropriate position would be after you have asked for email, prefill the authenciator and set the number of attempts one. Now if they enter an email which is previously entered you can show a message that this email is already present in the contact list and ask them if they want to renter. If yes then redirect them using an end of survey element to the same survey (allow multiple completes for this to work) and if they select no Just end their survey.
Thanks @NiC but it's still not clear to me how this setup would resolve the underlying issue. Since the registration survey exists to add people to a panel via contact trigger (i.e. after they complete the survey), prior to any individual completing the survey there is no corresponding contact info on which to authenticate. I appreciate your help, could you outline the logic and survey flow behind your suggestion in more detail?
Ah... I finally figured out what you meant with the help of Qualtrics support chat. I wasn't considering the options provided by non-authenticated survey paths. My new survey flow is as follows, in case others have a similar struggle:
1. block asking for email address
2. embedded data collecting that email address
3. authenticator based on embedded email value (value is prefilled to hide authenticator)
4a. if already in contact list (_pass authentication_) present customised end of survey element underneath authenticator ("already registered" message and don't record survey response).
4b. if not in contact list (_fail authentication_) present registration question block outside authenticator, then add to contact list on completion via contact list trigger (conditioned upon a specific question in the registration block being displayed).
1. block asking for email address
2. embedded data collecting that email address
3. authenticator based on embedded email value (value is prefilled to hide authenticator)
4a. if already in contact list (_pass authentication_) present customised end of survey element underneath authenticator ("already registered" message and don't record survey response).
4b. if not in contact list (_fail authentication_) present registration question block outside authenticator, then add to contact list on completion via contact list trigger (conditioned upon a specific question in the registration block being displayed).
Leave a Reply
Enter your E-mail address. We'll send you an e-mail with instructions to reset your password.