Not Considering

Revive OOTB Personalization & Profiling functionality

TL;DR The idea is to make the Personalization & Profiling functionality (conditional Component Presentations and Target Groups) fully supported again:

This includes:

  • Ability to import/export Target Group definitions (using CM Import/Export API and Content Porter)
  • Ability to publish Target Groups separately (like with the Context Expressions extension)
  • Ability to define Target Groups based on "Customer Characteristics", "Tracking Keys" and "Context Engine claims" (user device related)
  • Support in Digital Experience Delivery and Digital Experience Accelerator to evaluate the conditions and keep track of "Tracking Keys".

 

Background:

Tridion may have been one of the first WCM/WEM systems which offered Out-Of-The-Box Personalization & Profiling (P&P) functionality:

  • The ability to make Component Presentations conditional (in the CME), based on "Target Groups"
  • The ability to define Target Groups (in the CME)
    • By simple expressions on "Customer Characteristics"  (basically, key/value pairs in a User Profile)
    • By simple expressions on "Tracking Keys"
      • These "Tracking Keys" (related to Keywords managed in CM) are used to keep track of how often the user has viewed a particular (set of) content.
  • Automatic generation of the required dynamic logic to implement this Personalization & Profiling on Delivery side.

However, for a long time this functionality seemed to be mainly a (RFI) "checkbox feature" and it didn't get a lot of attention (no further development). In SDL Web 8, it did not even end up in the new CIL API,  so that you won't be able to implement the dynamic logic using the CIL API.

Meanwhile, there was an earlier attempt to revive the concept of Target Groups in the form of the Context Expressions extension:

  • The ability to make Component Presentations conditional (in the CME), based on "Target Groups"
  • The ability to define Target Groups
    • By boolean expressions (using the JEXL language) on Context Engine claims (key/value pairs derived from the user's device)
  • The ability to publish Target Group definitions separately

This extension was intended for an integration with SDL's Campaign Management & Analytics (CMA) system, which took care of tracking and analytics and allowed definition of Target Groups based on the analytics, thus forming a closed loop.

However, SDL divested CMA and we didn't provide functionality to edit the JEXL expressions in CME.  We did create a DXA Context Expression Module which comes with a PowerShell script to set the JEXL expressions, but this is obviously not very user-friendly.

Furthermore, we provide Experience Optimization as a Personalization/Campaigning solution.

Rick Pannekoek
Parents

  • Adding some comments from an implementation perspective, you can ignore my vote as someone "on the inside."

    Functionally, at the start of projects, I've often seen the desire to change the presented Component Presentations on a page based on user actions, metadata, or some other context. +1 to the ability to tag Component Presentations with Target Groups (or some settings) for show/hide functionality. Alternatively, I'd want the same functionality but using Experience Optimization Promotions.

    For personalization in general, I've seen challenges with the delivery approach and what tool or technology controls that context. I've also seen the actual implementation will depend on the team at the time and their technology preferences. A few times it was a 3rd-party rules engine or some attribute that controlled the "context." And the delivery might vary from static html, to ASPX or JSP pages, to MVC, or something client side (Single Page Application).

    I would want the approach to work in more customer scenarios, for sure MVC setups and SPAs, either out-of-the-box in DXA or through implementation. Ideally the boolean expressions could be extensible or agnostic of the JEXL expressions (where editor could enter values and the application could do something with them). Otherwise there's been a separate, but similar request for "Component Presentation Metadata."

    On the Experience Optimization side, I've seen implementations that added the ability to move a set of personalized content around on the page (move "Region" Component) as well as enable/disable personalization. So the approach should be region-friendly and ideally line up with XO (if not consolidated into XO itself).

Comment

  • Adding some comments from an implementation perspective, you can ignore my vote as someone "on the inside."

    Functionally, at the start of projects, I've often seen the desire to change the presented Component Presentations on a page based on user actions, metadata, or some other context. +1 to the ability to tag Component Presentations with Target Groups (or some settings) for show/hide functionality. Alternatively, I'd want the same functionality but using Experience Optimization Promotions.

    For personalization in general, I've seen challenges with the delivery approach and what tool or technology controls that context. I've also seen the actual implementation will depend on the team at the time and their technology preferences. A few times it was a 3rd-party rules engine or some attribute that controlled the "context." And the delivery might vary from static html, to ASPX or JSP pages, to MVC, or something client side (Single Page Application).

    I would want the approach to work in more customer scenarios, for sure MVC setups and SPAs, either out-of-the-box in DXA or through implementation. Ideally the boolean expressions could be extensible or agnostic of the JEXL expressions (where editor could enter values and the application could do something with them). Otherwise there's been a separate, but similar request for "Component Presentation Metadata."

    On the Experience Optimization side, I've seen implementations that added the ability to move a set of personalized content around on the page (move "Region" Component) as well as enable/disable personalization. So the approach should be region-friendly and ideally line up with XO (if not consolidated into XO itself).

Children
No Data