Stop Measuring NRR as One Number — Break It Down by Product

Most CS leaders track Net Revenue Retention as a single company-wide metric. One number. Board slide. Done.

That number is lying to you.

A company running 108% NRR can have one product line expanding at 130% while another is quietly contracting at 85%. The aggregate number masks the problem. By the time the contracting product drags the overall number down far enough to trigger alarm bells, you've already lost 6 months of intervention time.

If you're running a multi-product SaaS (or even a single product with multiple pricing tiers, add-ons, or license types), NRR per product line is the metric that actually tells you where growth is coming from and where it's bleeding out.

The Math

Company-level NRR is straightforward:

NRR = (Starting ARR + Expansion - Contraction - Churn) / Starting ARR

Product-level NRR applies the same formula but scoped to individual license items. If a customer has three products — Platform ($40K), Analytics Add-on ($15K), and API Access ($5K) — you calculate retention independently for each:

• Platform NRR: What percentage of Platform ARR from 12 months ago is still here today (including expansions within Platform)?
• Analytics NRR: Same, scoped to Analytics.
• API NRR: Same, scoped to API.

Now you can answer questions that aggregate NRR never could:

• Which product do customers expand on most?
• Which product has the highest churn rate?
• Is our newest product actually retaining, or is it riding on the coat-tails of the core platform's stickiness?
• When a customer downgrades, which product do they cut first?

How to Build This in Planhat

Planhat's data model is built for this. The License object represents individual subscriptions and is the foundation of all revenue calculations. Each License has:

• Product field — maps to your Product Catalog (configured in Settings)
• Value — the ARR or MRR of that specific license
• Status — active, churned, or pending
• Start/End dates — for calculating cohort retention
• Auto-renewal flag — critical for forecasting
• Custom fields — anything else you need to segment on

Because Licenses are separate objects linked to Companies, you can run revenue reports filtered by Product. Planhat's revenue reporting already supports this natively. But to get truly useful product-level NRR, you need to set it up with intention.

Step 1: Clean Your Product Catalog

Go to Settings > Revenue > Product Catalog. Make sure every product, tier, and add-on has its own entry. Don't lump "Platform - Standard" and "Platform - Enterprise" into one product unless you want to obscure the difference in retention between tiers.

Step 2: Ensure Every License Has a Product Assigned

Pull a License report filtered where Product = empty. Fix those. If Licenses are syncing from Salesforce Opportunities, make sure the Opportunity Product field maps to Planhat's Product field in your integration settings.

Step 3: Build Calculated Metrics at the Product Level

This is where it gets powerful. Planhat's Calculated Metrics support time-series data on Companies, but you can also use the Asset model to represent individual product lines per customer. Create an Asset for each active product per company, feed revenue data into it, and build Calculated Metrics that track MRR trajectory at the product level over time.

Now you have time-series revenue data per product per customer. You can visualize which products are growing, flat, or declining across your entire book.

Step 4: Create Product-Level Health Dimensions

In your Health Score configuration, add a dimension that weights differently based on product. A customer whose core Platform license is healthy but whose Analytics add-on is unused is a different risk profile than a customer whose Platform usage is declining.

Use Formula Fields to cross-reference License value with product usage metrics. Example: if Analytics licenses > $10K but Analytics DAU < 5, flag it.

What This Reveals

When I've built this for clients, three patterns show up almost every time:

Pattern 1: The Subsidizer. One product has stellar NRR (120%+) and is masking the poor retention of other products. Leadership thinks everything is fine because aggregate NRR is above 100%. Meanwhile, the secondary product line is churning at 20% annually and nobody is investigating why.

Pattern 2: The Expansion Bottleneck. Expansion revenue concentrates in one product. Customers expand on Platform seats but almost never upgrade their Analytics tier. This tells you the Analytics product either doesn't deliver enough incremental value, or the CSMs aren't positioned to have that expansion conversation.

Pattern 3: The Churn Canary. Customers who downgrade or cancel a secondary product are 3-4x more likely to churn entirely within 12 months. The secondary product cancellation is the leading indicator. If you're only tracking aggregate NRR, you miss this signal until the entire account churns.

Turning It Into Action

Once you see product-level NRR, the playbook writes itself:

• Product with low NRR: Is it a value delivery problem (customers aren't getting ROI) or an adoption problem (customers aren't using it)? Pull the usage metrics for that product specifically. If usage is low, build an adoption playbook. If usage is fine but retention is poor, the product itself might have a gap.

• Product with high expansion NRR: Double down. Train your CSMs on expansion plays specifically for that product. Build triggers in Planhat: when a customer hits 80% utilization on that product, auto-create a task for the CSM to explore an upgrade.

• Cross-product churn correlation: Build a Planhat automation that fires when a customer cancels any non-primary license. That should trigger a risk assessment, not just for the lost product, but for the entire account.

The Bigger Point

NRR is a lagging indicator. By the time it shows up on the board slide, the retention events already happened. Product-level NRR is still lagging, but it's less lagged — it gives you a more granular, faster signal about where the business is healthy and where it isn't.

The companies that figure this out don't just manage retention. They engineer it, product by product, license by license.