TL;DR
- The team at MonetizationOS originally built entitlement logic using a tag-based system: flexible and composable on paper, but it turned out too abstract for business users to understand or trust in practice.
- Demoing early prototypes revealed the real problem. Business users weren't thinking in tag logic. They were thinking in plans: what does a subscriber get, what does a free user see, what does a gold tier include.
- The solution was to replace tags with Plans: explicit, visual configurations that map directly to how people naturally think about access. Anonymous users, subscribers, and bot traffic each get a plan that defines exactly what they can and cannot do, with no conflicting rules to trace through.
- Behind the model is an entitlement engine running at the CDN edge, evaluating every access request in milliseconds. A free user gets three metered articles. A subscriber gets unlimited access. An AI agent gets usage-based access at a different price. The content stays the same; the entitlements are the dials.
- When pricing changes or a new offer launches, you change which entitlements attach to which plans, not the application code. That separation is what makes monetization programmable, testable, and fast enough to keep pace with the market.
<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.
-------------
MonetizationOS is edge-native infrastructure that governs and monetises every access request in real time, from human audiences to AI agents. It comes with 1,000,000 free operations per month, no setup fees, and deploys in hours. Get started for free at monetizationos.com
