Revenue went up 12% this month. Great. But why? And can you make it happen again?

Revenue is the most important number in your business. It's also one of the least useful ones for making decisions.

Not because it's wrong — your payment processor is probably very accurate. But because it's an aggregate. Every customer decision, every product change, every pricing experiment, every marketing campaign compresses down into a single line item. When it moves, you know something changed. You have no idea what.

A metrics tree changes that. It's a structured decomposition of revenue into its component drivers — a map of the specific behavioral and operational levers that produce your top-line number. Once you have the tree, "revenue was up 12%" becomes a starting point, not an ending point. You can immediately ask: which lever moved? By how much? What caused it?

And more importantly: which lever should we pull next?

What a Metrics Tree Actually Is

A metrics tree is a hierarchy of ratios. Each level decomposes the level above it into two or more factors that multiply to produce the parent metric. The root of the tree is revenue. The leaves are the specific, actionable behaviors and decisions that individual teams can actually influence.

The goal is to find metrics that are:

• Specific enough to be moved by a deliberate action

• Connected clearly to the revenue line above them

• Owned by a particular team or function

When you have this, you have something more valuable than a dashboard. You have a strategy document that tells you exactly which levers exist, who owns them, and what happens to revenue when any one of them shifts.

Let's build it, level by level.

Level 0: Revenue

Start at the root. Revenue is the product of everything below it. All other metrics in the tree must eventually trace back to this number. Anything that doesn't connect to revenue — directly or through a chain of influence — probably doesn't belong in the tree.

Level 1: Revenue per User × Number of Users

The first decomposition separates the monetary side of your business from the human side.

Revenue per User answers: how much does my typical customer relationship generate? This is where price, conversion, and monetization efficiency live.

Number of Users answers: how broadly have I established customer relationships? This is where acquisition, activation, and reach live.

These two metrics can move independently — and that independence is the point. If Revenue per User is growing while your user base is shrinking, you have a premium positioning story that's working at the top but failing in the middle of the funnel. If your user base is growing but Revenue per User is declining, you're scaling a less profitable customer profile. Both of these are strategic warnings that an aggregate revenue number masks.

Level 2: Revenue per Visit × Visits per User

Decompose Revenue per User further.

Visits per User = frequency. How often does the typical customer come back? This is your loyalty metric. Every strategy designed to create habits — push notifications, loyalty programs, email campaigns, subscription models — operates on this lever. Grocery loyalty cards are a classic example: they're not primarily designed to increase basket size, but to increase visit frequency. The economics of one additional weekly visit compound significantly at scale.

Revenue per Visit = basket size. How much does a customer spend in a typical session? Cross-selling, upselling, checkout optimization, product placement, and bundle strategies all live here. An impulse purchase near checkout, a "customers also bought" recommendation, a bundle discount — these are all basket-size strategies.

Notice how different these two levers are strategically. Improving Visits per User requires building habit and loyalty. Improving Revenue per Visit requires improving the purchase experience and product mix. The actions, the teams, and the investments required are different. Decomposing revenue reveals this — a flat Revenue per User number hides which of these two levers is the problem.

NOTE: For mobile apps and products with required onboarding steps before a transaction is possible, add a Layer 2.5: Dependent Actions — the completion rates for tutorials, payment method setup, profile completion, or whatever gates access to revenue. If these completion rates are low, the monetization levers above can't be activated at all, regardless of how good the product is. Fixing the dependent action problem is prerequisite to fixing the revenue problem.

Level 3: Items per Visit × Revenue per Item

Decompose Revenue per Visit further.

Items per Visit = purchase volume. How many units does the average transaction include? This is useful when you want to understand the volume story independent of price — particularly in commodity markets where price is constrained but unit economics are still manageable. Hotels use this logic: occupancy rate (volume) is tracked independently of RevPAR (revenue per room) because they have very different strategic implications.

Revenue per Item = average unit price. This is where pricing strategy, tiering decisions, and price elasticity analysis live. Price elasticity answers: if I raise the price of this SKU by 10%, does demand fall by more or less than 10%? If less, the price increase is profitable. If more, it isn't. This analysis only becomes possible once you're tracking Revenue per Item as a distinct metric.

Level 4: Product Mix

At the deepest level of the tree, you're tracking which products, SKUs, or tiers customers are purchasing — and at what margins.

Product mix matters because not all revenue is created equal. High-margin products and low-margin products can produce the same total revenue line while reflecting very different business health. A shift in mix toward higher-margin products is a meaningful business improvement even when revenue is flat.

Price discrimination — offering substitutable products at different price tiers — serves multiple customer segments simultaneously and improves average margin. This is the strategy behind SaaS tier structures, airline cabin classes, and software add-ons. Tracking product mix is how you know whether your pricing strategy is working at this level.

What the Tree Doesn't Capture

The revenue decomposition tree is complete for what happens after the customer commits to a purchase. But it doesn't cover three important adjacent areas.

Conversion Funnels cover what happens before the purchase. From the Total Addressable Market down to awareness, consideration, acquisition, and finally activation — every step loses some percentage of potential customers. Funnel metrics reveal whether a revenue problem is fundamentally an acquisition problem (not enough people at the top) or a conversion problem (enough prospects but too few convert).

User Flows cover what happens within each session — the specific product path from entry to purchase, and the branches where users drop off. Product page views, add-to-cart events, checkout initiation, payment entry — each of these is a micro-metric that lives between "visit" and "transaction" in the user journey.

Cost Modeling covers the economic reality of what it costs to generate the revenue. Revenue metrics without cost context miss your gross margin, CAC payback period, and LTV/CAC ratio — the metrics that determine whether your business model is actually healthy.

A complete metrics framework combines the revenue tree with these three supplementary views.

The Tree by Business Model

The structure of the tree varies by business model, but the logic is consistent.

B2C eCommerce (Blue Apron, DTC brands):
Revenue = Customers × Orders per Customer × Revenue per Order
Revenue per Order = Items per Order × Price per Item

B2C Subscription (Spotify, ClassPass):
Revenue = Subscribers × Monthly Price
Key subtrees: new subscriber acquisition rate, monthly churn rate, upgrade/downgrade rate

B2C Freemium + Ads (Duolingo, Medium):
Revenue = Ad Revenue + Premium Conversion Revenue
Ad Revenue = DAU × Sessions per User × Ads per Session × CPM
Premium Revenue = DAU × Conversion Rate × Monthly Price

B2B SaaS (Salesforce, HubSpot):
Revenue = Active Accounts × Average Contract Value
ACV subtree: new logo ARR, expansion ARR (upsell and cross-sell), contraction ARR, churn ARR

Each of these decompositions reveals the specific levers relevant to that model. A B2C subscription business optimizing for churn reduction is investing in a completely different set of tactics than a B2B SaaS business optimizing for expansion ARR — even though both are ultimately trying to grow revenue.

Building Your Tree in Four Steps

Step 1: Start with your primary revenue line. Write it at the top of a whiteboard or document.

Step 2: Ask at each level: "What must be true for this number to be higher?" The two factors that multiply to produce the parent metric become the children nodes. Repeat until you reach metrics that individual teams can directly influence through their work.

Step 3: For each leaf node, map it to a data source. Does the event that drives this metric exist in your database? If not, that's a gap in your instrumentation — add it to your roadmap.

Step 4: Document the tree in your Metrics Catalog. Assign each node to an owner (the team responsible for moving it), define the calculation, and set a reporting cadence.

The Tree as Strategy Document

Once you have a metrics tree, several things change.

"Revenue was up — why?" goes from a question that takes days to answer to one that takes minutes. You walk the tree from the root down, checking each level for the node that moved. The decomposition does the diagnostic work.

"Where should we invest?" becomes more structured. The node with the highest variance relative to its benchmark and the highest potential leverage on revenue is usually where the highest ROI opportunity lives.

"Which team owns this problem?" has a clear answer. Every node in the tree has an owner.

Revenue is still the most important number in your business. The metrics tree is what makes it useful.

The full revenue decomposition framework, Metrics Catalog template, and business model variations are covered in The Data Strategist course.