Usage-based pricing flips the traditional SaaS model. Instead of paying a flat subscription, customers pay for what they consume — API calls, compute minutes, messages sent, storage used. This model aligns vendor incentives with customer value, but it also creates a fundamentally different analytics challenge.
When revenue is directly tied to product usage, consumption data becomes the most important dataset in the company. This post covers the key metrics, analytical patterns, and operational intelligence that drive usage-based businesses.
The Usage-Based Model
Traditional SaaS revenue is predictable: N customers × $X/month = monthly revenue. Churn means a customer cancels their subscription.
Usage-based revenue is variable: each customer’s bill depends on their consumption. “Churn” isn’t binary — a customer can gradually reduce usage (revenue churn) without ever explicitly canceling.
This creates three distinct challenges:
- Revenue forecasting is harder because consumption varies month to month
- Churn detection requires monitoring usage trends, not just subscription status
- Account health is a spectrum, not a binary active/churned state
Consumption Metrics That Matter
Daily Active Usage (DAU-style for APIs)
Just as consumer apps track daily active users, usage-based platforms need to track daily consumption patterns:
SELECT
account_id,
DATE(timestamp) as day,
COUNT(*) as api_calls,
COUNT(CASE WHEN status_code >= 400 THEN 1 END) as errors,
PERCENTILE_CONT(0.99) WITHIN GROUP (ORDER BY latency_ms) as p99_latency
FROM api_logs
WHERE timestamp >= CURRENT_DATE - INTERVAL '30 days'
GROUP BY account_id, DATE(timestamp)
ORDER BY account_id, day
Quota Utilization
Every tier has limits. Monitoring how close customers are to their limits reveals both upsell opportunities and potential friction:
SELECT
a.account_id,
a.company_name,
a.tier,
t.monthly_quota,
SUM(u.api_calls) as current_month_usage,
ROUND(SUM(u.api_calls)::float / t.monthly_quota * 100, 1) as utilization_pct
FROM accounts a
JOIN tier_definitions t ON a.tier = t.tier_name
JOIN daily_usage u ON a.account_id = u.account_id
AND u.date >= DATE_TRUNC('month', CURRENT_DATE)
GROUP BY a.account_id, a.company_name, a.tier, t.monthly_quota
HAVING SUM(u.api_calls)::float / t.monthly_quota > 0.8
ORDER BY utilization_pct DESC
Accounts at >80% utilization need attention:
- Happy path: They’re growing and ready for an upsell conversation
- Unhappy path: They’re about to hit rate limits and get frustrated
Week-over-Week Trend
A single day’s usage means nothing. Trends over 7-14 days reveal the trajectory:
WITH weekly_usage AS (
SELECT
account_id,
DATE_TRUNC('week', date) as week,
AVG(api_calls) as avg_daily_calls
FROM daily_usage
GROUP BY account_id, DATE_TRUNC('week', date)
)
SELECT
curr.account_id,
curr.avg_daily_calls as current_week,
prev.avg_daily_calls as previous_week,
ROUND((curr.avg_daily_calls - prev.avg_daily_calls)
/ NULLIF(prev.avg_daily_calls, 0) * 100, 1) as trend_pct
FROM weekly_usage curr
JOIN weekly_usage prev
ON curr.account_id = prev.account_id
AND curr.week = prev.week + INTERVAL '7 days'
WHERE curr.week = DATE_TRUNC('week', CURRENT_DATE)
ORDER BY trend_pct ASC -- Most declining first
Churn Signals in Usage Data
In subscription SaaS, churn is a discrete event. In usage-based SaaS, churn is a gradient. These are the early warning signals.
Signal 1: Declining Usage Trend
A sustained decline over 14+ days is the strongest churn predictor. A single bad week can be noise; two consecutive declining weeks is a pattern.
Threshold: >20% week-over-week decline for 2+ consecutive weeks.
Signal 2: Increasing Error Rates
When a customer’s error rate increases, it often means they’re struggling with the integration. High error rates correlate with abandonment, especially during onboarding.
Threshold: Error rate >5% sustained over 7+ days, or sudden spike from baseline.
Signal 3: Feature Narrowing
A customer who used 8 different endpoints last month but only 3 this month is simplifying their integration — possibly migrating to a competitor or building an in-house alternative.
Threshold: >50% reduction in distinct endpoints used, month-over-month.
Signal 4: Support Ticket Patterns
Multiple support tickets, especially about core functionality or billing, correlate with churn risk. The combination of declining usage + support tickets is a strong compound signal.
Compound Scoring
Individual signals are noisy. Combining them into a health score improves prediction:
def account_health_score(account_id):
scores = {
"usage_trend": score_usage_trend(account_id), # 0-100
"error_rate": score_error_rate(account_id), # 0-100
"quota_utilization": score_utilization(account_id), # 0-100
"support_sentiment": score_support(account_id), # 0-100
}
weights = {
"usage_trend": 0.4, # Strongest signal
"error_rate": 0.2,
"quota_utilization": 0.2,
"support_sentiment": 0.2,
}
return sum(scores[k] * weights[k] for k in scores)
Developer Onboarding Funnels
For developer-facing APIs, onboarding quality directly drives revenue. Every developer who signs up but never makes their first successful API call is lost revenue.
The Funnel
Account Created 100%
↓
API Key Generated 82% ← 18% drop: signup friction
↓
First API Call 64% ← 18% drop: docs/auth confusion
↓
Successful Response 51% ← 13% drop: integration errors
↓
Second Endpoint Used 38% ← 13% drop: limited exploration
↓
Production Integration 22% ← 16% drop: evaluation → adoption gap
Each transition point is an opportunity for intervention. The biggest ROI is at the top — reducing the drop from “API Key” to “First API Call” by even 5 percentage points compounds into significant revenue.
Friction Detection
Automated friction detection combines event data with timing expectations:
- No first call within 24h of API key creation: Developer got stuck on auth or setup
- Repeated 4xx errors on same endpoint: Wrong parameters, missing headers, auth issues
- Doc page bouncing: Visiting many doc pages in rapid succession signals confusion
- Stalled progress: No new onboarding step completed in 48+ hours
Intervention Strategies
The response should be proportional to the signal:
| Signal | Severity | Intervention |
|---|---|---|
| No first call (24h) | Medium | Automated email with quickstart + code snippet |
| Repeated 401 errors | High | In-app message with auth fix + specific code |
| Stalled >48h | Medium | Email from DevRel with personalized help offer |
| Repeated 400 errors | High | Contextual docs link for the specific endpoint |
| Inactive >7 days | Low | Re-engagement email with new feature highlights |
The key is making interventions contextual. A generic “need help?” email converts at ~2%. A message that says “I noticed you’re getting 401 errors on /v1/text-to-speech — here’s the correct way to pass your API key” converts at ~15-20%.
PLG Metrics for Usage-Based Businesses
Product-Led Growth (PLG) metrics look different in usage-based models.
Net Revenue Retention (NRR)
The single most important metric for a usage-based business. NRR measures revenue from existing customers, including expansion (more usage) and contraction (less usage):
NRR = (Starting MRR + Expansion - Contraction - Churn) / Starting MRR × 100
- <100%: Revenue from existing customers is shrinking (bad)
- 100-110%: Stable, some growth offsetting churn
- >120%: Strong expansion — existing customers growing faster than churn (best-in-class)
The best usage-based companies have NRR >130%, meaning their existing customer base generates 30% more revenue year-over-year even without adding new customers.
Expansion Revenue
Usage-based models have a natural expansion mechanism: as customers succeed with the product, they use more of it. Track:
- Organic expansion rate: % of accounts increasing usage month-over-month
- Tier upgrade rate: % of accounts hitting limits and upgrading
- Feature adoption breadth: Number of distinct API endpoints used per account
Time-to-Value (TTV)
How quickly does a new customer reach meaningful usage? In API businesses:
- Time-to-first-call: Minutes/hours from signup to first API request
- Time-to-production: Days from signup to production-level traffic (>1000 calls/day)
- Time-to-ROI: When the customer’s usage indicates they’ve integrated deeply enough that switching costs make churn unlikely
Operational Intelligence with AI Agents
This is where AI agents add value over traditional dashboards. A dashboard shows you the numbers. An agent tells you what the numbers mean and what to do about it.
What a Revenue Ops Agent Does
- Queries usage data across accounts to identify trends
- Cross-references billing to spot accounts approaching limits
- Searches support tickets to understand the “why” behind usage changes
- Generates recommendations combining quantitative signals with qualitative context
A dashboard can show you that ACC-003’s usage dropped 33%. An agent can tell you: “ACC-003’s usage dropped 33% this week. They had 3 support tickets about latency issues in the last month, their contract renews in 45 days, and based on similar accounts, there’s a 72% probability of churn without intervention. Recommended action: schedule CSM check-in and escalate the open support ticket.”
The Data Stack
Data Sources Processing Intelligence
───────────── ────────────── ─────────────
API Logs → Snowflake/BigQuery → AI Agent
Billing (Stripe) dbt transformations LangGraph + Tools
CRM (Salesforce) Usage aggregations RAG over tickets
Support (Zendesk) Churn scoring Alerts & Actions
Product Events Cohort analysis CSM workflows
Practical Takeaways
- In usage-based SaaS, consumption data is the revenue dataset — treat it with the same rigor as financial data
- Monitor week-over-week usage trends, not daily snapshots — individual days are noisy
- Compound churn signals (declining usage + support tickets + approaching renewal) are far more predictive than individual signals
- Developer onboarding quality has the highest ROI — a 5% improvement in activation compounds into significant ARR
- Net Revenue Retention is the north star metric — if NRR >120%, the business grows even without new customers
- AI agents add value by connecting structured data (usage, billing) with unstructured data (support tickets, meeting notes) in a single reasoning loop
Comments
No comments yet. Be the first to comment!