In order for personalization to be applied correctly at query time, it is essential that the userToken sent with search queries matches the userToken sent with events for that user, not the authenticatedUserToken.
This is because authenticatedUserToken is not yet utilised by personalization. While it is fine to send an authenticatedUserToken with events, the most important thing is that the userToken sent with search queries matches the userToken sent with events.
- The
userTokensent with events is used to build user profiles - The
userTokensent with queries is used the find and apply those profiles
This means that if you are sending an anonymous/session ID as the userToken value with events, you must also send that same userToken at query time; otherwise users will not be see personalised results.
If your users are typically logged in when they visit your site, and you want to use their authenticated ID for personalization, you can, but only if you also send it as the userToken in both queries and events. In this case, the event authenticatedUserToken and userToken will hold the same value.
If your users are more likely to log in after landing on your site and are first assigned an anonymous/session ID, you should:
- Continue using the anonymous ID as the
userTokenfor queries and events and persist it - Send the
authenticatedUserTokenwith events after login
This ensures that the profile built under the anonymous ID is preserved. If you switch to using the authenticated ID as the userToken after login, the earlier profile cannot be applied to search queries.
We have a full guide articles on best practices here:
- Which user token should I send at query time? - userToken and authenticatedUserToken best practices
- What is the best practice for identifying userTokens if a login is possible at any point in the customer journey?
For a full list of common userToken issues, troubleshooting topics and best practices, see our summary article here.