The 9 Licensing Metrics Every App Business Should Track

Your Stripe dashboard tells you money arrived. It does not tell you whether the customer ever got into the app.

That gap is where most licensing problems live. A payment succeeds, a key gets generated, an email goes out, and somewhere in that chain a percentage of your paying customers quietly never activate. They do not email you. They ask for a refund three weeks later, or they just disappear. From the revenue side everything looked fine.

Licensing metrics close that gap. They are not vanity numbers. Each one below maps to a decision you will actually have to make: whether to change your activation limit, whether to rewrite an email, whether your fail-open policy is doing its job.

Nine are enough. I have seen dashboards with thirty and they get read once.

Why revenue dashboards hide licensing problems

Revenue tooling measures the transaction. Licensing failures happen after the transaction, so they are structurally invisible to it.

Consider a real failure mode. Your license email starts landing in Gmail’s spam folder because you changed sending domains and forgot the DNS records. Purchases keep completing. Stripe looks perfect. Your MRR chart does not move. Meanwhile every customer from that week is sitting with an app they paid for and cannot unlock.

You will find out from support tickets, and only from the fraction of people annoyed enough to write in. Most will not. Industry support data consistently shows only a small minority of frustrated customers ever contact support, and everyone else just leaves.

The metric that would have caught this on day one is activation rate. It is the single most useful number in licensing and almost nobody tracks it.

The three activation metrics

Activation metrics answer one question: does a purchase reliably become a working install?

1. Activation rate. The percentage of issued licenses that get activated at least once. Measure it in a window, usually seven days from issuance, so a slow month does not drag the number.

Healthy desktop apps sit between 85% and 95%. Anything under 80% means the path from payment to working app is broken somewhere. The usual culprits, in order of how often I have seen them: the email went to spam, the activation screen is not obvious in the app, or the key format invites typos.

2. Time to first activation. The median gap between purchase and first successful activation. Track the median, not the average, because a handful of customers who activate six months later will wreck the mean.

For an app people buy while they are actively trying to use it, this should be minutes. If your median is hours, the delivery step is slow. If it is days, people are buying on one device and installing on another later, which is worth knowing before you design your activation flow around a single machine.

3. Devices per license. The average number of machines bound to each key.

This is the number that tells you whether your activation limit is right. Most indie apps set a cap of three or five, then never check what customers actually use. If your average is 1.4 and your cap is 5, the cap is doing nothing except reassuring you. If your average is 2.8 against a cap of 3, you have a support problem building, because the customers at the ceiling are the ones who will email you when they buy a new laptop. How the binding works underneath is covered in how device activations work.

Watch the tail, not just the mean. A key on eleven devices is not a heavy user. It is a key posted somewhere.

The three health metrics

Health metrics tell you whether the licensing system is quietly failing for people who already got in.

4. Validation failure rate, broken down by reason. The aggregate number is close to useless. The breakdown is where the value is.

A failure because the signature did not verify means something is wrong with your keys or your build. A failure because the lease expired means your refresh interval is too tight for how people actually use the app. A failure because the device is unknown means someone reinstalled or replaced hardware. Those three demand completely different responses, and a single “3% failure rate” number hides all of it.

If you are building this yourself, put a reason code on every failure before you do anything else. Retrofitting it later means throwing away your history.

// Every validation result carries a reason. Aggregate on the reason,
// never on the pass/fail boolean alone.
type ValidationReason =
  | 'ok'
  | 'signature_invalid'   // build or key problem, urgent
  | 'lease_expired'       // refresh interval too aggressive
  | 'device_unknown'      // reinstall or new hardware
  | 'device_limit'        // customer hit the activation cap
  | 'revoked'             // refund or chargeback
  | 'network_unreachable' // your problem, not theirs

const weekly = await db
  .select({ reason: validations.reason, n: count() })
  .from(validations)
  .where(gte(validations.at, sevenDaysAgo))
  .groupBy(validations.reason)

// signature_invalid trending up means ship a fix today.
// device_limit trending up means your cap is too low.
// network_unreachable means check that you fail open.

5. Device reset rate. How often customers deactivate a machine to free a seat, whether through your portal or by emailing you.

This is a direct proxy for support load. Every reset that does not happen in a self-serve customer portal is an email you have to answer by hand. When this climbs, either your cap is too tight or your customers are changing hardware more than you assumed.

6. Offline validation share. The percentage of validations that resolve from a cached lease instead of a live server call.

This one is easy to ignore until it matters. It tells you how much of your customer base would keep working if your licensing server went down for an hour. If the number is near zero, you have built a system where your uptime is your customers’ uptime, which is a bad position for a desktop app to be in. The mechanics of why a signed lease can be verified without a network are in how offline license validation works, and the failure case is in what happens when your licensing server goes down.

The three money metrics

Money metrics tell you whether the licensing model matches how people buy.

7. Trial-to-paid conversion. The percentage of started trials that become purchases, measured by cohort.

Cohort matters. A single blended number moves too slowly to learn from. Split by month started, and you can tell whether the trial change you shipped in August actually did anything. Trial length and reminder timing are their own subject, covered in from trial to paid.

8. Lapse recovery rate. For subscription licenses, the percentage of customers who lapse and then come back within 90 days.

Most people track churn and stop there. Churn treats a lapse as final, and for desktop software it often is not. Cards expire. People pause a project and pick it back up. If your recovery rate is meaningfully above zero, then what your app does during the lapsed window is a revenue decision, not just a policy one. Lock someone out completely and you have closed the door. Drop them to a reduced state that keeps their data reachable and the door stays open.

9. Refund rate, split by timing. Refunds inside 48 hours mean something different from refunds at day 25.

Fast refunds usually mean the app was not what they expected, or they could not get it working. That second cause is a licensing problem wearing a product disguise, and you can confirm it by checking whether those customers ever activated. Late refunds are usually genuine product fit. What should happen to the key afterwards is covered in what happens after a refund.

What to leave off the dashboard

Three numbers look like metrics and are not.

Total keys issued. It only goes up. It cannot tell you anything is wrong.

Raw install count. Reinstalls, VMs, and CI machines inflate it. It is a bragging number, not a decision number.

Estimated piracy. Almost nobody can measure this honestly. A cracked build has your license check removed, so it never contacts your server and never appears anywhere in your data. Any figure you put on a dashboard is a guess dressed up as a measurement. Watch the signals you can actually see, like the devices-per-license tail, and treat the rest as unknown.

Where these numbers should come from

You have two options and one of them is worse than it looks.

Building it yourself means adding timestamps and reason codes to your schema, keeping an append-only validation log, and writing the aggregation. That is a weekend of work and then permanent maintenance, and the log grows fast enough that you will be thinking about retention policy within a year. The reason this gets built badly so often is that it never feels urgent until you need history you did not keep. That pattern, where the simple thing you wrote at launch becomes a liability, is the whole subject of why licensing gets hard at scale.

The alternative is using a licensing layer that records this by default. Keylight tracks activations, validations with reason codes, device counts, and lease state per product, because the system has to record all of it anyway to do its job. The dashboard is a read on data that already exists. Stripe stays your payment processor and keeps owning the revenue side. See pricing for what that costs, or read why I built Keylight for the longer version of why this is a separate layer at all.

Either way, the point is the same. Start with activation rate. If you track exactly one number from this list, track that one, because it is the only metric here that catches a customer who paid you and never got in.