How to enable Personalization on NextJS framework server side render? Can't take effect on server side render

[canyan1989]

Here is we are using framework: NextJS / React / klevu-core
We use next.js framework, because is good for SEO.
NextJS => klevu-core SDK=> personalisation =>https://github.com/klevultd/frontend-sdk/blob/master/packages/klevu-core/docs/modules/personalisation.md

1> The Personalization will not take effect on server side render. How can we achieve the Personalization functionality when rendering on the server side?

2> how to implement Personalization in a user-friendly way for existing/returning customers that have analytics data already. i.e. not reloading page content => So far one idea for Personalization only take effect on client, it means need to call Klevu API after page load(server side render) and update page content again (client side reloading page content). But we don't want to do it this way.

[jerrypena1]

Hi @canyan1989

1. The tricky part is that Klevu uses the previously viewed product IDs to determine which products to boost/deboost; which makes the results personalized for the user's session. Since we typically store this information in the user's browser, you would need to somehow make these IDs available on the server in order to make personalization work.

2. Similarly to the information shared above, the tricky part is sending the IDs. If you can store the IDs on the server-side and tie it to the user's session, you could retrieve this information and send it when making the server-side requests.

This being an SDK, it's completely upto you on which mechanism you use. The SDK provides localStorage automatic storing and retrieving of the IDs, but you can modify the requests if you are providing the IDs. I hope this helps.

[canyan1989]

Hi @jerrypena1

Thanks, It's helpful. And have more question want to confirm:

1> About Point2, if we modify the requests and provides the IDs on server-side requests, but SDK provides localStorage automatic storing and retrieving of the IDs on client-side requests. Is it also correct?
2> For at same search condition, this case will case the different results between server-side and client-side?
3> If we want to keep same logic with SDK on server-side, How can we provides the Similarly IDs on server-side requests?
4> How about the SDK logic of storing and retrieving of of the IDs ?
5> What is the maximum of providing product IDs and what is the minimum of providing product IDs ?
6> search() / categoryMerchandising() => SDK provides localStorage automatic storing and retrieving of the IDs on client-side requests. Both are same logic ? Have any different?

[jerrypena1]

Hi @canyan1989

1> the personalization modifier that you pass in can optionally accept parameters which allow you to pass in the IDs on the server side. Because you would need to manage the product IDs anyway in order to make this work on the server side, in order to avoid a mismatch of the local & server data for the IDs, I would use the same mechanism to pass in the IDs on the client side as well and bypass using the default localStorage mechanism.
2> addressed in my previous answer... avoid using two different methods and use a single method to manage storing of the IDs that works for both client and server.
3> Currently we store the lastclicked products in localstorage, so I would either pull the information from there to store on the server, or hook into the click events on the site to trigger storing the IDs on the server.
4> I would still allow the SDK to do everything it would normally do. The only difference is being able to send the IDs into the personalization modifier, so that is the part that needs the server side IDs.
5> the minimum is 0 (no products have been clicked yet), and there is no limit in the code for a maximum. The API also does not mention a limit, so I would assume the only limit would be regarding the payload size itself which is 8KB (https://docs.klevu.com/apis/smart-search-overview#XJfK8)
6> yes, both search and categorymerchandising store the same information in localstorage, but the real important piece of the data is the IDs regarding the personalization, so that is all I would store and make available on the server side.

[canyan1989]

Hi @jerrypena1

Thanks.

We're testing this way: store the IDs on the server-side and tie it to the user's session, retrieve this information and send it when making the server-side requests.

[jerrypena1]

hi @canyan1989 I'm curious is that worked for you?