Stop Managing Humans in Your CMS

Too many times, a content management system becomes a people management system. Meaning, an organization uses the CMS to manage all the information about the people that consume the content -- users, members, customers, etc.

I think this happened because it was a natural extension of a CMS's user management system, and it integrated easily with permissions. The problem was (is?) that in doing this, we naturally bound identity to channel. If our user database was in the same system that we managed our website, then we effectively cemented those two together. But remember, a user is not necessarily a customer.

It's 2023, and we need to "lift out" the notion of human identity from our channel management. We need to acknowledge that humans exist apart from channels -- they might consume things on our website, but that's just one touch point. If we bind their identity to it, we miss out on chances to leverage personalization in other channels.

In 2021, we acquired Zaius, which became the Optimizely Data Platform. Zaius is a customer data platform (CDP), which is now part of Optimizely One.

CDPs are a "master identity databases" where you can track all your customer's behaviors and aggregate information about them. You can then query this information and use the resulting "segments" to take actions or run other campaigns. (Some years back, right when the CDP market began to expand, I wrote a long-ish primer on what it was and why it mattered. It might be worth a refresher.)

Using ODP, we can manage identity and preference data in a system apart from our website. In practical terms, this means we're moving "profile" data out of our CMS and into a centralized system. Our CMS will still have the concept of an "account" which is used for practical concerns like permissions, but all the preference data moves to ODP.

ODP has a fantastic API, and just to prove how easy it is to connect this to CMS, I wrote a quick C# wrapper for it. Here's a GitHub repo.

(You don't care about code? That's fine, but, read on -- I'll pick up the narrative in a bit.)

Now, I don't want to call this an "add-on" or even a "project," because it's just so simple. There's just one class with no dependencies. Use it as-written, or use it as a reference -- it's not hard to understand. You're welcome to do whatever you want with this, just know that I wrote it in about an hour, and it's not an official release. It's mainly to demonstrate how easy ODP is to use.

This class allows you to push and pull data to/from an ODP customer object bound to the current CMS user. So our CMS will store the barebones information for them to manage their authentication, and ODP will store everything else. This class helps you connect the two ("I know who they are in CMS, so get me the same person from ODP...")

It's this simple to get their identity and store some data about it.

var profile = OptiDataProfile.GetCurrentProfile();
profile.SetValue("preferred_mode", "dark");

That value will be pushed into an ODP object (which will be created if it doesn't exist) which can be bound to a key from their user account (usually email, but you could use user ID too). So, next time they come to your CMS site, just get the profile and read out what you want.

var profile = OptiDataProfile.GetCurrentProfile();
var mode = profile.GetString("preferred_mode");

(And keep in mind that you could always push or pull this from JavaScript. If you want to do that, go nuts. This code only helps if you want to talk directly from CMS to ODP.)

Now, back to our larger story --

You might be saying, "Why would I store their preferred viewing mode in ODP? Doesn't this only mean something to the CMS...?"

This is the mode of thinking we need to get out of.

There are at least two practical benefits to storing this in ODP, and this is where we get a little philosophical --

First, using ODP centralizes your user data and extends it to every channel. It transcends any particular digital property, and there's value in that. In this case, maybe they want Dark Mode on other properties? Should you change the mode for them on your mobile app (which has access to the same profile)?  How about your emails? 

The larger, deeper point is this: you should extend your user data past the immediate channel. To store this the channel-managing system (CMS, in this case), is effectively to say, "I will never use this data outside this website," and I feel like that's a little short-sighted. Think bigger, aim higher.

Second, ODP is a customer database that you can query. If you store their preferred viewing mode in a data platform like this, you can use it when creating customer segments. Now you have a location where you can take their viewing mode into account alongside all your other customer data.

They prefer Dark Mode and they're over 50? Maybe they're sensitive to light. Sell them some sunglasses.

They prefer Dark Mode, their first name is "Willow", and they live in Colorado? Maybe they're ecologically sensitive. Offer to round up their purchase and donate it to Greenpeace.

They prefer Dark Mode and they bought black lipstick? Maybe they're emo or goth. Promote the new My Chemical Romance album. (I didn't read this article, I swear...)

Anyway, you get the idea.

Maybe we're going off the rails a bit on Dark Mode, but these two points are indisputable:

1. Having more data about a customer gives you more options to segment them for personalization, experimentation, or other campaigns. Swap out dark mode for anything else: address, phone number, employer, favorite pizza topping, whatever.
   
   
2. Your customer's identity as a human with preferences and information trail should transcend the channel they're using at any given moment. They're not just your "web site visitor." They're a human. Treat them with that perspective.

More customer data is better than less. And having it in one location provides other benefits, so long as it's effortless to set it, get it, change it, and put it back.

Hopefully this library helps with that, and this article gave you a new perspective on it.