Building on Magnolia‘s Personalization Magnolia Conference 2015, Technical Track

Basel, June 9th 2015

About Jörg

•  Software engineering background •  Joined Aperto in 2010

•  Technical Architect for exciting and demanding Magnolia projects since then

E.g.

•  Middle East Broadcasting Company Dubai http://www.mbc.net/

•  Kanton Basel-Stadt http://www.bs.ch/ Jörg von Frantzius Systems Architect

Of the largest owner-runned advertising agencies in Germany

BERLIN BASEL

DUBAI

BEIJING

SAIGON

Top

10

Mio

32 Turnover in 2014

Platz

01 highest share of digital services of all full-service agencies in Germany

heads

370 Employees worldwide

MIAMI

We‘re designing the digitalized World.

Aperto + Magnolia: strong partnership since 2006

•  More than 40 successfully implemented Magnolia projects

•  High competence in the execution and implementation of large and technologically sophisticated projects, e.g. business integration, high performance and security

•  Joint product development with Magnolia (STK – Standard Templating Kit)

•  Over 50 Magnolia-experienced and trained employees in our departments technology, UX Design, Design and Project Management

•  Experienced with international projects in Germany, China, Dubai, Switzerland and UK

Personalization?

What it‘s about

Visitors of your site Aren’t all the same! So why show them All the same content? Positive effects Depend on what your site’s goals are …

Positive effects

In general: •  Content more relevant to user •  More engaging website

With monetization: •  Increase KPIs (Key Performance Indicators),

e.g. time spent, views per session

•  Increase sales •  Upselling (e.g. show next higher tariff) •  Cross-selling (e.g. show complementary product)

Required for Personalization: data about visitor

Requirement for Personalization: Information about the visitor! Can come from any digital source of information you have Can use multiple (different) sources at the same time Must be surfaced in Magnolia as „Custom Traits“ Requires some custom programming

(more on that later..)

Possible sources of information about visitors

•  Registration data from log-in area

•  CRM system, in combination with log-in area

•  Predictive behavioural targeting provider

•  Own user behaviour tracking

•  Social login (e.g. Facebook, Google+)

Personalization in real life

Imagine you go to a shop in real life, and ask a shop assistant for recommendations … He/she will certainly look at you (age, gender, clothes, etc.) To base his recommendations! (Likely also learns more about you than any tracking provider will ever do)

Connect with back office sales data

In a banking or insurance site, connecting with back office data Allows to recommend products for cross- or upselling Or to simply provide access to recommendable information E.g. health insurance may want to recommend prevention courses Or specific health information, based on age or gender Forms, PDFs or frequently needed information related to specific product that visitor is known to own

Can be prominently shown to reduce calls into call center

Reuse back office connection existing already for online services

If you already have online self-services Connected to user database

This could mean a treasure you can lift with personalization If you don’t have user self-services yet, or only simple ones Creating or expanding them and combining with personalization May create win-win situation: •  Site gains value for the customer (with new services) •  Site gains value for you (with benefits from personalization)

Magnolia’s Personalization feature most of all allows you to Target editorial content Maintained within Magnolia itself You could also develop a component with custom logic based on user data That works without any of Magnolia’s Personalization features But that’s a different story … (content residing outside of Magnolia)

Personalization in Magnolia = targeting content maintained within Magnolia itself

Segmentation

Of course, you cannot target content for each user individually (unless you have very few visitors and a lot of editors …)

So you need to identify “Segments” within your user base Users within same Segment will receive the same content

Users within same segment have traits in common

Segmentation entirely depends on your business E.g. following your marketing strategies

OK, getting more techical now

(this is not the business track after all)

Technical key concepts of Personalization in Magnolia

Magnolia 5.3 introduced Key concepts for Personalization

As APIs and in UI: •  Traits of visitors •  Rules matching on traits •  Segments making rules reusable •  Page variants containing personalized content •  Personas for previewing personalized results

Traits

An example trait definition (found in module configuration):

Available Traits

Available traits are: all traits defined in all “traits” folders of all modules

Magnolia collects them for you and offers them for selection where applicable, e.g. in rule definitions:

Sample Traits

Magnolia contains 3 sample traits out-of-the-box

•  Date: allows to target content to date range (simply the current date, not really a trait of the visitor…)

•  Visitor: allows to target new users vs. returning users via cookies

•  Country: maps visitor IP to country

These may already be useful to some degree, but Custom Traits is where things start to get interesting (to be discussed in detail later on..)

Rules

Rules are defined to match visitors / audiences

A rule may allow to define a value range For a trait with a discrete value, e.g. a date Multiple traits may be combined (either matching all or any of the traits)

Segments

A Segment simply gives a name to a rule, and makes it re-usable in multiple places

Maintained in “Segments” App Sample shows EMEA Segment Matching any of its countries

Page Variants I

Out-of-the box, targeting currently is only possible on page level

Page Variants II

Creating a page variant effectively creates a copy of the page (component-based variants to be shown in proof-of-concept later on)

For each page-variant, the desired audience can be chosen By selecting segments, as ad-hoc rules, or both

Personas

Personas define sample trait values, maintained in “Personas” App that you can use for previewing targeted content

Can also add ad-hoc trait values in „Preview as visitor“ In addition to values defined in selected Persona

Personas have discrete trait values

Entering persona trait values is different from entering rules: While a rule may allow a range, e.g. for a date, the persona will allow only a single value That’s because you want to preview as a single visitor, not as a range of visitors!

You will need Custom Traits

Custom traits

A custom trait is required if you want to connect Your specific user profile data

with Magnolia’s Personalization Maybe over time 3rd party modules will be developed Contributing connection e.g. with Facebook or other social login profiles Custom traits require custom development Complex at first sight, but well worth the effort!

Custom traits development

Very recommendable documentation in Magnolia Wiki Let’s look at previous trait definition again …

Custom traits development

traitClass e.g. java.util.Date Java class of the trait value, value determined with each request

ruleField

For entering rules for this trait:

valueField For entering a single value of this trait in Persona and ad-hoc in “Preview as visitor”

Custom traits development

defaultPreviewTrait Optional. Adds the trait to the Preview app by default, will otherwise turn up only in Personas’ Traits

defaultRuleTrait

Optional. Adds the trait in the Choose audience dialog in the Pages app by default. Set this property to true for any traits that editors use routinely.

How does it work?

(For developers …)

Custom traits: how does it work?

Let’s look at the two remaining parts of the trait definition: voterClass

Decides wheter a trait’s concrete value matches a given rule, e.g. DateVoter: does given single date fall within date range given in rule?

converterClass Needed to simulate trait values as request parameters during “Preview as visitor”

Turns request parameter into trait value, and vice-versa

Trait detection in filter class

What you don’t see in the trait definition: How is the trait’s value determined during request execution?

Happens in specialized request filter class Puts result in TraitCollector (available for injection in request-scope) In previous example: DateDetectorFilter

So how do filter, trait collector and voter work together?

Filter, trait collector and voter collaboration

Filter stores trait value in TraitCollector, where voter gets it from

Detection and evaluation decoupled through TraitCollector

Trait detection and evaluation (rule matching) are decoupled

Both “real” trait detection on public and trait simulation in preview put their trait values in TraitCollector And that’s where trait evaluation gets it from, in both cases That means: You can edit and target personalized content before real trait detection is fully developed

Leverage personalization concepts without content variants

Above Personalization API can be leveraged without using content variants at all

Well-designed concepts that offer a lot of flexibility E.g. track categories of pages visited in persistent cookie Build component that displays automated list of recent articles in these categories Enjoy using “Preview as visitor” to test the result!

Personalization use-cases without variants

We used Rules + Segments to target whole pages (without variants) In a customer PoC

I.e. audience doesn’t see variant, but is able to see page at all Implementation: •  Filter for hiding pages that don’t match current visitor •  Customized navigation logic

•  Hides navigation items of pages hidden from current visitor

Component-based Personalization

A Proof of Concept

Page variations

Currently targeted variations must be created on page-level

Traits and segments are assigned to an entire page One page copy must be maintained for each target audience

Reducing content maintenance

Being able to target individual components significantly reduces editorial work Magnolia has this on roadmap for 5.5 (from what I understood) Meanwhile PoC demonstrates feasability with some custom development

Targeting components

New “component box” is introduced

All component variants easily managed in a tabbed box Each tab provides content for one audience group Traits and segments directly assigned to a tab

Component variations

Segments and rules can be assigned per component

No longer necessary to create duplicate content One content page can be used to address several audiences “Preview as visitor” works as expected

4 component variations for different IP locations

Storage structure

•  “Component box” is a component with •  area “tabItems” containing

•  “componentBoxItem” components, each carrying •  mgnl:variantTitle •  Actual component to be rendered •  mgnl:ruleSet

mgnl:ruleSet stored by extending Magnolia’s own chooseAudience dialog Deserialized using Content2Bean, just like Magnolia does itself with page variants

Rendering

Model of area “tabItems” evaluates componentBoxItems’ rules + segments to determine matching component, stores result as request attribute

ComponentBoxItemModel.execute()

checks whether component was elected Returns RenderingModel.SKIP_RENDERING if it wasn’t

Thank you!

Jörg von Frantzius, Technical Architect E-Mail joerg.frantzius@aperto.com

Telefon +49 (0) 30 283 921-0 Aperto AG | Chausseestr. 5 | 10115 Berlin