...
for detecting fraudulent survey respondents, deprecating the current third-party integration with RelevantID. You may need to adjust some of your existing workflows due to this change.
The existing RelevantID embedded data fields (Q_RelevantIDDuplicate, Q_RelevantIDDuplicateScore RelevantID, Q_RelevantIDFraudScore, Q_RelevantIDLastStartDate) will start using default values instead of calling the third-party to compute a score. Any branch logic dependent on a non-zero score will no longer take effect.
Survey Options will now include two toggles for detecting duplicate respondents:
One will configure browser cookie detection used by “Prevent Multiple Respondents” feature, which will continue to function as before, allowing survey creators to determine the behavior when the survey is first loaded by a respondent who has that cookie.
A new “Detect duplicate respondents” toggle will be added to configure the behavior for likely duplicates, as detected by running a proprietary algorithm when the survey ends. This toggle can be further customized with the option to either flag the response with embedded data or screen it out. Surveys that previously enabled “RelevantID” will automatically enable this toggle and be configured to flag responses that are likely duplicates
A new embedded data field called Q_DuplicateRespondent will be added to responses after they are submitted, with a “true” value to flag responses detected as a likely duplicate under this new system. This embedded data field will not be available for branching logic within the survey in order to improve the accuracy of detecting duplicate respondents. This embedded data field is only added if you decide duplicate responses should be kept, not screened out.
What action do I need to take?
...
If you have a question about RelevantID, please visit the Fraud Detection support page. It’s also always worth checking the XM Community to see if any other users have the same question. If you’d rather speak to a specialist, our Support Team is always ready to assist. To contact them, please file a support request from your Customer Success Hub.
Qualtrics authentication was changed from Shibboleth to “Azure ID” on September 3, 2024
for the university effectively enabling Single Sign-on (SSO) However, for survey owners/authors, when the current SSO connection is turned off (Shibboleth) then the SSO authenticator in the survey will stop working and pulling in user attributes from the SSO connection. It will also not update to the new connection automatically. Users will need to go in and manually change the connection and republish their surveys to bring in the attributes from the new SSO connection (Azure ID).