Understanding Personalization Calculation

Based on specific business requirements, a CxConfig item can be created through Backoffice and stored in the database. Each CxConfig item:​

• Includes general personalization settings, such as personalization calculation processes.​
• Can be associated with one or more BaseSites, allowing the personalization configuration to be applied to the linked BaseSites.​

Next, let’s examine the standard calculation process for the personalization module. Pay close attention to the following three numbered steps and their introduction that follows.

1. When a user visits the composable storefront, SAP Commerce Cloud initially verifies if the personalization functionality is enabled.​

   To enable the personalization functionality, two conditions must be met simultaneously:

   • The current user must have actively consented to the collection of their personal data.​
   • The personalization Web service is enabled (as shown in the following screenshot.)
   
2. If personalization is enabled, the previously calculated personalization result for the current user must be loaded in the current session. At this point, SAP Commerce Cloud must determine whether recalculation is required. Recalculation will be triggered if either of the following conditions are met:​
   • The calculation result does not exist.
   • The calculation result has become invalid.​

   Note that we can configure the duration (in milliseconds) for which the personalization calculation remains valid in Backoffice.

   
3. If a calculation is required, the personalization process is triggered and executed asynchronously in the background, consisting of four major steps:​
   • Update User Segments: Updates the segments for the current user.​
   • Determine Active Variations: Identifies the active variations for the current user based on a trigger. The trigger represents the conditions that activate related variations. We will discuss this in more detail in the next section. Note that the trigger is a key component that can be customized within the personalization module.​
   • Execute Related Actions: Executes the actions associated with the active variations.​
   • Save Personalized Results: Saves all personalized action results in the database.​

That concludes our quick overview of the personalization calculation process. Next, we delve into more detailed explanations of some of the individual steps involved.

An important feature of the personalization module is the ability to vary the content shown on a page depending on the segments a user belongs to. Determining which variations are relevant for a given user requires triggers. Let’s learn how these work.

This is a brief introduction to triggers and their related customization. The previous lesson included a demo on how to combine existing triggers with actions to deliver personalized content on the composable storefront. In a later exercise lesson, we explore how to customize triggers with the personalization module.​

As the final step, we must deal with the personalization calculation-related data in the database as well. What does this mean? ​

1. The personalization calculation results are retained in the database for each user, especially for anonymous users. ​
2. Each asynchronous personalization calculation creates a new business process that is also stored in the database.

Both types of data can pose challenges as the related database tables can easily grow to an unmanageable size and reduce performance.​

Here are two recommended standard solutions:​

1. Clean old personalization calculation results, particularly for anonymous users.​

   Use a session close listener or the CxResultsCleaningCronJob.​

2. Clean old business processes from asynchronous personalization calculations.​

   Use the CxPersonalizationProcessCleanupCronJob.​