building on magnolia's personalization
TRANSCRIPT
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 [email protected]
Telefon +49 (0) 30 283 921-0 Aperto AG | Chausseestr. 5 | 10115 Berlin