Understanding Pricing Data
Pricing is often treated as a strategic decision, debated in board rooms and workshop sessions, emerging from analysis of competitor positioning and customer willingness to pay. The decision is made. The price changes. Then nothing happens the way anyone expected. Conversion drops when it should increase. Churn spikes in unexpected segments. Revenue grows, but not where the model predicted. The post-mortem reveals that the pricing change interacted with the product in ways no one anticipated, triggered billing edge cases no one documented, and produced customer behaviours that contradicted every assumption.
The problem is not the strategy. The problem is treating pricing as a decision rather than as a system. Pricing is not a number you set and forget. It is a data flow that touches every part of the business: product usage, billing infrastructure, customer segmentation, revenue recognition, analytics pipelines, support operations. When these systems are not designed to support pricing flexibility, even theoretically correct pricing decisions fail in practice. Understanding pricing as a data problem is the prerequisite for pricing that actually works.
Why Pricing Is A Data Problem
The conventional view places pricing in the finance function. Finance teams calculate unit economics, determine target margins, analyse competitor pricing, and propose price points. This made sense when software was sold through perpetual licences with static pricing. It makes no sense in subscription businesses where pricing is dynamic, personalised, and continually tested.
Pricing in modern software-as-a-service is a cross-functional system. Product teams define the features and usage patterns that determine value. Engineering teams instrument the tracking that measures usage. Billing systems translate product entitlements into charges. Analytics teams measure how pricing changes affect behaviour. Finance teams ensure that revenue recognition follows accounting standards. Customer success teams handle the support burden when pricing creates confusion. Sales teams negotiate contracts within the constraints of the pricing model. Each function holds a piece of the puzzle, and none can operate independently.
When pricing is treated as a finance problem, decisions are made without considering whether the product can enforce the intended structure, whether the billing system can implement the necessary logic, or whether the analytics exist to measure the impact. The result is pricing that works on paper but breaks in production. A usage-based tier that requires measurement capabilities the product does not have. A volume discount structure that the billing system cannot calculate correctly. A promotional offer that creates accounting complexity no one anticipated. Each failure erodes confidence and makes the organisation hesitant to experiment further.
The alternative is to recognise pricing as a data flow with dependencies across the entire stack. Before you touch a price, you must answer: Can the product measure what we are pricing? Can the billing system enforce the rules? Can analytics track the outcomes? Can finance recognise the revenue correctly? Can support explain it to customers? If any answer is no, the pricing change is not ready. The work required is not strategic analysis but infrastructure: building the measurement, the enforcement, the tracking, the tooling. This work is unglamorous and time-consuming, which is why it is deferred, which is why pricing changes fail.
The Data You Need Before You Touch Price
Pricing operates on concepts that must be defined with precision before they can be implemented or analysed. Plans, entitlements, add-ons, discounts, usage: these terms are used casually in conversation but become slippery when you attempt to encode them in systems. The failure to define them rigorously is the root cause of most pricing implementation disasters.
A plan is a packaging of features and limits offered at a specific price point. But this simple definition hides complexity. Is a plan defined by its features, its price, or both? If you change the price but keep the features, is it the same plan or a new plan? If you change a feature but keep the price, what happens to existing customers on the old plan? These are not philosophical questions. Your database schema must answer them. Your billing system must enforce them. Your analytics must track them. Different answers lead to different implementations with different trade-offs.
An entitlement is a specific capability or resource that a plan grants. A customer on the professional plan is entitled to unlimited projects, advanced reporting, and priority support. Entitlements are the bridge between the abstract concept of a plan and the concrete implementation of feature access in your product. The product checks entitlements, not plans. This separation is essential for flexibility. You can change which plans include which entitlements without changing product code. But it requires discipline: every feature must correspond to a defined entitlement, and the mapping between plans and entitlements must be stored as data, not hardcoded.
Add-ons are additional capabilities purchased separately from the base plan. They complicate the data model because a customer’s total entitlements are now the union of their plan entitlements and their add-on entitlements. Moreover, add-ons may have their own pricing logic: one-time fees, recurring charges, usage-based costs. The billing system must support all of these whilst keeping them distinct in reporting.
Discounts are reductions applied to the standard price. They come in many forms: percentage discounts, fixed-amount discounts, volume discounts, promotional discounts, contractual discounts. Each type has different semantics. A promotional discount might expire. A contractual discount might apply only to certain line items. A volume discount might be tiered. The data model must represent all of these and make them queryable. You need to be able to answer: Which customers have promotional discounts that expire this quarter? What is the weighted average discount rate by customer segment? How much revenue are we forgoing due to contractual discounts? Without structured discount data, these questions are unanswerable.
Usage is the consumption of resources that may be metered for billing purposes. Some products charge based on usage: per user, per gigabyte, per transaction, per seat. But even products with flat pricing often track usage for other reasons: to understand engagement, to identify expansion opportunities, to enforce fair-use policies. Usage data must be granular, timestamped, and tied to specific customers and resources. It must be collected reliably even under failure conditions. It must be aggregated and rolled up for billing whilst remaining available in detail for analytics.
The distinction between price and value metric is critical. The price is what the customer pays. The value metric is what they receive. For a per-seat product, the value metric is the number of seats. The price is the cost per seat times the number of seats. The value metric might change (the customer adds seats) whilst the price per unit remains constant, or the price per unit might change (volume discounts) whilst the value metric remains constant. Confusing price and value metric leads to pricing models that feel arbitrary to customers and are difficult to implement.
How raw product usage translates into perceived value is the fundamental question of pricing strategy, but it is also a data question. You must instrument the product to track usage: which features are used, how frequently, by whom, for what purpose. You must correlate this usage with customer outcomes: do customers who use feature X heavily grow faster, retain longer, expand more? The correlation reveals which usage patterns signal value, which should guide the choice of value metric. If heavy users of feature X are the most valuable customers, consider pricing on feature X usage. If usage of feature X is uniformly high across all customers, it is table stakes and should not be a pricing lever.
Tiers, Feature Gates, Limits
The structure of your pricing tiers is not merely a marketing decision. It shapes customer behaviour, product usage, and internal operations. Tiering creates clustering effects. Customers on each tier exhibit different patterns, not just because the tiers include different features but because the price points attract different customer segments with different needs and expectations.
Usage clustering is the phenomenon where customers on the same tier converge toward similar usage levels. This happens through selection and adaptation. Selection: customers whose needs exceed the tier’s limits upgrade or churn, whilst customers whose needs fall well below the limits may downgrade. Adaptation: customers adjust their usage to fit within the limits they have paid for, finding workarounds or changing workflows rather than upgrading. The result is that usage distributions within tiers are often tighter than you would expect from a naive model.
This clustering provides valuable signal. If usage within a tier shows wide variance, it suggests that the tier is serving multiple distinct customer segments that should be separated. If usage consistently bumps against tier limits, it suggests that the limits are too restrictive and are forcing premature upgrades or causing churn. If usage is consistently far below tier limits, it suggests that the limits are too generous and you are leaving money on the table.
Power-user patterns are particularly revealing. A small percentage of customers on each tier will push usage to extremes, far beyond the median. These power users are often the most valuable customers: they extract the most value, they expand the most, they churn the least. But they are also the most likely to feel constrained by tier limits. Understanding their behaviour helps you design higher tiers that capture their value without alienating the broader base. It also reveals which features or usage dimensions are most critical to heavy users, informing both product investment and pricing structure.
Most software-as-a-service companies overestimate how many plans they need. The impulse is to offer fine-grained tiers that appeal to every possible customer segment. A free tier, a basic tier, a professional tier, a team tier, an enterprise tier, and perhaps a few intermediate tiers for specific use cases. The theory is that more options mean more customers find a fit. The reality is that more options create confusion, increase support burden, complicate billing, and fragment the customer base in ways that make analysis difficult.
The optimal number of tiers is typically three to four, plus potentially a free tier and a custom enterprise tier. Three tiers provide enough differentiation to capture customers at different willingness-to-pay levels without overwhelming them with choice. Each tier should be clearly differentiated by value, not just by arbitrary feature combinations. The tiers should ladder naturally: customers should understand why they might want to upgrade from basic to professional, and from professional to enterprise. If the value proposition of each tier is not obvious, you have too many tiers or they are poorly structured.
Detecting misalignment between pricing model and product model requires looking at several signals. First, feature adoption: are customers using the features their tier provides, or are they ignoring expensive features and wishing for cheaper features from lower tiers? Second, upgrade patterns: do customers upgrade because they hit limits and need more capacity, or because they want access to specific features? The former suggests usage-based pricing might be more natural than feature-based pricing. The latter suggests the opposite. Third, downgrade and churn reasons: are customers leaving because the price is too high for the value delivered, or because they need features that do not exist in their tier? Each pattern suggests different pricing corrections.
A common misalignment is pricing on features when customers care about capacity, or pricing on capacity when customers care about features. A project management tool that prices by number of projects might find that customers actually care more about collaboration features and would pay for better integrations regardless of project count. A data analytics tool that prices by feature access might find that customers primarily care about data volume and would prefer simple per-gigabyte pricing. These misalignments are only visible through behavioural data: what customers use, what they complain about, what they cite when upgrading or downgrading.
Expert help is only a call away. We are always happy to give advice, offer an impartial opinion and put you on the right track. Book a call with a member of our friendly team today.
Pricing As A System Of Signals
Every interaction a customer has with your pricing reveals information about their willingness to pay and their perception of value. Purchase behaviour, discount sensitivity, upgrade timing, downgrade triggers: these are not random events but signals that, when aggregated and analysed, reveal the health of your pricing model.
Purchase behaviour during the initial sale is the first signal. Customers who convert immediately after seeing the price are less price-sensitive than customers who evaluate for weeks. Customers who choose higher tiers without considering lower tiers have higher willingness to pay than customers who carefully compare options. Customers who negotiate discounts before purchasing are more price-sensitive or have organisational constraints around budget. Each behaviour segment has different optimal pricing and positioning.
Discount and promotion behaviour reveals hidden elasticity. When you offer a discount, you observe not only whether it drives more conversions but who converts. If a twenty percent discount drives conversions primarily from customers who would have purchased at full price, the discount destroys value. If it drives conversions from customers who would never have purchased at full price, it expands the market. If it drives conversions from customers who would have purchased later at full price, it accelerates revenue but does not change lifetime value. Segmenting discount responders by their predicted behaviour without the discount is essential for evaluating promotion effectiveness.
Moreover, repeated response to discounts signals conditioning. If customers learn that discounts are frequent, they wait for them. If customers believe that negotiating yields discounts, they all negotiate. These behaviours are rational responses to your pricing policy, and once established, they are difficult to reverse. The data to detect conditioning is the increasing percentage of sales occurring during promotions or the increasing frequency of discount requests in sales conversations. When these trends emerge, you have trained your market to expect discounts, and raising prices becomes nearly impossible without churn.
The early warnings of a wrong price are distributed across multiple systems. Churn spikes immediately after a price increase suggest that the increase exceeded willingness to pay for a meaningful customer segment. Downgrades after a price increase suggest that customers are willing to pay more but not at the new level, and are seeking cheaper alternatives within your offering. Support tickets about pricing complexity or confusion suggest that the pricing model is not intuitive. Low trial activation among users who see premium pricing suggests that the price is creating a psychological barrier before customers experience value.
Each of these signals is noisy individually. A churn spike could be seasonal. A downgrade could be due to changing needs. But when multiple signals align, the pattern is clear. The challenge is having the instrumentation to detect these signals in real time. Churn data comes from your subscription platform. Downgrade events come from billing systems. Support tickets come from customer relationship management tools. Trial activation comes from product analytics. Connecting these disparate data sources to create a unified view of pricing health is non-trivial but essential.
Timing is also signal. Customers who upgrade within their first month have found value quickly and are willing to pay for more. Customers who upgrade after six months have gradually expanded their usage and hit natural limits. Customers who have been on the same tier for two years have either found their steady state or are not growing in their use of your product. Each pattern has different implications for product development, customer success outreach, and pricing structure. Fast upgraders suggest that initial tier limits are too restrictive. Slow upgraders suggest that value accumulates over time and that annual contracts might capture more value than monthly. Non-upgraders suggest either satisfaction with their current tier or a lack of product-market fit for higher tiers.
The Minimum Data For Pricing Analytics
To make pricing testable, measurable, and predictable, you need a data model that captures the essential relationships and attributes. This model is not the same as your billing system’s database schema or your product’s data structures. It is an analytical model designed specifically to answer pricing questions.
At the centre is the customer entity. Each customer has attributes: acquisition date, acquisition channel, industry segment, company size, geography. These attributes are necessary for segmentation. Pricing analysis must always be segmented because aggregate numbers obscure the reality that different customer types respond differently to pricing.
Connected to each customer are their subscriptions. A subscription represents a commitment to a specific plan over a period of time. The subscription entity captures: which plan, start date, current status, billing interval, contracted amount, applied discounts. Critically, it must capture not just current state but state history. When a customer upgrades, you need to know when, from which plan, to which plan, and why (if the reason is captured). When a discount is applied, you need to know when, by whom, and under what circumstances.
Each plan is defined by its entitlements. The plan entity specifies the price, the billing interval, and references to the entitlements it includes. Entitlements are stored separately, allowing flexible mapping. A plan might include entitlements for unlimited projects, advanced reporting, and priority support. Another plan might include only the first two. The mapping is data, not code, enabling you to restructure plans without deploying new product code.
Usage data connects to customers and subscriptions. Each usage event records: which customer, which resource, how much, when. For a per-seat product, usage events might record seat additions and removals. For a per-gigabyte product, usage events record data ingestion. For a per-transaction product, usage events record each transaction. This granular data must be aggregated for billing whilst remaining available in detail for analysis. You need to answer: How does usage correlate with tier? Do customers consistently approach tier limits before upgrading, or do they upgrade well before hitting limits? Are there usage patterns that predict churn?
Billing events record every financial transaction: charges, payments, refunds, credits. Each billing event ties back to a subscription and, where applicable, to specific usage. This creates an audit trail from revenue back to the underlying customer behaviour that generated it. It also enables reconciliation between what your billing system thinks it charged and what your payment processor actually collected.
Event streams capture state changes and user actions throughout the customer lifecycle. Subscription created, plan upgraded, payment failed, feature accessed, limit reached, support ticket created. These events provide context that static tables cannot. They enable you to construct timelines: what happened in the week before this customer churned? What sequence of actions preceded this upgrade? Event streams are the richest source of behavioural signal, but they are only valuable if queried systematically.
The key tables you need are: customers, subscriptions, plans, entitlements, plan entitlements (the mapping), usage, billing events, and lifecycle events. Each table must have proper foreign keys maintaining referential integrity. Each must have timestamps recording when records were created and modified. Each must be designed for both transactional access (looking up a customer’s current subscription) and analytical queries (calculating net revenue retention by cohort).
The errors that break everything are predictable. Foreign key violations when subscriptions reference deleted plans. Missing timestamps that make it impossible to reconstruct historical state. Inconsistent status values where different systems use different enumerations for the same concept. Duplicate records caused by retry logic without idempotency checks. Orphaned usage data that cannot be tied back to a customer because the association was never stored. Each of these errors individually seems minor, but they compound. A small percentage of bad data makes all analysis suspect.
The discipline required is treating the pricing data model with the same rigour as production database schemas. Version control. Migration scripts. Validation checks. Documentation of every field and every relationship. Automated tests that verify referential integrity and detect anomalies. This investment is not glamorous, but it is the foundation. Without it, pricing analytics is guesswork.
Conclusion
Pricing decisions are only as good as the data infrastructure that supports them. You can hire the best pricing consultants, study every competitor, survey every customer, and still fail if the underlying systems cannot implement what you decide, measure what happens, or learn from the results. The businesses that excel at pricing are not those with the cleverest strategies but those with the most rigorous data foundations.
When pricing is testable, you can run experiments: change the price for a segment, measure the impact on conversion and retention, iterate based on results. When pricing is measurable, you can quantify exactly how pricing changes affect revenue, churn, and customer behaviour, eliminating the ambiguity that plagues post-mortems. When pricing is predictable, you can model the impact of proposed changes before implementing them, reducing the risk of catastrophic mistakes.
None of this is possible without the data model to support it. The model does not need to be perfect. It will evolve as your pricing evolves. But it must exist, and it must be treated as foundational infrastructure rather than as an afterthought. Every pricing initiative should begin with an audit of the data: What can we measure? What is missing? What needs to be built? Only after these questions are answered should the strategic discussion begin.
The return on this investment is compounding. Better data enables better decisions. Better decisions improve outcomes. Improved outcomes generate more data. The loop accelerates. Pricing becomes a lever you can pull with confidence rather than a gamble you take with trepidation. That confidence, built on data, is the difference between pricing as a one-time event and pricing as a system that continuously optimises value capture. The latter is strategic. The former is hope.
Get In Touch
Our friendly team are always on hand to answer questions, troubleshoot problems and point you in the right direction.
