Overcome session count limitation in your Sitecore Personalize Decision Model

Sitecore CDP and Personalize are 2 SaaS flagship products in the composable stack. Previously, the monolith XP used to handle all customer data and interactions but in the new Composable world, these 2 products have taken over that.


CDP provides the ability to bring customer data from any platform and activate whereas Personalize tailor's customer experience based on external and internal data across different channels through personalization and a/b testing capabilities.

One of the key features of Personalize is the decision model. A decision model allows simple to complex business rules to run based on a variety of data from behavioral, transactional and offline data from external systems to determine the next best offer or action to show. It has got many components like decision tree, offers, programmables, etc. A programmable decision allows to run service-side code in a decision-making process.

Since the programmables run server side, it has got certain limitations on the behavioral data like the number of sessions, events that you have access to in your JavaScript code.

Depending on whether you have just Personalize or both CDP & Personalize license, your limits vary.

https://doc.sitecore.com/personalize/en/users/sitecore-personalize/understanding-data-limits-in-decisioning-and-conditions.html provides the data limits if you have just the Personalize license.


https://doc.sitecore.com/cdp/en/users/sitecore-cdp/data-limits-in-sitecore-cdp.html provides the data limits if you have both the Personalize and CDP license.


As you can see, with just Personalize license, you have access to just last 40 sessions which you would hit pretty quickly with your web applications.

You can use Amazon Data Lake export to access prior sessions and events data but that requires exporting the data from Sitecore's data lake into your own data lake and accessing it inside the decision model via an external connection which is time consuming.

The other option is what I did in one of my client projects is to create a Guest Data Extension and store the processed results from the decision model into it.

Guest Data Extension fields:

1. processedResults - JSON string - Stores the processed results from the decision model

2. sessionRef - Stores the last processed session reference - A guid value

3. sessionEventRef - Stores the last processed event reference within the session - A guid value

Here is the process flow of the solution



One potential roadblock that I hit was the decision model programmable can only read guest data and its extension and it cannot update it for performance reasons. So, I had to use my FE (head) application to do the update part.

Comments