Making your content behave like a product catalog
Marketing platforms are built around products. A SKU has a price, an image, a set of attributes, and a recommendation engine that knows what to do with all of it. Everything else a business publishes tends to live somewhere the platform can't reach, which is a problem if the publishing is any good, because for a lot of companies the content is the reason anyone shows up at all.
The fix is to give that content the same shape a product record has. It takes three passes, and the first one is the pass most teams already do badly.
Pass one: tag for revenue
Content tagging usually produces metadata about the content. Topic, author, publish date, word count, maybe a vague category. None of that helps a marketing platform sell anything.
What you want are attributes that connect a piece of content to something you charge for. A cookware brand tags each recipe with the pan it requires. A gym tags every workout by the equipment it needs. A software company tags help articles by which plan tier unlocks the feature being explained. A tour operator tags destination guides by the trip someone would book after reading one.
Difficulty is usually worth capturing too, along with whatever axis separates your beginners from your veterans. That's how you stop sending the same thing to a customer on day four and a customer on year six.
Pass two: break the asset into pieces
The finished piece of content is rarely the unit that creates demand. Something smaller inside it is doing that work.
A recipe is an assembly of techniques, and the technique is what makes someone want a specific pan. A course is a stack of individual skills. A property listing is a bundle of features, one or two of which are the actual reason a person calls. Pull those sub-units out and treat each one as its own record, searchable and taggable on its own terms.
Then throw most of them away. Learning to dice an onion moves no cookware, so a cookware brand has no reason to track it. Keep only the pieces that touch something you sell, which in practice is a small fraction of what you find. A pan sauce needs a skillet in a way that's hard to argue with, and steam baking is what earns a Dutch oven its shelf space, which no quantity of bread recipes will manage on its own.
Pass three: get it into the platform
This is where it gets awkward. Most ESPs have a product catalog and no equivalent for content. No lookup tables, no custom data types, nothing to hold a record that isn't a thing you sell.
There are two ways through, and the choice is less technical than it looks.
Content in the product catalog | Structured data in the template | |
How it works | Each piece is written in as a product record | Dictionaries and loops hard coded into templates |
What you get | The recommendation engine treats a reader like a shopper; browse abandonment writes itself | Personalization works, and the recommendation engine stays focused on things that have prices |
What it costs | The engine can learn the wrong lesson, and a Shop Now button can land on something you meant to give away | Nothing syncs on its own; somebody maintains it by hand |
The first option is the clean version. You were reading about this, here's the thing you need for it. Connecting the warehouse, the CDP and the ESP is the work that makes it hold together, and the sync is the part most teams underestimate.
It also carries a risk worth taking seriously. We had a client's leadership veto exactly this, correctly, on the grounds that a checkout button in the middle of free educational content is the kind of small thing customers notice. That veto is a reasonable one, and it is the main reason the second option still exists.
The hard coded route trades automation for control. It survives contact with a legal team and a brand team, and it keeps the recommendation engine honest. It also means a person owns a spreadsheet, which is fine right up until that person leaves. Which route fits depends on your stack, and it is worth deciding deliberately rather than by default — the same question sits at the center of most ESP and CDP implementations.
What this gets you
Once the sub-units map to SKUs, you can show which content drove demand for which product. Most content teams have been asserting that connection for years without much to back it up.
You can also sort people by how far along they are rather than by what they said they liked. A new customer gets taught the fundamental thing. Someone who's been around since 2019 gets handed something harder. People stay subscribed to a teacher for longer than they stay subscribed to a store, which is a different way of thinking about the lifecycle stages you already map.
The side effect nobody plans for
Once the whole library is sorted by difficulty and by which product it supports, the holes are impossible to miss.
We built a dashboard off this data for one client's content team, and it became the brief for what to write next. It turned out an entire product line had no beginner material at all. Nobody had noticed, because nobody had ever looked at the library as a grid.
That is a better input than seasonality and whatever seemed interesting that month. It is also the part of this work that pays for itself fastest, because it redirects effort the team was going to spend anyway.
Where to start
Export whatever library you have and get it into a spreadsheet with a column for the product each piece supports. You'll learn two things quickly: how much of the content connects to nothing you sell, and which products have no content behind them at all.
The tagging and the sub-unit work are both easier once you can see how much of the library is actually in play, and that number is usually smaller than the content team expects.
Once you know the shape of it, the question becomes how the records get from wherever they live into the platform that has to use them. That is a pipeline question before it is a marketing one, and it is the part worth designing before you tag three hundred articles.
Frequently asked questions
What should you tag content with? Attributes that connect to something you charge for: the product a piece supports, the plan tier it unlocks, the trip someone would book after reading it. Topic and author are useful for your CMS and useless to your marketing platform. Difficulty is worth capturing too, because it is what lets you treat a new customer differently from a six-year one.
Can you put content in a product catalog? Technically yes, and it is the cleanest path to recommendations and browse abandonment. The risk is that your recommendation engine starts treating free content like merchandise, and that a Shop Now button appears on something you meant to give away. Decide that with your brand team before you build it.
How do you find content gaps? Sort the whole library by difficulty and by which product each piece supports, then look for empty cells. Gaps that were invisible as a list are obvious as a grid.
If you want help designing the data model or the sync behind it, our data engineering practice and lifecycle marketing services cover both halves of this.
