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.
Personalization of headless SPA projects is also supported.
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 Contacts 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
Content variants are not limited to pages only. You may also create a variant of a component within a page. Component personalization makes personalizing content easier 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 is then 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 enabled in DX Core by default but you can disable or restrict it.
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
Every trait has inherent allowed values. For example, locations are countries, ages are numbers, and genders are either male or female. Create traits that have a clear set of allowed values. Traits that have vague values are difficult to detect and assign. Also, make sure the trait applies to the majority of your audience. ``New vs. returning visitor'' is a good trait because the values are easy to detect and it applies to every visitor.
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
equalsstring comparison between the trait and the cookie value.
You can also create your own traits.
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.
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
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 date-based local rule serves this content for the days around 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 the 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 - Americasserves 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 the audience to match. Then the content variant is served.
Think of segments having an OR condition and local rules an AND condition.
audience matches IF date = 2019-05-015 AND weather = sunny AND (segment = "Americas visitors" OR segment = "Returning visitors")
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:
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
Create a segment only when you know your audience well and have targeted
at least one successful campaign to them using local rules. Visitors who
share a combination of traits are good candidates for segmentation if
they respond well to personalization. For example, add visitors who
previously bought a product to a
Previous buyers segment and offer
them a discount as a reward for return business. Segmentation helps you
repeat successful personalization experiments. Start with local rules,
move to segmentation later.
The traits of a segment can be combined with either a logical AND or a logical OR:
segment matches IF trait 1 matches AND trait 2 matches AND trait 3 matches ...
segment matches IF trait 1 matches OR trait 2 matches OR trait 3 matches ...
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 "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 DX Core 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
module changes cache configuration during installation. It creates a
property and sets it to
In DX Core, page variants are cached automatically. Magnolia generates cache entries for each page variant by including trait information in the cache keys. Component variants are cached with the Advanced Cache module.
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.
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
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
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 behavior 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-core: commands: default: personalizationActivation: itemTypes: mgnl:contentNode,mgnl:componentVariants,mgnl:variants,mgnl:variant