Published on November 27, 2015 by Zak Greant
In part I of this post, I showed basic use of Magnolia's personalization features for time-based campaign pages. In this post, I'll write about more advanced usage of the approach and outline some of its limitations.
Use cases and issues
Managing multiple campaigns with multiple pages. The approach I outlined in part I (assigning dates to a page variant using individual trait) works well enough if you have a small number of campaigns that involve a small number of pages. However, when you need to manage multiple overlapping campaigns that involve multiple pages, you need to use a more structured approach.
Managing campaigns with uncertain dates. If you primarily manage campaigns with certain dates – such as holiday-based retail campaigns – you probably won't need to adjust the dates of your campaigns once they are set up. If your campaigns are instead driven by less certain things like funding drives, playoff outcomes or ski seasons, you may need to adjust the display dates of many variants. You really don't want to this for every page variant (as you'd be forced to do if you used the simple method from the first part.)
Different assets per campaign. While many of the assets will be shared across pages (or content app items), each campaign may also have many unique assets. For example, your Nowruz campaign may involve holiday-specific versions of most common assets for your site. You need ways to make it easy to manage all these different assets without confusion.
Use short and consistent names for your campaigns. First, choose short and understandable names for your campaigns. If the name would work as a non-ironic hashtag, then it's about the right length.This will help you easily understand what page variants are a part of which campaign. You should use the same short name in all relevant contexts – audience names for page variants, asset folder names and segment names.
Create one segment per campaign. For the multiple page/campaign and uncertain date use cases, it's best to create a dedicated segment for the campaign.
Once you've created a segment, add a date trait and set the appropriate start and end dates for your campaign.
As you create page variants for your campaigns and set an audience for them, just use one of your campaign segments (instead of setting a date trait for the audience.)
Using one segment per campaign:
If you need to change the date for a campaign, you only need to change it in a single place to update every associated page variant.
Group assets using folders. In the Assets app, create one folder per campaign and put all campaign-related assets in it. This will make it much easier to avoid update conflicts (where one person overwrites another person's changes.)
Campaign dates are based on server date and time. When Magnolia decides what date and time to use for selecting a variant to show to a visitor, it uses the date and time on the server. You can make Magnolia use the visitors date and time by creating a custom personalization trait.
Day-level granularity. The default date trait doesn't let you specify times. The start time is 00:00:01 on the start date specified and the end time is 23:59:59 on the end date specified. If you need more granular control, you'll need create a custom personalization trait.
Mix carefully with Scheduled Publishing. Using personalization this way allows editors to see the state of the site at any future point in time using the Preview app. However, any pages that have been scheduled for publishing with the scheduled publishing feature will be invisible to editors using the Preview app. It's best to avoid mixing the two approaches.
Beware of auto-generated content. If parts of your site structure only exist for certain campaigns, you may find that auto-generated content – such as menus – may not work quite as you expect. In these cases test to make sure you don't have unexpected results. Alternately, it may be wiser to use microsites for certain campaigns.
Zak Greant is a writer, programmer and cook with a long history of involvement with the Free Software and Open Source movements. In the past two decades, he's worked with or been a contributor to the PHP project, MySQL AB, the Mozilla Foundation, the Open Source Initiative, the Free Software Foundation, eZ Systems AS, the WikiMedia Foundation, along with various other FLOSS organizations and startups. At Magnolia, he focuses on a wide range of projects from communications and marketing to open source strategy and licensing.
See all posts on Zak Greant