Personalization means adapting content to the visitor according to his or her personal preferences, needs and capabilities. A personalized website is more relevant and engaging than a static non-personalized site. Personalization turns a static pull experience into an interactive push relationship – the visitor indicates their interest and the website pushes matching content. Of all possible content variants that could be offered, personalization helps you serve the content that fits best. Content tailored to the visitor has a better chance of making a sale or persuading the visitor to stay longer.
Page personalization is an Enterprise Standard and Enterprise Pro feature; component personalization is an Enterprise Pro feature.
Variants are alternative content
A variant is an alternative content element that replaces the original element in personalized content delivery. Magnolia serves the variant instead of the original element when personalization rules match. A variant is a copy of the original element, edited to best suit the intended audience.
Variants are created in the same app where the original content element was created. For example, page variants are created in the Pages app.
Here are three variants of the Travel demo home page. Each variant targets users from a different region. The original page has a special variant icon which tells you this content has alternatives.
Variants are displayed under the original page but they are not children. They are copies. Variants don't inherit inheritable components from the original page, for example. Think of variants as "swaps" that take the place of the original page when personalization rules match.
Content variants are not limited to pages only. You may also create a variant of a component within a page. may substantially ease personalization of content because it allows the editor to personalize content in a scalable way. A page may in some cases feel like too big an item to personalize. Personalizing the whole page would mean copying a lot of redundant content if only a small portion of the page content has to be personalized.
For example, the page editor may want to set different contact hours for the visitors from Europe+Africa and for the visitors from the Middle East by adding just one short line of text to the whole page. This can be achieved by creating two variants of the Text and image component which forms a part of the Contact page in the Travel demo:
The page containing the component variants will then be marked with the variant icon:
Adding content variants to a page component does not produce a copy of the whole page.
Personalization of components is by default enabled in Magnolia EE Pro but it you can.
Traits describe the visitors
In order to personalize content you need to know something about the visitor. In Magnolia, we call that something a trait. A trait is an attribute of the visitor or visit that you can detect and assign a value to. For example, age is a trait. It tells you if the content is appropriate for the visitor.
Think of traits as characteristics of the visitor's persona:
- Yên is an 18-year-old Vietnamese speaker.
- John is a music-loving shopaholic.
- Carlo is a Boston-based marketing manager whose Honda Accord has 50,000 miles on the odometer.
Here are some traits commonly used for personalization:
- Date of visit
- Location of visit
- Language set in browser
Magnolia provides four traits out of the box:
- Date: Allows you to serve content based on the current date. For example, run a Valentine's Day campaign the week before February 14.
- Country: Allows you to target visitors from a particular country. For example, show product prices in pounds to U.K. visitors.
Visitor: Allows you to detect if a visitor is new, registered or logged in. For example, greet a logged-in visitor by their name.
- Cookie: Allows you to detect browser cookies and compare their values to traits. For example, show a weather forecast for the holiday destination the user searched for. The cookie trait makes simple "equals" string comparison between the trait and the cookie value.
You can also create your own traits.
Explicit and implicit personalization
You may have heard about explicit and implicit personalization. In Magnolia you can do both. It depends on the trait.
- Explicit personalization is based on traits that visitors declare and choose themselves. Explicit traits are typically stored in profile attributes such as age, gender and language. Visitors populate the profile knowingly, usually by filling in a form. You can then connect traits to the profile attributes. In this type of personalization the website pushes content in which the user has an explicit interest.
- Implicit personalization is based on tracking user behavior as they navigate the site. Implicit traits may also be stored in a user profile but the difference is that these traits are not known to the user. Over time you learn more about the visitor as they click links and view pages. In this type of personalization the website pushes content that matches the visitor's past behavior.
You can mix explicit and implicit traits. For example, you can ask users to declare their gender explicitly but then use implicit behavioral analysis to find out what products they like. Similarly, you can collect a given trait using either method: you could analyze visitor behavior to figure out if they are interested in movies or you could just ask them. The difference between explicit and implicit traits is really just academic.
Rules filter content
Magnolia's personalization is rule based. Rules push relevant content to the front and filter irrelevant content out. Rules can be based on any trait you can reliably detect and analyze, such as profile attributes, preferences, past behavior, search terms, or interests.
To create a rule, define permitted values for a trait. For example, "Age >= 18" is a rule. When a visitor is 20 years old, the rule is met and personalized content is served.
Examples of rules:
- Age >= 18
- Gender = female
- Interests include movies
- Date of visit = 2/14
- Location of visit = China
- Language set in browser = English
Choosing an audience
You can choose the audience for a content variant in two ways:
- Local rule: The simplest way to choose an audience is to pick a trait and define permitted values for it. This creates a local rule. In the example below, the local rule "Start date = 2016-05-01 and End date = 2015-05-08" serves this content for the week leading up to Mother's Day. Start your personalization experiments with a local rule because it is transparent and easy to understand.
- Segment: Once you know your audience well divide it into segments. Choose a segment as audience when you want to target the variant to visitors who have responded to personalization well in the past. In the example below, the segment "Economic-regions - Americas" serves this content variant only to visitors from the Americas.
You can use segments and local rules at the same time. One of the segments and all the local rules must be true for audience to match. Then the content variant is served.
Think of segments having an OR condition and local rules an AND condition.
To simplify the process of assigning rules, you can divide the entire visitor population into segments. A segment is all the visitors who meet a given rule. This means that people in the segment have common needs and priorities. It must be large enough to be measurable, stable over time, reachable and responsive. These qualities make the segment a meaningful target audience for repeated campaigns.
Examples of segments and the rules that define them:
- Chinese moviegoers
- Age >= 18
- Interests include movies
- Location of visit = China
- Returning marketing managers
- Job title = "Marketing Manager" OR "CMO"
- Type of visitor = returning
- Interests include photography
- Has Flickr account = true
The traits of a segment can be combined with either a logical AND or a logical OR:
A segment defined in the following way will make the content available only if ALL of the following three traits match (i.e. the user has logged in, comes from the United States, and accesses the content on 4 July 2020):
Persona is a hypothetical visitor who represents the target audience. The persona has the same goals as other visitors in a segment group. Use personas together with segmentation to test content variants. If a variant makes sense for the persona then it is suitable for everybody in the same segment.
Describe the persona in a short paragraph that explains their behavior, needs and goals. Add a few fictional personal details to make the persona a realistic character. A realistic persona belongs to more than one segment at the same time. For example, a persona can be interested in both music and technology at the same time.
Use personas to preview content variants. Personas are helpful because they put a personal human face on otherwise abstract data about visitors. By thinking about the needs of a fictional persona you can better infer what a real person might need.
Caching of personalized content
Caching "realizes a performance increase for transfers of data that is being repeatedly transferred". In Magnolia, caching of personalized pages and pages with personalized components is possible in Enterprise Edition Pro with the Advanced Cache for Personalization (ACP) module. The module caches content variants automatically.
Without the ACP module, cache is bypassed for any content that has variants. The Personalization module changes cache configuration during installation. It creates a
/modules/cache/config/contentCaching/defaultPageCache/cachePolicy/ttlVoters/PersonalizedContentTtlVoter@class property and sets it to
Caching in EE Standard
In Magnolia EE Standard, personalized pages are not cached. Cache will generate a non-cacheable entry under the cache key representing page with variants and therefore effectively disable caching of the variants.
Caching in EE Pro
In Magnolia EE Pro, page variants are cached automatically. Magnolia generates cache entries for each page variant by including trait information in the cache keys.
In Magnolia EE Pro, component variants are cached with the ACP module version 1.8. The module is bundled only with the 5.4.9 EE Pro component personalization webapp. With 5.5 EE Pro, caching of pages with component variants will be enabled in all bundle types.
Caching of a page containing component variants means that a separate version of the page is cached for each component variant when the component variant is requested. For example, if a page contains two personalized components (A and B), each component has two variants (A1, A2, B1, B2), and if the combination A1 + B2 is valid for a visitor, this combination will be stored in the cache.
Overview of caching and personalization features by editions
|Cache feature||CE||EE Std||EE Pro||Note|
|Caching of normal pages|
|Caching of personalized pages||Available with any EE Pro 5.4+ bundle.|
|Caching of pages with personalized components|
In 5.4.9 EE Pro, bundled only with the cp13n webapp.
In 5.5+ EE Pro, included in all bundles.
The Preview app allows you to test personalized content. You can impersonate a visitor to verify that the correct page variant is served. The impersonated visitor can be a persona or a mix of local traits. The Preview app looks just like the preview in the Pages app but it has a sidebar for selecting the persona and traits.
First matching variant wins. If two or more variants match the rules, Magnolia serves whatever variant is first under the parent page. This is important to understand when troubleshooting why your variant is not served. Is another matching variant in a higher position? Move your variant higher.
A page and its variants are linked via UUID. Each variant has a
mgnl:variationOf property whose value is the parent page UUID. The property links a variant to its parent. This is important to understand when you export variants to other Magnolia instances for testing. The page you export from and the page you import to must have the same UUID, meaning the original page must exist in the target instance. Publish or export the original page to the target environment first.
Pages that have variants have a special mixinType
mgnl:hasVariant. You can only import variants to a page that already has variants. The
variants node must exist under the target page. You cannot import a variant under a page that has no existing variants as it won't have the necessary mixinType
Page variants are not published by default
If page variants exist for a page, the variants are not published when you publish the page. By default, only page content such as page areas or component variants are published when you publish a page.
This behaviour can be changed by modifying the Publish action. To be able to publish also page variants with the command, add the
mgnl:variant node types to the
itemTypes property of the
personalizationActivation command in the
Personalization & integrations
If you want to use a personalization engine of an external system, see how it was done for Customer segments in IBM WebSphere Commerce Integration module or the example how to retrieve traits from SugarCRM Connector.
Visitor: Allows you to detect if a visitor is new, returning or logged in. For example, greet a logged-in visitor by their name.