Personalization Hub Manual / Version 2301
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:
SelectionRulesFieldis an editor to be used to define content selection rulesConditionsFieldis 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.
propertyNameis 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.allowedContentTypeis 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.


