<div anchor>Introduction</div>
Entitlements are complex. Every access decision has multiple moving parts: who the user is, what they've subscribed to, trial status, usage limits, promotions, corporate licenses. It quickly gets complicated, especially in B2C products where users might be anonymous, logged in, paying, or somewhere in between.
When building entitlement logic for MonetizationOS, our goal was to create something flexible without compromising on UX.
To make this work, we needed a way to represent user and product context in a flexible, composable format. Tags seemed like the obvious choice.
<div anchor>Working with Tags</div>
Working with Tags
We started with a tag-based approach. Tags are a familiar concept across different roles, which made them feel like a natural choice. They're composable and easy to work with. You could pass them in with each request, and they could represent anything from user state to product tiers.
Here's how it worked: We'd provide out-of-the-box system tags like user_authenticated, user_anonymous, or product_gold. Users could also create their own tags.
Features would be defined independently and could have multiple entitlements to control access. And each entitlement had two groups of tags:
Grant Access Tags
Tags in this group would allow access
Deny Access Tags
Tags in this group would block access
The solution seemed really elegant. If a customer wanted to add a new product tier like "Gold Plus," they could just create a product_gold_plus tag, attach it to the right features, and be done. No restructuring, no duplication. The tag gets passed in, matched to an entitlement, and access is granted or denied.
This meant teams could launch campaigns, test bundles, or run promotions without needing engineering help. On paper, this was powerful and flexible.
<div anchor>Complexities and Edge Cases</div>
Complexities and Edge Cases
However, in practice the system became too complex to understand. It was difficult to see what was included within any given plan. When multiple entitlements shared the same tag, it created complex, nuanced UX problems. Which tag takes priority? You couldn't look at the system and understand what a subscriber or free user actually had access to.
<div anchor>Reality Check</div>
Reality Check
The validation to this came when we started demoing early prototypes. It became clear the issue wasn't just with the UX. It didn't fit with people's mental model of access.
Business users weren't thinking in terms of tag logic. They were thinking about user types and subscription plans. What does a subscriber get? What's in the gold tier?
When people can't explain how something works, they don't trust it. And when they don't trust it, they don't use it.
We needed a model that actually matched how people think.
<div anchor>The Solution: Plans</div>
The Solution: Plans
It became clear we needed to rethink our approach. Instead of resolving access through tag matching, we introduced plans.
Plans clearly and explicitly define who gets access to what. They map directly to the mental model of how users think about access: “What do subscribers of gold get?”, “What do anonymous users see?” “How do we block access for bots?”
Let’s take a classic use case:
Anonymous users can access up to 5 articles per month, but they shouldn’t see any premium content.
Here’s how we configure that using our new Plans model:
- Create a plan called Anonymous.
- Assign it to anonymous users with a single toggle.
- Add the “Articles” feature to the plan.
- Set a meter of 5 articles every month.
- Exclude premium content by disabling the Premium Articles property.
It takes just a few steps, and the UI makes it easy to see what’s included, what’s restricted, and who the plan applies to.
Once set up, users get a clean, visual overview of what the plan includes and who it applies to. There’s no tracing through grant and block logic, no resolving tag conflicts. Whatever is configured is exactly what the user gets.
Plans gave us the structure we needed to scale. They turned entitlement logic from something abstract into something users could see, understand, and trust.
<div anchor>What Plans Provide</div>
What Plans Provide
- Clarity
You can see what a plan includes at a glance. - Predictability
No more mysterious conflicts or wondering which rule wins. - Speed
Business users can adjust packaging themselves. - Alignment
The model now matches how people naturally think about access.
<div anchor>The Takeaway</div>
The Takeaway
The tag model gave us flexibility but cost us clarity. It worked well for developers but confused business users.
Plans gave you structure. They made the system not just powerful, but understandable.
Want to learn more about Plans and how MOS enforces entitlements? Head over to our docs or sign up and start using it for free today.
------
Every interaction with your content - whether it's a human reader, a paying subscriber, or an AI crawler - is governed by an entitlement. Entitlements are the atomic units that determine what any given visitor can actually do: which content they can access, how much of it, under what conditions, and at what price. They're the bridge between commercial decisions and technical execution - translating pricing, packaging, and access rules into real-time behaviour without touching application code.
MonetizationOS is built on this principle. Rather than treating monetisation as a gate that sits on top of content, MOS runs an entitlement engine at the edge that evaluates every access request in real time - identifying the visitor, checking their permissions, and returning an access decision in milliseconds. A free user gets three metered articles. A subscriber gets unlimited access. An AI agent gets metered, usage-based access at a different price point entirely. The content stays the same. The entitlements are the dials. Plans set the dial positions for each audience. When you want to change pricing or launch a new offer, you're changing which entitlements attach to which products - not writing code. That separation is what makes monetisation programmable, testable, and fast enough to keep pace with how the market is actually moving.
