Personalization of web content, especially for b2c stores, is highly demanded by customers nowadays. They prefer to see relevant products on their buying journey as part of a state-of-the-art user experience. This also includes personalized searches and even personalized promotions. These high customer expectations can be mostly met by SAP Commerce Cloud’s out-of-the-box available dynamic personalization features.
What makes them dynamic? The content might change, for example based on customer behavior in the storefront which provides more than the previously introduced static personalization features known as restrictions.
Let’s briefly introduce the main building blocks for Dynamic Personalization first and apply them to an example before diving into the details:
In simple terms, let’s assume Laura’s company wants to have a "Summer Sale". To help with the sale, Laura can create a customization for their webstore that will make it look different for different groups of users. Each user belongs to one or more segments, which comprise users with certain similarities like their age, their gender or their perceived interests based on their shopping history.
Certain logically combined segments make up a target group.
Note
By combining user segments to a target group, we can tailor our sales efforts more precisely to customers who are most likely to buy our products.
Our "Summer Sale" customization can contain several target groups, which trigger different actions like exchanging UI components, adding promotions, or modifying search results.
The following diagram demonstrates the relationship between Customization, User, Segment, Target Group, and Action:
To illustrate how Laura can use Dynamic Personalization, let’s refine our example:
Laura created the SummerSale customization, which contains two target groups.
One is called VIPCustomerMen. It is configured to include users who belong to both the VIPCustomer and Men segments.
The other target group BigSpenderGeek is configured to include users who belong to either the BigSpender or Geek segments.
For example, the Summer Sale customization might look like this:
Both target groups VIPCustomerMen and BigSpenderGeek trigger different actions, as you can see in the following diagram:
In the preceding diagram, note the actions taken when the Target Group is triggered. These actions can be:
- The current user is shown a variation of one or more of the components displayed on the current page.
- The current user benefits from a promotion.
- The current user is assigned a custom search profile that modifies the order of products in search results shown on the site.
Now that we have briefly introduced the terms and applied them to an example, let's cover some important details regarding our building blocks:
- A Segment is the smallest available grouping element.
- A User may belong to any number of segments.
- Each segment may include many users.
Note
The association of users to segments typically happens behind the scenes and outside of SAP Commerce Cloud. It is complex, requires a lot of logic, and is often supported by more SAP tools like Emarsys or custom coding. We cover more related details in later lessons of this unit. For now, we use the basic features of BackOffice to set up these associations.
The major building block to define a sale is a Customization. Each customization contains different Target Groups, and each user inside a target group can experience the same customization differently.
But how does the system know which user belongs to which target group per customization? Well, this is provided by the entry conditions defined for each target group based on segment membership.
A Target Group contains segments, which in turn contain customers. The entry condition is a logical term. For example, customers only belong to Target Group T1 if they are members of Segments S1 AND S2 OR S3.
Note
The term Target Group is used for business-related functionality in the front end UI, but the technical documentation refers to them as Variation. The two terms are interchangeable. It’s a target group in terms of who is affected, and a variation in terms of what it does.
But how does the system know which personalization behavior belongs to which target group inside a customization? Well, this is provided by the actions defined for each target group.
Actions might switch one UI component against another. But an action could also trigger a target group-specific promotion, for example, 20% OFF for "Discount Lover – Kids" or it might adjust the search results, for example, to show pink products on top of the PLP, but only for the "Pink Lover – VIP – Woman" target group.
Congratulations! You have made it through the theory section. Just to make sure that you are comfortable with dynamic personalization on the job, here is a video summary:
Priorities
What would happen if a customer belongs to several segments that would theoretically trigger two different target groups inside a single customization? This is not allowed, because each of the two might want to exchange the same UI component with a different new one.
Therefore, target groups are assigned a priority inside their customization, and only one can be active at any point in time for a specific user. Thus, the target group with the higher priority wins.
Ok, that was easy, but what if we have several customizations defined, and more than one could be active for a customer at the same time? This is allowed, therefore customizations are also assigned a priority.
Let’s assume that a customer belongs to two different target groups simultaneously, but this time they belong to different customizations. Both of the two again want to exchange the same UI component with a different new one. In this case, the customization with the higher priority wins.