Personalization Hub Manual / Version 2406.0
Table Of ContentsThis chapter describes how you configure CoreMedia Adaptive Personalization features in the underlying platforms.
Section 3.2.1, “Defining Property Editors” describes how you can integrate the delivered property editors into CoreMedia Studio content forms.
Section 3.2.2, “Configuring Caching For Rules and Condition Evaluation” describes how to cache rules and conditions.
CoreMedia Adaptive Personalization includes two property editors for editing personalization specific content properties in CoreMedia Studio:
SelectionRulesField
is an editor to be used to define content selection rulesConditionsField
is an editor to be used to define customer segment conditions
SelectionRulesField
and ConditionsField
can be used for a content
property of type XML using schema coremedia-selectionrules-1.0
. This schema is
defined in cap-personalization-schema-bundle.jar
and can be imported into a
content type declaration file by adding the following code near the top of the file:
<XmlSchema Name="coremedia-selectionrules-1.0" SchemaLocation="classpath:xml/coremedia-selectionrules-1.0.xsd" Language="http://www.w3.org/2001/XMLSchema"/>
You configure a property editor for a specific content property as explained in the CoreMedia Studio Manual.
The CoreMedia Blueprint development workspace provides a Studio form using these condition fields to edit personalized content items.
Setting up the Property Editors
CoreMedia Adaptive Personalization offers different types
of conditions that are listed in Section 5.1, “Condition Types”. Therefore, you can
adapt the property editors for selection rules and segment conditions to the types of
properties your application is using. For example, if your context contains a property
dateOfBirth
that holds the current visitor's date of birth, the property
editors should use a DateCondition
instead of a StringCondition
for
conditions using the property.
You configure the editors in the ext-xml
files defining the property editors for
your content types.
SelectionRulesField
SelectionRulesField
supports the attributes propertyName
and
allowedContentType
.
propertyName
is required and denotes the name of the content property to be associated with the field. This attribute is common to all property editors in CoreMedia Studio.allowedContentType
is optional and denotes the name of the type of content that can be selected via rules defined using this property editor.
For example, if allowedContentType="CMTeasable"
is used, only content items of type
CMTeasable
or of any subtype can be added to the rules created via this editor.
Thus, you won't be able to create a rule that selects a CMChannel
.
The child element conditionItems
defines the condition types the
SelectionRulesField
will support. The following table lists the allowed
attributes in conditions.
Property Name | Description |
---|---|
conditionName
| The text the user sees in the combo box used to select the type of a condition. It is not further processed by the rule editor and thus can be an arbitrary string. Required |
propertyPrefix
|
The prefix denotes the context name of the property and does not include the
separating '.'. For example, to denote all properties in the 'foo' context, such as
'foo.bar' and 'foo.zork', supply 'foo' as the
propertyPrefix value. ConditionTypes
support either propertyPrefix or
propertyName , but not both.
|
propertyName
|
The name of the property the condition is associated with. The rule editor compares
the name of the property used in a condition with this string to identify the UI
element it should use for rendering the condition.
ConditionTypes support either
propertyPrefix or propertyName , but not
both.
|
isDefault
| If set to "true", the condition type is used as the selected condition type if a new condition is added to a rule via the UI. Make sure that there's only a single default item because otherwise you cannot be sure which one will be selected. Default is 'false'. |
Table 3.1. All properties
Example with propertyName
attribute:
<perso:dateCondition conditionName="Date of Birth" propertyName="personal.dateofbirth"/>
This element makes the SelectionRulesField
use a DateCondition
if a
condition is defined on the personal.dateofbirth
property.
Example with propertyPrefix
attribute:
<perso:keywordCondition conditionName='Explicit Interest' propertyPrefix='explicit' isDefault='true'/>
This element makes the SelectionRulesField
use a KeywordCondition
for all properties starting with the prefix "explicit" followed by ".", for example,
"explicit.science".
The order of elements in conditionItems
is relevant for item selection. The
SelectionRulesField
searches the list top to bottom to find the Condition for a
given property name. It uses the first item whose propertyName
or
propertyPrefix
matches.
ConditionsField
The ConditionsField
property editor is similar to the
SelectionRulesEditor
in that it allows you to define a list of customer segment
conditions using the same components and configuration, except for the
SegmentCondition
.
Using the AddConditionItemsPlugin to add conditions to the property editors
The SelectionRuleField
as well as the ConditionsField
support the
AddConditionItemsPlugin
to allow the configuration of condition items via plugin
rules. Plugin rules are a mechanism provided by
CoreMedia Studio to allow
Studio plugins to modify common UI
components.
For example, you might want to keep the configuration of condition items specific to your CRM
system in the same project as your CAE/CRM integration. To this end, create a
CoreMedia Studio plugin containing plugin rules that
configure the condition items using the AddConditionItemsPlugin
and introduce it
as a Maven dependency to your CoreMedia Studio
web
application (for details, see the
CoreMedia Studio Developer Manual).
Module p13n-studio
of the CoreMedia Blueprint development workspace shows
how to configure selection rules based on Elastic Social contexts.