CMS for personalized content?

59 views
Skip to first unread message

david hendler

unread,
Aug 25, 2017, 12:01:32 PM8/25/17
to content...@googlegroups.com
Does anyone have experience with CMSes that can offer different content to different people? We have a closed global audience (only employees of the company can access the system), but we want to deliver different content based on criteria like population and job type.

Any suggestions, experiences, pitfalls to watch for?

Thanks!
David

Alex Faundez

unread,
Aug 25, 2017, 12:56:54 PM8/25/17
to Content Strategy
hi David,

Episerver CMS recently demoed their latest release and it includes a rather interesting content personalisation feature, where specific content is delivered to specific audiences.

We haven't tested it though.

a

Kevin Nichols

unread,
Aug 25, 2017, 2:16:15 PM8/25/17
to content...@googlegroups.com
David: Happy to talk further. You want a componentized CMS that allows you to build logic at the template / component level to target user based on rules. Essentially it is rules-based, explicit personalization approach. Many CMS's can handle this, but it's all about coming up with the rules and then ensuring these are properly implemented. Reach out to me directly, if you have specific questions. Kevin 

--
You received this message because you are subscribed to the Google Groups "Content Strategy" group.
To unsubscribe from this group and stop receiving emails from it, send an email to contentstrategy+unsubscribe@googlegroups.com.
To post to this group, send email to contentstrategy@googlegroups.com.
Visit this group at https://groups.google.com/group/contentstrategy.
For more options, visit https://groups.google.com/d/optout.

Hilary Marsh

unread,
Aug 25, 2017, 2:20:17 PM8/25/17
to content...@googlegroups.com
I would also ask other questions:

Do you have a steady enough stream of content for each audience to justify the separation?
Are you sure that each audience doesn’t want the information you won’t be showing them?
How will you manage people’s control over what they see? Especially for an intranet, folks who manage people in other jobs, other locations may need to see content that’s not directly intended for them.

—Hilary


Hilary Marsh
President and Chief Strategist, Content Company

312-806-7854  |  hil...@contentcompany.biz

Content strategy consultant, speaker, teacher
http://www.contentcompany.biz
Set up a chat: https://hilarymarsh.youcanbook.me 
Subscribe to my newsletter: http://www.contentcompany.biz/newsletter





To unsubscribe from this group and stop receiving emails from it, send an email to contentstrate...@googlegroups.com.
To post to this group, send email to content...@googlegroups.com.

david hendler

unread,
Aug 25, 2017, 5:55:08 PM8/25/17
to content...@googlegroups.com
Thanks for the follow up questions.

To answer you, Hilary: this is for HR content (policies, programs, and forms) that have different documents for different audiences. That is, each location might have different dress codes that apply to their associates. In order to keep people from being confused, we want to only show a given location's dress code to the affected associates.

We actually do have 3 kinds of permission groups, though: associate level, manager, and HR. Each level up shows a wider range of content. A manager, for instance, might have to see the policies for many of their directs in different locations. HR might need to see content for several managers over many regions.

Kevin, to your point: we do have the rules made up. We have been cleaning up a lot of the rules, and in fact I am in the process of auditing them to make sure we don't ghost rules lingering about. When we first launched 6 years ago, there were a lot of bad practices put in place, which I have been fixing since I came aboard last year.

Cruce Saunders

unread,
Aug 25, 2017, 6:32:31 PM8/25/17
to content...@googlegroups.com

David,

A few thoughts.  Just did one of these with a national franchisor that needed to vary sensitive internal content by employee type, region, state, then location.  

Very straightforward authenticated-user personalization is widely supported.  To accomplish the personalization scenarios described, we would need the following: 

structured content:   every CMS does this, but the content must be structured to support the personalization needs. e.g. build a content model that chunks down to the parts different users need to consume uniquely.

taxonomy and metadata:  content should be associated with metadata that aims to it different consumers and scenarios (e.g. location ID)

user accounts:  we need to be able to authenticate against your HRIS, or other director, and match up specific profile data to a CMS record

roles and segments:   segments must be defined within the CMS to support content-targeting by segment

rules:  condition-based content targeting at the level of presentation components makes it easier for business users to target content (e.g. an author should be able to define: what should display in this widget for each of my audience segments?)


For a more advanced form of personalization, one would also look for:

session data on platform:   ideally we have session data on platform with the CMS.  This allows us to target content by browse-behavior in addition to profile data.

session scoring:  ideally the CMS has some sort of lead-scoring or other form of session-scoring functionality.  this, combined with rules, makes it possible to personalize search results or navigation items by demonstrated interest, or other such session-based information.

Technically one could accomplish what you're needing to accomplish with any number of CMS platforms, or even Sharepoint if you must.   

For the scenario you describe, the ones I'd recommend including in a selection process include:

Kentico
Sitecore
Ingeniux
Episerver
Sitefinity

Hope this helps in the search!

Cruce

-- 

Richard Sheffield

unread,
Aug 26, 2017, 1:59:40 AM8/26/17
to content...@googlegroups.com
You have been given some great advice here! I agree that rules-based segmentation via a CMS is the way to go.

The one thing I'd add is to investigate where the data is stored that you want the rules to operate against. Can this data store be accessed by the CMS? Is it robust enough to have the CMS connect directly to it so each user's attributes can be read in real time at page load? If not you may have to set up a nightly dump of user data into a data store that won't slow down page load time.  Getting the page to load fast enough is going to be the hard part if the rules get complicated.

Also, don't forget to factor in the time it will take to have content folks go through all your old content to add the needed metadata to make the rules work. And migrating content into a new CMS is always a nightmare :)

Best of luck!
Richard Sheffield
Reply all
Reply to author
Forward
0 new messages