From our Depsters July 31, 2018
Personalisation in SDL Tridion Web 8
SDL Tridion featured some useful mechanisms to enable personalisation that were part of the “legacy” Profiling & Personalisation API designed to integrate with the Ambient Data Framework. SDL have since replaced this with Experience Optimisation (formally Smart Target), but you can re-enable the legacy functionality with a little work to get a very modern and flexible approach to personalised content.
There are two personalisation mechanisms that we’re going to cover in this post:
- Contextual Evaluation: Evaluate Target Groups against a customer profile to include or exclude content accordingly.
- Transformation: Use a custom syntax to include tokens within the content that can be ‘transformed’ and replaced with customer profile property values (with optional fallbacks).
Our technology stack is SDL Web 8 with DXA v2.0 (C# Asp.Net), along with the DXA Model Service registered in the CIS (Content Interaction Services) using the new R2 data model.
Enabling Contextual Evaluation
The first thing to do is to ensure that we include Target Group data within the Page R2 model. We do this by registering an additional type name for our model builder pipeline. This is a semicolon delimited list of classes to execute in-order when building the R2 model(s).
- From within the CME, navigate to wherever you installed the DXA R2 Template Building Blocks.
- Open the ‘Render Page Content’ TBB.
- Select the ‘Source’ tab.
- Update the modelBuilderTypeNames parameter to include ‘AddTargetGroupsModelBuilder’ as the last item in the delimited array.
- Save and close the TBB.
You can test this change by creating a new Target Group and adding one or more definitions. Within a pages Component Presentations tab, and with an individual Component Presentation selected, you should see your Target Group in the ‘Target Groups’ tab (see screen grab below).
If you check one or more Target Groups, and preview the page you should see the Target Group data included within the ExtensionData property for the associated Entity:
Now we have the data available, we just need to be able to evaluate it at render-time within our presentation application. To do this we will create a customised PageController in our DXA web application.
We will use the SiteConfiguration to access the ModelServiceProvider and subsequently use it to get the PageModelData using the Sdl.Web.DataModel assembly. This is a strongly typed model representing the page which we can traverse (similar to the PageModel) to iterate over regions and entities so that we can access the ExtensionData.
This evaluation of the Target Groups will result in a List<RegionModelData> representing all regions that contain at least one entity evaluating to true with all entities that evaluated to false having been removed.
This can be assigned to the PageModelData and used to create a PageModel using the ModelBuilderPipeline as the DefaultContentProvider does internally (line 129).
Similar to how we transformed the PageModelData after evaluating the Target Groups, we can also transform the entities themselves to apply changes to the content contained within. The easiest way to do this is to serialise the entity back to JSON and perform a Regex replacement.
The following Regex pattern can be used to match any replacement syntax present within the entity:
This pattern describes double curly brackets enclosing a claim name with an optional fallback value using pipe | as a separator e.g.
The claim name is an implementation detail that is facilitated by creating an IDictionary<string, string> to represent every customer claim name and value to be used for both contextual evaluation (note the dictionary passed into the evaluation methods) and any transformation replacements.
If using a Customer Data Platform, it should be simple to access the customer profile and convert it into a string dictionary. Otherwise, this could be retrieved via a CRM API or generated dynamically based on request information and interaction throughout the application.
By combining contextual evaluation and transformation you can achieve a robust and powerful personalisation strategy which is already very well integrated within the CME.
The biggest challenge is changing the request flow to include a mechanism to obtain a customer profile and the claims that describe the customer to apply against any personalisation.
There are also some considerations regarding caching since you can’t effectively cache personalised responses for an extended duration – we hope to cover this in a future post!