Sales & Conversion
Personas
SaaS & Startup
Time to ROI
Medium-term (3-6 months)
You're sitting in a pricing meeting, and someone says: "Let's charge based on usage." Sounds simple, right? Then comes the next question: "Usage of what exactly?"
This is where most companies hit their first wall. I've seen founders spend weeks debating whether to charge per API call, per user, per transaction, or per gigabyte of data processed. The choice isn't just technical—it shapes your entire business model.
After working with dozens of SaaS and e-commerce businesses, I've learned that the metric you choose determines everything: customer acquisition costs, retention rates, expansion revenue, and even product development priorities.
Here's what you'll discover in this playbook:
The 8 most common usage metrics that actually work in practice
Why 70% of companies choose the wrong metric (and how to avoid this)
Real examples from successful implementations across different industries
A decision framework to pick the right metric for your business
Common pitfalls that can kill your usage-based pricing before it starts
Whether you're launching a SaaS product or optimizing an existing business model, understanding these metrics will save you months of trial and error.
Industry Reality
What Every Business Thinks They Know About Usage Metrics
The conventional wisdom around usage metrics sounds logical: "Find what customers use most and charge for that." Most pricing consultants will tell you to run analytics, identify your core value driver, and build billing around it.
Here's what the industry typically recommends:
Track everything first - Monitor all possible usage patterns before deciding
Choose the highest-correlation metric - Pick what correlates most with customer success
Start simple - Begin with one metric and add complexity later
Align with value - Ensure the metric reflects customer-perceived value
Make it predictable - Choose metrics customers can forecast and control
This advice exists because most businesses approach usage billing like a science experiment. They want data-driven decisions, measurable outcomes, and predictable revenue models.
But here's where conventional wisdom falls short: It assumes all usage metrics are created equal and that correlation equals causation. In reality, the "perfect" metric on paper often creates terrible customer experiences or business dynamics.
I've seen companies optimize for the wrong metric for years, achieving technical success while missing massive revenue opportunities. The transition requires understanding not just what to measure, but what those measurements actually mean for your business model.
Consider me as your business complice.
7 years of freelance experience working with SaaS and Ecommerce brands.
Last year, I worked with a SaaS client who was struggling with their transition to usage-based pricing. They were a workflow automation platform—think Zapier for enterprise teams. Their original subscription model was working okay, but they knew they were leaving money on the table.
The client was generating solid revenue with their tiered subscription model, but they had a classic problem: their power users were getting incredible value at a fixed price, while their casual users felt like they were overpaying. They wanted to implement usage-based billing to align costs with value, but they had no idea what to measure.
Their first instinct? Let's charge per automation run. Makes sense, right? More automations = more value. But when we dug into their usage data, we discovered something interesting: their highest-value customers weren't necessarily running the most automations. They were running complex, multi-step workflows that saved them thousands of hours.
We tried three different approaches before finding what worked:
Attempt #1: Per automation execution. Simple to track, but customers with complex workflows that ran infrequently felt penalized. A workflow that ran once per week but saved 10 hours of manual work was charged the same as a simple notification automation.
Attempt #2: Per connected app. This felt more aligned with value since more integrations meant more powerful workflows. But customers started limiting their integrations to control costs, which actually reduced the platform's stickiness.
The breakthrough came when we realized we were thinking about this wrong. Instead of trying to meter individual actions, we needed to measure business impact. But how do you quantify "business impact" in a scalable way?
Here's my playbook
What I ended up doing and the results.
That's when I developed what I call the "Value Ladder" approach to usage metrics. Instead of picking one perfect metric, we created a tiered system that captured different levels of platform engagement.
The system we implemented had three measurement layers:
Layer 1: Basic Activity Metrics - These are the foundational measurements every usage billing system needs. For this client, we tracked workflow executions, but not as the primary billing driver. These metrics helped us understand usage patterns and detect anomalies.
Layer 2: Value Driver Metrics - This is where the real billing happened. Instead of raw executions, we measured "active workflows" per month. A workflow that ran 1000 times in a month counted the same as one that ran once—what mattered was that it was actively providing value.
Layer 3: Business Impact Metrics - For enterprise customers, we added a "complexity multiplier" based on workflow sophistication. Multi-app workflows with conditional logic carried higher weights than simple trigger-action pairs.
Here's how we implemented it:
Month 1-2: Data Collection Phase - We instrumented their platform to track both traditional metrics (executions, data processed) and our new composite metrics (active workflows, complexity scores). No billing changes yet—just gathering baseline data.
Month 3: Customer Research - We surveyed their top 50 customers about willingness to pay for different scenarios. The insights were eye-opening: customers cared more about reliability and workflow sophistication than raw volume.
Month 4-5: Pilot Implementation - We launched with 20 volunteer customers using a hybrid model: base subscription + usage fees for "active workflow slots." Each customer got 10 active workflows included, then paid per additional active workflow.
Month 6: Full Rollout - Based on pilot feedback, we refined the model and launched to their entire customer base. The key was framing it as "workflow capacity" rather than "usage billing."
Value Alignment
Not all metrics capture real customer value. We learned that volume-based metrics often penalize efficient usage patterns.
Customer Predictability
The best usage metrics let customers forecast their bills. Unpredictable costs create budget anxiety and drive churn.
Implementation Complexity
Simple-sounding metrics can be nightmares to implement. Track the technical and operational overhead before committing.
Communication Strategy
How you explain the metric matters as much as the metric itself. Frame it around customer outcomes, not internal measurements.
The results exceeded our expectations on multiple fronts:
Revenue Impact: Average revenue per customer increased by 40% within six months. More importantly, the revenue growth was sustainable—customers were expanding their usage rather than churning due to bill shock.
Customer Satisfaction: Despite paying more on average, customer satisfaction scores actually improved. The usage model felt fairer because it aligned with perceived value. Heavy users felt like they were paying appropriately for the value they received.
Product Development Clarity: The new metrics gave us clear signals about which features drove real value. We stopped building features that increased "usage" and focused on features that increased "active workflow" creation.
Sales Efficiency: The sales team found it easier to have pricing conversations. Instead of explaining complex feature tiers, they could talk about workflow capacity—something customers immediately understood.
The most surprising outcome? Customer retention improved during the transition. We expected some churn as customers adjusted to the new model, but retention actually increased because the pricing felt more transparent and fair.
What I've learned and the mistakes I've made.
Sharing so you don't make them.
This project taught me five crucial lessons about usage metrics that most businesses miss:
Correlation isn't causation in metrics selection - Just because something correlates with customer success doesn't mean customers will accept paying for it
Simple metrics often have complex implementations - "Per API call" sounds easy until you're dealing with retries, errors, and batch operations
Customer perception shapes metric success - The most mathematically perfect metric fails if customers don't understand or accept it
Hybrid models reduce transition risk - Combining base subscriptions with usage components lets customers adjust gradually
Metric choice shapes product roadmap - Whatever you measure becomes what you optimize for, so choose carefully
What I'd do differently: We spent too much time perfecting the metric before testing customer reactions. Next time, I'd prototype multiple billing scenarios with customers much earlier in the process.
When this approach works best: This value ladder approach works particularly well for B2B platforms where usage varies significantly between customers and where value comes from workflow complexity rather than pure volume.
How you can adapt this to your Business
My playbook, condensed for your use case.
For your SaaS / Startup
For SaaS businesses, focus on these implementation priorities:
Start with freemium limits to test metric acceptance
Instrument tracking before changing billing
Survey customers about willingness to pay scenarios
Consider composite metrics over simple volume measures
For your Ecommerce store
For e-commerce platforms, consider these specific applications:
Transaction fees based on order value, not quantity
Data storage metrics for product catalogs
Integration usage for multichannel selling
API calls for headless commerce implementations