Methodology & sources
Scores are weighted averages of named factors. Each factor shows its weight, its value and the evidence behind it, so you can disagree with a specific input rather than a black box. No score depends on hidden model output.
Five kinds of data
- Verified
- Read directly from an authoritative public source (e.g. Apple's Search API, a domain registry), with the retrieval time.
- 3rd-party estimate
- An estimate from a named, licensed provider. Shown with the provider's name; never presented as fact.
- User-provided
- Entered by the person running the evaluation. Used in the scores, but not verified.
- Model projection
- A judgement or forecast produced by Appvaluator's formulas or an AI model. Always labelled.
- Unavailable
- We couldn't obtain it. It's excluded from the score (which lowers confidence) rather than guessed.
Confidence
Each score's confidence is the share of its weight backed by evidence, weighted by evidence quality (verified 100%, user-provided 75%, third-party estimate 70%, model projection 45%, unavailable 0%).
Domain appraisals
Every appraisal shows four separate things: an estimated value in dollars (central estimate, likely range, quick-sale range and a suggested asking price), the evidence confidence behind it, a 0–10 name-quality score, and, only when the owner supplies figures, the value of any operating business. The name-quality score is never converted into a price.
The value is a weighted geometric blend of independent components. (1) A feature model: a reference price for the name's structure (exact category or audience term, dictionary word, phrase, brandable, acronym), adjusted for the size of the plausible buyer pool, purchase-intent vertical, length, hyphens and digits, and extension. (2) The domain's own reported sale history, weighted by recency. (3) Relevant comparable completed sales, weighted by similarity; unrelated sales are excluded, not averaged in. (4) Measured type-in traffic or keyword volume, when available. Missing components get no weight and widen the range.
Names are read with inflections and industry vocabulary: “cosplayers” is the plural agent noun of “cosplay”, not “cos” + “players”. Community, media, marketplace and directory uses count as commercial utility even when the words aren't purchase-oriented. Missing search data is shown as a gap, never scored as low demand.
Only completed sales count as evidence. Asking prices are shown for context and never move the estimate. A past sale is what someone paid then, not the current value.
Sources
| Source | Supplies | Terms |
|---|---|---|
| Apple iTunes Search & Lookup API | App metadata, ratings and counts, release/update dates, prices, search results per storefront, recent reviews (when Apple serves them) | Public Apple API (~20 req/min). |
| RDAP via IANA bootstrap | Domain registration status, registrar, dates | Public registry data. |
| Direct page fetch (robots.txt-respecting) | On-page SEO, pricing and monetization signals, technology hints | Public page submitted by the user. |
| Anthropic Claude | Qualitative analysis, names and copy, specs, code generation | Metered API. |
| App intelligence (AppMagic / Sensor Tower / data.ai) | Download estimates, revenue estimates, top charts history | Commercial licence required. |
| Keyword metrics (Apple Search Ads / DataForSEO) | Search popularity / volume per storefront | Commercial or advertiser account. |
| Website traffic (Similarweb) | Monthly visits estimates, traffic sources | Commercial licence required. |
| Domain comparable sales (NameBio) | Completed domain sales | Commercial API. |
| Google Play metadata | Android metadata, install-count bands | No official public API; not built in because scraping conflicts with Google's terms. Connect a licensed provider instead. |