CoreMedia Adaptive Personalization is a collection of building blocks intended to assist you in leveraging the versatility of the CAE to implement dynamic and personalized content delivery. The basic idea is that each request to the site by a visitor is associated with context data and that this data is used to determine what is to be delivered to the visitor. Contexts might represent arbitrary things about the user and his environment, such as the user's current interests, the location from which the user accesses the site, and the device used.

Figure 3.5. Adaptive Personalization overview

CoreMedia Adaptive Personalization runs partly within the CAE delivery component to evaluate the selection and choice of content based on your settings. CoreMedia Adaptive Personalization also depends on content types in the CoreMedia content repository to persist certain settings and personalization rules, representing the personalized content you want to place on your site. These content types can be edited conveniently through CoreMedia's web based editor by using the Adaptive Personalization Editor Plugin. Using the CoreMedia Adaptive Personalization content types in your publication workflow, you can place personalized content just like you would place any other content, using the same editing metaphors and workflows as with any other CoreMedia content.

Both components are integrated into CoreMedia Blueprint by default. CoreMedia Blueprint already has suitable content types in place. When using a custom content type model, it will be necessary to model suitable content types for Adaptive Personalization and configure their usage according to documentation.

Dedicated personalization content items in the content repository are used to manage personalization of a site editorially. The type Personalized Content represents personalized content by storing a Markup property with a set of selection rules used to decide what content to render when a request is processed in the CAE. The type Customer Segment allows you to define segments of website users based on conditional rules. Using the same selection rule logic as the type Personalized Content, this type stores the rules as a String property. Customer Segments can then in term be used within a matching condition type in Personalized Content content items. The type Test User Context can be used by editors within CoreMedia Studio to switch user contexts within the preview pane to test and preview the effects of personalization settings before publishing any content items to a live website. These content items are edited, placed and published from within CoreMedia Studio like any other content item - except the test user contexts which have no effect or use when published. During delivery of those content items, CoreMedia Adaptive Personalization components running within the CAE will interpret and evaluate the contents of those content items in order to render matching, personalized content based on the user's request and the user context.

The CAE has access to a pool of context sources addressed through the Context API, which is also described in detail in this manual. Out of the box, CoreMedia Adaptive Personalization supports storing user context information in cookies. For each request, the CAE can determine the specific context using the contexts available through the Context API implement context sources. The information stored in those contexts can be used to define selection rules in Personalized Content and User Segment content items.

The evaluation of dynamic, request specific selection rules per request is costly in terms of computation. Because of this, CoreMedia Adaptive Personalization facilitates the caching features already in place in the CAE and computes a cacheable, precomputed representation of a set of selection rules, using both CAE data views and cache keys where appropriate. This minimizes the impact of personalization on CAE performance.

Adaptive Personalization in the CAE

Within the CAE a high level point of view request processing looks like in figure.

Figure 3.6. Request processing in the CAE

CoreMedia Adaptive Personalization integrates into the CAE using the standard Spring facilities and API. Within the CoreMedia Blueprint development workspace, Adaptive Personalization is already be integrated in the CAE setup. Refer to the installation documentation for details about how to manipulate the Spring configuration of CoreMedia Adaptive Personalization.

Within the CAE, Adaptive Personalization performs two basic functions:

Context information must be collected before processing a request and can be persisted after having processed the request. This can be achieved through Spring Web MVC interceptors or servlet filters. Evaluation of content selection rules may be performed while processing a request, for example, using content bean logic.

How contexts, properties, conditions and personas work together

In CoreMedia Adaptive Personalization the information about a website users context is stored in a so called ContextCollection that can be best thought of as a request scope map holding the request's context objects. All context sources that are configured via the Spring application context are called to retrieve and store their context information for the given Request into the request - and therefore usually user-specific - ContextCollection. A common scenario is to instantiate a ContextCollection when a request hits the CoreMedia Content Application Engine (CAE) with enabled CoreMedia Adaptive Personalization. Alternatively, a ContextCollection can be implemented using thread local storage, so that it is effectively a singleton bean (as the DefaultContextCollection).

A context is identified by a name (“keywords”, “personal” or “system”, for example) and can store arbitrary data. Usually (at least the default contexts that are shipped with the product) the context sources implement the PropertyProvider interface which requires that a context stores Map-like information in key/value pairs. Therefore, the properties of a given context are identified by the context name and property names with corresponding values, for example a numeric value, a string value, a date value.

Example

<contextname>.<propertyname>=<value>

The <contextname>.<propertyname> pattern is also used in personalization selection rules to identify the context information that will be used in a rule.

Examples

select <content> if <contextname>.<propertyname> \
  <operator> <value>
select content:1234 if keyword.sports > 0.5

In the Selection Rules editor, which is part of the CoreMedia Studio plug-in, you can use different UI components to define different conditions in personalization rules. Which UI component is used, can be configured by a manually mapping from context property names to component types. This is, for example, done in CMSelectionRulesForm.mxml and CMSegmentForm.mxml of the CoreMedia Blueprint development workspace.

When the CAE evaluates a personalization rule for a given request, the SelectionRulesProcessor uses the already known <contextname>.<propertyname> pattern to check whether the values in the current ContextCollection match the rules or not. For more details on the selection rule execution please refer to Section 3.3.3, “Working With Selection Rule Lists”.

Due to the map-style nature of the context data, it is very easy to create test data for editorial usage. That is exactly how the persona contexts work in the personalization UI (the PersonaSelector).

Instead of actually instantiating a ContextSource with an identifier “keyword” and the property “sports” and value 70% you can simply write “keyword.sports=0.7” into the persona context. This information is then used in the CAE as context information and the real “keyword” ContextSource is ignored.

When the CAE evaluates a personalization rule, an executable representation of the rule string is created or retrieved from the cache and supplied with the active user’s ContextCollection. This representation uses the <contextname>.<propertyname> pattern encoded in the individual conditions to retrieve the corresponding property values from the ContextCollection and applies the specified comparison operator from the personalization rule.