Tl;dr
- Metering is foundational for any usage-based pricing model, and getting it wrong means revenue leaks, frustrated users, and broken trust
- AI monetization needs usage tracking by design, whether it’s for token-driven features or metering AI agents themselves
- Your entitlements system is only as good as your usage tracking
- Stigg supports event-based and reported usage, aggregation, and unit conversion, right out of the box
- Metering must be highly available, secure, and observable, and we've baked that in from day one
Usage-based pricing is only as powerful as your metering is accurate.
Whether you’re gating access with hard limits or nudging upgrades with soft limits, without real-time insight into feature usage, you’re guessing, and in high-stakes scenarios like AI consumption or API limits, those guesses cost money and trust.
In this post, we’ll explore:
- Why metering is a core building block of any entitlements system
- Key architectural patterns to implement it right
- How Stigg handles metering out-of-the-box
- How to design for availability, security, and scale when usage data is critical to monetization
Why Metering is Essential for Entitlements
Entitlements define what a customer can access. Metering tells you what they’ve actually used. Without usage data, there’s no way to manage the following:
- Access control: Should this customer be allowed to upload another file?
- Upgrade triggers: Is it time to show a paywall or nudge to upgrade?
- Billing accuracy: How much should the customer be charged?
- Customer transparency: Can they see how close they are to their limits?
Without reliable metering, your entitlement checks become guesses, not gates.
In short: No metering = no monetization agility.
Why AI Monetization Depends on Metering
Whether you're integrating OpenAI, fine-tuning a proprietary model, or exposing internal APIs, AI is inherently usage-based, and needs to be priced accordingly.
For AI-Powered Features
AI services often have high variable costs. Pricing by usage (e.g. number of generations, tokens, or prompts) ensures:
- Cost control at scale
- Fair value exchange per action
- Better upgrade moments for power users
Want to charge for 500 generated summaries per month? Or include 1,000 prompts in your Pro plan? That’s metering + entitlements in action.
For AI as Your Next User
More and more, your platform’s next “user” will be an agent, not a human.
AI agents interact with your product programmatically and often at high volumes:
- They access resources
- Upload files
- Call APIs
If you can’t meter them properly, they’ll blow past limits, and create silent overages or broken UX.
Metering enables safe, fair, and scalable AI interaction with your product, while unlocking AI-native monetization models.
Common Metering Patterns for Usage Enforcement
1. Real-Time Checks for Hard Limits
Use when:
- Users hit limits that must stop access (e.g. seats, storage)
function canUploadFile(currentUsage, fileSize, limit) {
return currentUsage + fileSize <= limit;
}
Pair with caching (e.g. Redis) for speed.
2. Background Aggregation for Soft Limits
Use when:
- You want to notify or throttle users
- You’re okay with slight delay
// aggregate every hour
scheduleJob(() => {
aggregateUsage('api-calls', last30Days);
});
This also powers customer-facing dashboards:
“You’ve used 90% of your quota”.
3. Event-Driven Metering
Use when:
- Your app emits high volumes of usage events (e.g. MAUs)
- You want scalable, eventually consistent metering
eventBus.publish("usage.event", {
tenantId: "acme",
featureId: "api-call",
usage: 1,
});
How Stigg Handles Metering
At Stigg, we’ve designed our metering engine to support real-world SaaS and AI use cases, with multiple data sources, powerful aggregation, and clear presentation.
Two Metering Models
1. Reported Usage
Perfect for features like “seats” or “storage used”, where your system knows the usage total and reports it to Stigg.
stiggClient.reportUsage("tenant-id", {
featureId: "seats",
usage: 5,
});
2. Raw Events
Ideal for behavioral features like MAUs or token consumption, where your system emits events and Stigg handles aggregation.
stiggClient.trackEvent("tenant-id", {
eventName: "user-logged-in",
properties: { userId: "abc123" },
});
Built-in Aggregation Options (with Examples)
Stigg supports:
- Count (e.g. number of uploads)
- Count Unique (e.g. MAUs)
- Sum (e.g. GB uploaded)
- Average, Min, Max (e.g. session length)
You define filters, select the aggregation method, and Stigg handles the rest.
{
"eventName": "file-upload",
"properties": {
"sizeInBytes": 500000
}
}
Apply a Sum
aggregation on sizeInBytes
to calculate storage used.
Configuring Units & Presentation Granularity
Want to report usage in bytes but show customers GB? No problem.
Stigg allows you to:
- Report usage in high granularity (e.g. bytes)
- Display usage in human-readable format (e.g. 4.3 GB)
- Round up for billing (e.g. 0.02 GB → billed for 1 GB)
How it works:
Enable the “Feature is sold in different units” setting.

Define both:
- Reporting unit (e.g. bytes)
- Presented unit (e.g. GB) and conversion (e.g. 1 GB = 1,000,000,000 bytes)
Even though usage is reported in bytes, Stigg’s SDKs and dashboard return usage in GB, and if integrated with a billing solution, round up the presented units for billing.
Example:
If a customer uses 0.02 GB → they’ll be billed for 1 GB.
This improves transparency, UX, and billing consistency, without adding overhead to your own systems.
Designing Metering for Availability, Security & Scale
Metering is core infrastructure. If it fails, it can impact feature access, billing, and customer trust.
Here’s what we’ve learned about building a resilient metering system:
1. High Availability & Low Latency
Usage checks are often inline with core product flows, like API requests or onboarding. That means:
- Keep latency low (ideally sub-10ms)
- Cache entitlement and usage data locally
- Replicate critical systems across regions for redundancy
Stigg’s architecture ensures multi-region replication, redundant data pipelines, and automatic failover in case of regional outages.
2. Local Caching & Fallback Strategies
In case the network is flaky or your metering service is unreachable:
- Use local fallback caches (memory or persistent disk)
- Default to “fail open” or “fail closed” depending on the criticality of the feature
Stigg SDKs include built-in caching and fallback logic to maintain service availability even when connectivity is interrupted.
3. Usage Buffering & Retry Logic
Sometimes, events can’t be delivered immediately, due to network hiccups, rate limits, or service restarts.
A robust system should:
- Buffer usage events locally
- Retry failed transmissions
- Guarantee at-least-once delivery
Stigg automatically buffers and retries failed usage reports to prevent data loss.
4. Observability, Monitoring & Alerting
Metering bugs can lead to lost revenue, incorrect charges, or frustrated users.
Key best practices include:
- Emit metrics on event ingestion, processing latency, and aggregation success
- Alert on anomalies (e.g. usage spikes)
- Trace usage events from ingestion to entitlement enforcement
Stigg provides built-in observability hooks and usage dashboards to help you monitor usage data in real time.
Final Thoughts: Metering is a Monetization Primitive
Entitlements define what’s allowed. Metering tells you what’s happening. Together, they form the backbone of:
- Usage-based pricing
- Real-time enforcement
- Smarter monetization decisions
- And a foundation to support **AI-native products**
Metering isn’t a back-end concern anymore, it’s a monetization primitive.
Getting it right unlocks new growth levers. Getting it wrong? That’s lost revenue, churn, or regulatory risk.
To support flexible monetization, you need metering that is:
- Accurate
- Real-time or near real-time
- Fault-tolerant
- Understandable (for both devs and customers)
- Integrated with your entitlements and billing
Ready to Power Usage-Based Pricing?
Whether you're launching a new SaaS product or modernizing your monetization stack, Stigg gives you the tools to meter, enforce, and monetize, without rebuilding your infra from scratch.
👉 Try it out in our sandbox or check out our docs to learn more.