Methodology
How Bright App Data audits a mobile app from public evidence
The twelve ASO signals, the review-evidence rules and the valuation limits behind every Bright App Data app report — including what public data can never show.
Short answer
A public app audit scores what the store actually exposes: listing copy, creative coverage, rating volume, review language, developer replies and update cadence. It cannot see revenue, retention or conversion rate, because those live in the developer's console. A credible audit reports the first group and labels the second unavailable.
A public audit must separate facts from guesses
An app-store page is generous with some things and silent about others. It shows you the title, the descriptions, the screenshots, how many people rated the app, what recent reviewers wrote, whether the developer answered them, and when the binary last changed. It shows you nothing about money.
That split matters more than any scoring formula. Plenty of tools blur it, publishing confident revenue estimates derived from install ranges. We don't, because an install range like "100,000+" spans an order of magnitude, and multiplying a guess by another guess produces a number that looks precise and isn't.
So every Bright App Data report has two registers. Facts, quoted from the listing. And signals, which are interpretations we explain. Anything that would need App Store Connect or Play Console access is marked unavailable rather than modelled.
The twelve signal groups, and why each one is scored
Each signal has to be checkable the same way on both stores, and each has to connect to something an owner can actually change this week.
The catalog figures quoted against those signals are a snapshot of the audited catalog taken on 3 August 2026. The catalog grows continuously, so the live totals are higher than any count published here; the shares move far more slowly.
- Title structure and keyword use — Google Play and the App Store both cap the title at 30 characters, and across 6,634 audited listings the average title uses only 21.5 of them
- Short description coverage — 80 characters on Play, a 30-character subtitle on Apple
- Long description depth and keyword density, flagged when one term crosses roughly 3% of the text
- Screenshot count and whether a preview video exists — 84.1% of audited apps have no preview video
- Icon presence and quality signals
- Rating strength against the category band
- Review volume and review velocity — the audited average is 40.4 new reviews a month
- Developer reply rate — 47.4% of audited apps have never answered a single review
- Update cadence and days since the last release
- Privacy policy presence
- Localization: whether the listing was ever translated for the markets it ships to
- Recurring complaint clusters detected in public reviews
Why every complaint carries its evidence
A complaint count with nothing behind it is an assertion. The issue engine groups recurring themes — crashes, login failures, payments, performance, device compatibility — and keeps short verbatim excerpts alongside the count, so a reader can judge whether the classification was fair.
The bar for recording a cluster is deliberately low but not trivial: at least two independent reviews rated one to three stars have to describe the same kind of problem. Two is enough to stop a single furious reviewer from creating a finding, and low enough that a real emerging issue surfaces before it becomes a crisis.
This is also where we are most careful with language. A cluster means users are reporting something. It does not mean we found a bug. A user who reports a crash might be on an unsupported OS version, might have a corrupted install, or might be describing an outage that ended two months ago. Confirming a defect takes a technical audit of the app itself, which is a different and private piece of work.
How the indicative value range works — and what breaks it
The valuation combines an audience proxy with seven multipliers: rating quality, update recency, listing maturity, monetization signals, ASO foundation, detected issue pressure and sampled review risk. The output is a range with a stated confidence level, never a single number.
Update recency is the harshest input. An app updated within the last 60 days earns a small premium; one that hasn't shipped in over two years is discounted to roughly a third of what it would otherwise score. That is a deliberate stance: unmaintained code accumulates platform debt, and both stores keep raising their minimum target SDK.
The range is a screening tool for deciding which apps deserve a real conversation. It is not a price. Revenue quality, churn, ownership, liabilities and source-code condition all sit outside public data, and any one of them can move a real number by an order of magnitude in either direction.
What we refuse to publish
No invented revenue. No fabricated retention curves. No confident claim that an app "is" buggy when the honest statement is that users report problems. No report at all for an app where the public evidence is too thin to say anything specific — those stay unpublished rather than becoming filler pages.
App owners can dispute anything in a report. The corrections policy at /disclaimer explains how, and a disputed report gets re-audited against the current listing rather than defended.
Clear answers
Frequently asked questions
Does Bright App Data need access to my App Store Connect or Play Console?
No. Every public report is built from information any visitor to your store listing can see, plus public reviews. We never ask for console credentials for a public audit, and a report that claims console-only metrics would be fabricating them.
How many reviews does an audit read?
Up to 100 recent public reviews per app, which is what the stores expose reliably. That is a sample, not the full history, so complaint counts describe the sample rather than every review ever written.
Is the ASO score comparable between Google Play and the App Store?
The score is comparable, the underlying limits are not. Apple gives you a 30-character subtitle where Play gives you an 80-character short description, so the same copy scores differently. The audit applies each store's own limits before scoring.
How often is a report refreshed?
Every report shows the date it was last audited. Listings change, so a report older than about six weeks is flagged internally for a refresh, and the visible date always reflects when the evidence was actually collected.
Does a detected issue mean my app has a bug?
No. It means several independent users described the same kind of problem in public reviews. That is a real signal worth investigating, but confirming a defect requires reproducing it against the code, which a public audit cannot do.