Content Personalization Prerequisites: The Content Model
You can’t have personalization without defining content types and the relationships between them.
Personalization means delivering content that is relevant to the user’s context.
With product recommendations and social media assets, this is quite straight-forward: you track your user’s behavior, create segments based on user data, and the platform’s algorithm does the hard work for you.
But what about content? How do you deliver a personalized message through your blog articles and static service pages, when all the content is locked down in templates?
How do you adjust the content dynamically, based on a user’s behavior, when all your pages are made of huge blocks of text?
The key to content personalization is treating content as data, and structuring it accordingly.
What is structured content?
Structured content means content that is broken down in small blocks that have clearly defined relationships with other blocks. All these content pieces are tagged with relevant metadata, and they come together in content templates, as the context demands it.
By structuring your content, tagging it, and modeling the logic and relationships between content types (blocks), you create form- and channel-free content that can be delivered to any device and user segment.
Structured content is also referred to as intelligent content because it is:
adaptable
responsive
accessible
easy to translate
machine-readable
free of design
channel-free
form-free
easy to find and retrieve
smartly connected
The art of structuring content is called content modeling, and its deliverable is a content model.
A content model is a formal representation of structured content as a collection of content types and the relationships between them.
What goes into a content model?
A content model tells the entire story of your domain or website in one big map. It defines all the content types that you need now or may need in the future.
It breaks these types down into smaller content components, in the same way that atomic design breaks the design of a page into the smallest blocks.
More content types together form a content module, and more modules assembled together define a content template.
If we take the opposite direction and go from large to small, a content type is a collection of content components and attributes, and each attribute is a key-value data pair.
So to visualize this easier:
key-value data pairs > attributes > content components > content types > content modules > content templates + metadata > content model
Let’s look at a practical example: the content model for a content marketing agency.
Image: content model for content marketing agency
As you can see, the model includes both content modules (Services, Distribution, Resources) and content types (Persona, Challenge, Consultancy, Training, etc).
When do we decide that something is a module and not a type? A module groups content types that are similar in nature. The content types are the main building blocks of the model, and the easiest way to think about them is as pages on your website.
So if a topic needs a dedicated page on your website, it’s a good candidate for a content type. With this in mind, you can think of content modules as overview pages.
Then, the content components will be sections of the pages that repeat. For example, a CTA block, or a header component, or an author box. The attributes will be all the fields that you want to have on the page, but cannot exist on their own.
For example, the author box can be reused across pages and it still makes sense on its own, so it’s a good candidate for a component. But the intro of a blog article doesn’t make sense out of context, so it should be an attribute.
Content templates and metadata model
For each content type, you will need to develop a page template. I like to structure the templates into the following parts:
Visible area — includes content components and attributes
Discovery metadata
Content metadata
Administrative metadata
Publishing metadata
Tracking metadata
The visible part of the page is the user-facing one. For a Specialist (author) page, for example, it can include the breadcrumbs, the author name, picture, specialty and bio, the social links, contact information, and an overview of the resources authored.
The descriptive metadata for this example will cover the basic page properties, so the page title, description, navigation title, meta title and meta description, social media title, and social media description, page asset (hero picture).
Some of these fields may be omitted if, for example, you prefer to have a single description that you use as page intro, meta description, and social media description. You decide how granular you want your content and metadata to be.
The discovery metadata includes things like the page URL, vanity URL, and redirects. You can also group here the content metadata if you prefer. The content metadata describes the target industry, persona, the service that the page is about, the benefit, the challenge.
The administrative metadata includes things like the page unique ID, the version, the content template, the page creator (which is not always the specialist/author), the user roles that have permission to use the template, the language, and so on.
The publishing metadata includes the page author (the specialist), the author picture, title, bio, the device & channels that the resource is intended for. These last two metadata fields can be skipped if you use the same assets and content across all channels.
Finally, the tracking metadata area is dedicated to all your tracking codes, so, for example, GA code, content group, CRO tool integration, marketing automation code, and so on.
What are the steps for developing a content model?
Before any modeling work can start, you need to have clarity on:
What your business is about
What your content should talk about
This will help you choose your content types. From here, the steps for developing the content model are as follows:
Describe the relationships between content types.
Decide how authors will assemble content. Will they use templates? Will they create instances of content types, that will be assembled and delivered to channels by the CMS?
If you decide to use templates, you’ll have to define all the templates that you will need, as per the chosen content types.
Decide how much you want to break down the content types. Will you use components or just attributes? Both these will need to be clearly defined.
Detail the metadata that each template or content type will use, both the internal one and the user-facing metadata.
While this may sound like a lot, it’s extremely helpful to have it all done before starting any CMS development or customization work.
If you need help in developing a content model for your website, get in touch with our team. We'll audit your content, research your ICP and define your content model and templates.
Common misunderstandings regarding content modeling
As closing thoughts, it’s worth mentioning a few common mistakes and misunderstandings regarding content modeling.
First and most important, there is no definitive rule or format for a content model. Your domain is very different than the niches I work with, so you may have very different content types, templates, and components.
Then, when you implement templates and types into your CMS, you only do this once. Your content authors or whoever adds content to the CMS will use the same templates but will create new instances of content.
So you will not end up with 10 different types of Author for example. You’ll have one Author content type, with perhaps 10 instances, if you have 10 authors creating content. These instances are commonly referred to as content items, and they are grouped into content packages.
If you have a multilingual website, for example, you might have an EN content package, an FR one, and so on. Or if you’re a corporation with multiple websites for different countries, you might have country content packages.