Clarify how to use authenticatedUserToken with personalization

[a47ae]

When using the insights middleware and and authenticatedUserToken is set, each query request sets the userToken parameter to the value of authenticatedUserToken Source.

From my testing this results in no personalization as the personalization only works with the non authenticated user token. I confirmed this by making a manual request once with the search parameter userToken set the value of authenticatedUserToken and once to the value userToken. In the case of authenticatedUserToken I received no personalized results and in the case where I set the it to the userToken I received personalized results.

I also confirmed in the dashboard that the events have correctly set a userToken and an authenticatedUserToken.

I now have the question, if this is intended behaviour or am I missing something?

[francoischalifour]

You're correct that the behavior of the Insights middleware has introduced collisions since supporting authenticatedUserToken. For personalization, the ultimate goal is to consistently forward the anonymous user token to the Search API.

I discussed with @benhinchley and the rational was to keep supporting existing customers' implementations as they were working. Some customers were updating the Search API userToken once their users logged in, aiming to personalize mainly the logged in journey of their users. The Insights middleware replicated this behavior. However, this approach doesn't fully align with your scenario, and with where we're heading with personalization; which is supporting personalization for both new and returning users.

In Q4, we plan to stitch user sessions from logged-out to logged-in states in the backend, which will accommodate both anonymous and authenticated user tokens. From that point on, we will strongly recommend forwarding the anonymous user token to the Search API.

In the meantime, is there a workaround to force sending the anonymous user token to the Search API with the Insights middleware @Haroenv @sarahdayan @dhayab @aymeric-giraudet?

[benhinchley]

Hey @a47ae, thanks for raising this. The current behaviour mimics the previous behaviour of the client prior to the introduction of authenticatedUserToken where setting the logged in token to the userToken field would have overwritten the anonymous token that is created by default.

Were you previously setting the the userToken field to be the logged in user token? or have you only recently started setting the authenticatedUserToken attribute now that it is available?

[Haroenv]

I think the only way to opt out of forwarding the token would be forking the insights middleware and removing the authenticated token from:

• https://github.com/algolia/instantsearch/blob/master/packages/instantsearch.js/src/middlewares/createInsightsMiddleware.ts#L274-L290
• https://github.com/algolia/instantsearch/blob/master/packages/instantsearch.js/src/middlewares/createInsightsMiddleware.ts#L301-L308

or alternatively revert this commit locally: a20715c

For now I don't know what a future proof non breaking change solution can be, as people can of course be relying on all these different situations now.

[a47ae]

Hey @francoischalifour @benhinchley and @Haroenv , thank you for your detailed answer. :)

This is a new implementation, so I can not provide information on how we handled this previously. We followed the integration guide best practices

It is important to set the authenticatedUserToken parameter for authenticated users rather than userToken, which is intended to be used for anonymous tokens. Source

But then noticed that with this implementation we loose personalization for logged in users.
For context, we implement Algolia in an eccommerce site, so most users are not logged in but should receive personalization based on the anonymous token stored in a cookie. But if a user is logged in we would prefer to use this information and in the optimal case merge with the previous anonymous session (which we taught would already happen, but if I understand this correctly is only coming in Q4).

Does the authenticatedUserToken provide any value right know if sessions are not merged yet? Otherwise we would consider just not setting the authenticatedUserToken right know.

[francoischalifour]

We introduced authenticatedUserToken before supporting user session stitching to ensure our users' setup would be ready when the complete feature is available. By doing this, anonymous users from the past few months can be directly attached to an authenticatedUserToken, which means we lose less user data.

Given your current setup, it's reasonable not to use authenticatedUserToken right now, as long as you persist the user token in cookies (with the user's consent). This will keep personalizing the logged-in journey of your users as long as they use the same browser/device.