Measuring a product
The metrics that mean something for a BSV product, from a first payment as activation to recovery readiness and agent budgets, the vanity numbers to ignore, and how to measure without linking people's payments to who they are.
Measure money moving, permissions granted, and users who could survive losing their phone. Those three tell you more about a BSV product than installs or wallets created, which cost nothing to produce and say nothing about use.
Activation is a first payment
A new user has activated when they have made or received their first real payment. Before that they have an empty wallet or an unconnected app, and the guide's onboarding advice is built around getting them past that point in one sitting. See Usage life cycle.
Do
Define activation as a first payment made or received, and measure the time from first opening the product to it.
Don't
Count a created wallet as an activated user. Creating a wallet takes no input and no time, so the number grows whether or not anybody uses the product.
Connection grants and refusals
For an app, the connection prompt is the gate. Every permission you ask for is a place the user can say no. See Connecting a wallet.
Do
Measure grants and refusals per permission, not per prompt. A prompt that asks for three things and is refused does not tell you which of the three caused it.
Do
Treat a rising refusal rate after adding a permission as a finding about that permission, and test asking for it later, at the feature that needs it.
Allowance top-ups and repeat payments
An allowance that runs out and is topped up is the clearest signal a per-use product has: the user saw what they spent and chose to spend more. One that runs out and is left empty is the opposite.
Do
Track what happens when an allowance is used up: topped up, left empty, or revoked. Those are your renewal, your dormant users and your churn.
Do
Measure repeat payments per user over a period you choose in advance, such as a second payment within a week of the first. A single payment is curiosity; a second is a habit starting.
Recovery readiness
The barrier the guide ranks first is fear of losing money, and a user who could not recover is the one who eventually does. A complete backup has two parts. The recovery words restore the keys. The wallet backup restores the records: which money is the user's and how to spend it. Losing either can lose money. See Backups.
This metric belongs to whoever makes the wallet. An app connected to the user's wallet cannot see it, and should not ask.
Do
If you make a wallet, measure the share of users holding money who have both parts of a backup in place, and report it next to active users. Every user without both is one lost phone away from losing money.
Do
Count a backup as in place only once the user has finished it. We suggest treating a wallet backup as missing if it has not run since the user's last payment.
Agent budget use
For a product where software spends on the user's behalf, the questions are whether the bounds were right and whether the person stayed in control. See Letting an agent spend.
Do
Measure how much of each agent budget is used, how often the agent asks a person to approve something outside its scope, and how often the stop control is pressed.
A budget that is never close to used may be larger than it needs to be. Frequent requests for approval mean the scope is wrong. A stop pressed often means something went wrong first, and is worth a conversation.
Vanity numbers
| Number | Why it misleads |
|---|---|
| Wallets created | Free and instant to create, so it measures installs, not use |
| Transaction count | One reading session can be hundreds of payments |
| Total volume in sats | Dominated by a few large payments, says nothing about most users |
| Allowances granted | A grant nobody spends against is a refusal that took longer |
| Public on-chain activity | Counts every user of the network, not yours, and separating yours means tracing people |
Don't
Report payment counts as growth for a per-use product. Count people who paid, and how often they came back.
Measuring without linking identities
Payments on BSV are public and permanent. They do not carry a name, and each uses a new key, so an observer cannot easily tie them to a person. Spending them together can link them, and so can your analytics. See Wallet privacy.
Do
Measure inside your own product, against your own events, and keep identities out of the analytics. What a user paid for in your app is yours to count; what else they did on chain is not.
Don't
Attach a user's identity key or handle to payment records in your analytics. Joined with the public ledger, that table names their spending to anyone who gets a copy.
Don't
Run chain analysis on your own users to fill gaps in your analytics. If a number can only be found by tracing payments, decide you do not need it.
Open questions
- What time from first open to first payment is good? No published figures exist for BSV products, and this guide will not invent one.
- Can a wallet report recovery readiness without learning anything about the backup itself?
- Is a revoked allowance a lost user, or a careful one who will come back?
Related
- Usage life cycle: where people stop, stage by stage
- Conducting research: finding out why a number moved
- Growth that pays
- Wallet privacy
- Writing up findings: when a metric raises a question only a study can answer
Written from: /guide/designing-products/usage-life-cycle/, /guide/patterns/connecting-a-wallet/, /guide/patterns/charging-per-use/, /guide/patterns/letting-an-agent-spend/, /guide/how-it-works/backups/, /guide/how-it-works/wallet-privacy/, /guide/daily-spending-wallet/first-use/.
Checklist
The rules on this page, in a form you can work through.
13 rules