An app lists a $99 purchase. Somewhere, a spreadsheet is about to multiply that price by every download the app has ever received.
Please interrupt the spreadsheet.
A listed purchase tells you that an offer exists at the observed price in the observed storefront. It does not reveal conversion, purchase frequency, refunds, introductory eligibility, or the mix of plans people choose.
Read the menu, not the restaurant’s accounts
Imagine a hypothetical language app offering a monthly subscription, an annual subscription and a lifetime unlock. The most expensive item might be prominent in the store listing while almost nobody buys it. Or it might be the main business. The menu alone cannot settle the question.
A useful purchase inventory includes the product name, price, billing interval, country, currency, observation date and where the offer appeared. Keep introductory prices separate from standard renewal prices. If you cannot observe a term, leave it unknown.
Build a sensitivity table
For your own proposed app, model several purchase rates rather than borrowing an imaginary one from a competitor. At a hypothetical $20 purchase price, 100 purchases produce $2,000 in gross sales before costs. Whether reaching those 100 buyers requires 1,000 visitors or 100,000 is a much bigger business question than the multiplication.
Use interviews and a real offer to investigate willingness to pay. A free waitlist is useful evidence of interest; it is not equivalent to a completed purchase.
What the price can tell you
The structure of an offer can still reveal a hypothesis worth testing. Does the product charge for a recurring service, a permanent unlock, or a consumable task? Does the annual option make sense for the job’s natural frequency?
Study those choices as product decisions. Resist turning them into financial outcomes until you have evidence about actual transactions. A price tag is information. It is not a tiny income statement.