Strategy
Part of Digital product pricing: a two-sided framework
Five questions to vet a digital product benchmark
Five questions for evaluating digital product pricing benchmarks, plus checks for price versions, payment reconciliation and cohort maturity.
What to take away
- A published benchmark is context until it answers five questions about product, price version, market, cohort and counts.
- Analytics revenue is not automatically recognized revenue.
- Benchmark matched products and price versions, not isolated price points.
- A price change is judged on suitable-buyer volume and refunds, not on realized price alone.
- A percentage without counts and maturity can mislead.
Five questions for any published benchmark
Use these five questions to evaluate digital product pricing benchmarks you already have. If the source cannot answer them, use it as background and build your own comparison from matched products and price versions.
- Which product, price version and audience does it describe?
- Which market, currency and tax treatment does it use?
- Which cohort dates and refund window does it cover?
- Are raw counts and maturity shown beside the percentage?
- Can you recalculate it from the cited source or a dataset you govern?
A public average that omits these fields is not a decision rule. Recalculate the figure from the cited source or governed dataset, then record any mismatch. Keep market context separate from an internal target.
Start with the analytics number
Analytics revenue is a count of collected events, not a ledger. Google Analytics explains ecommerce metrics such as transactions, purchases, ecommerce purchases, items and refunds, and notes that different metrics include different event types. Those values reflect collected analytics events.
Reconcile them with payment, invoice, entitlement, refund and accounting records before they enter a digital product pricing benchmark. A gap between the two is not an error to hide. It is the first thing a reviewer will ask about, so write down its size and its cause.
Split the gap between analytics and payments
The gap between analytics revenue and settled payments is the sum of a few named causes, so split it instead of netting it away. Start from the settlement report and walk the difference line by line.
Possible cause / Record that settles it
- Refunds and chargebacks booked after the event
- Refund ledger
- Test or staff purchases counted as events
- Order or invoice record
- Duplicate or retried events
- Payment processor settlement report
- Tax and currency treated differently
- Order or invoice record
- Purchases the page never reported
- Entitlement or account system
Write the gap as analytics revenue minus settled payments, then assign each part to a row. Whatever no row explains stays open as an unexplained remainder with an owner. A benchmark built on a gap nobody can explain inherits its error.
Freeze the measures
Fill the dictionary before comparing anything. Each line fixes one measure and names the record that settles it.
Measures to freeze
- Net realized pricenet receipts / mature orders
- Plan mixbuyers by available plan
- Delivery successcorrect access / net orders
- Refund raterefunded orders / paid orders
- Support costattributed labor and vendor cost
- Contributionnet receipts less mature variable cost
- Transactions and purchases:freeze which events count and whether items or refunds are inside them. Companion record: the payment processor settlement report.
- Net price:freeze list price, discounts, promotions, currency and tax treatment. Companion record: the order or invoice record.
- Qualified buyers:freeze new versus existing, market, channel and cohort dates. Companion record: the entitlement or account system.
- Refunds and chargebacks:freeze the refund window and how reversals are booked. Companion record: the refund ledger.
Label every price version
A price is a version, and each version needs a label before its results mean anything. State the product, the price, the audience, the market, the currency and the dates it was live. Keep promotional and standard prices apart.
A label can be one line: product, plan, price, audience, market, currency, first and last day live, and whether it was a promotion. If a result cannot be traced to such a line, it is an anecdote, and it should not sit in a benchmark beside results that can.
The FTC's Guides Against Deceptive Pricing, codified at 16 CFR Part 233, say the advertiser should make certain that the former price is not a fictitious one. A benchmark that quotes an earlier price therefore needs a record that the earlier price was real.
Read a price change against buyers
A price increase can raise realized price while lowering suitable-buyer volume. A cheaper plan can improve acquisition while increasing support or attracting use the product cannot serve. Neither result is visible in revenue alone.
| Change | Can improve | Can worsen | Pair it with |
|---|---|---|---|
| Higher price | Realized price | Suitable-buyer volume | Counts of qualified buyers |
| Cheaper plan | Acquisition | Support load, unsuited use | Support and buyer-harm measures |
| Promotion | Short-term purchases | Comparability with standard price | Standard-price cohort beside it |
Choose the decision measure in advance, pair it with buyer-harm and operational guardrails, and retain the rejected explanations. The wider set of areas to compare sits in digital product strategy benchmarks.
Count the costs under the revenue
Revenue only becomes a margin once the costs sit beneath it. IRS Publication 334 has information on business income, expenses and tax credits for a small business owner filing a federal income tax return. It is not a management-accounting template or global tax advice.
Track payment fees, marketplaces, affiliates, hosting, metered services, license royalties, fraud, refunds, chargebacks, support and fulfillment. Report cash, accounting and managerial views by their own definitions rather than mixing them in one margin. For tax treatment by place, see sales tax by state.
Let refunds and cohorts mature
Wait for refunds and renewals to mature before declaring a price version better. Use raw counts beside rates, show ranges for small samples and separate new from existing customers.
Annotate every product, page, channel and funnel stage change, because each one alters who arrives and what they expect. Reading these records through digital product analytics keeps the definitions the same from one review to the next.
Common questions
What is a good refund rate?
No single figure is right for every product. Split refunds by product, price version, market, and cohort age, hold the refund window constant across the cohorts you compare, and use your own earlier cohorts as the reference instead of a published number built on different definitions.
Should average revenue set the price?
No. It is an outcome under a product and customer mix, not a standalone pricing method.
Which benchmark matters most?
Mature contribution from suitable buyers who receive and use the promised product, paired with trust and harm measures.
Why do analytics and payment totals differ?
Analytics values reflect collected events, while payment records reflect settled money. Reconcile the two and keep the difference on record.
