Summary
Every ASO ranking factor list in circulation is written from practitioner experience. That is legitimate, and it is not evidence. This one is built the other way round: we read the full text of Apple’s search patents and wrote down only what they actually name as an input to ranking.
The result is narrower than the industry list in some places and considerably wider in others. Apple names signals nobody talks about, including developer reputation, accolades earned by staying in a chart, and an explicit correction that discounts downloads an app received while it was already ranking well.
It also contains an actual equation.
How this list was built
We pulled the complete description and claims of every Apple search and ranking patent documented on this site, then extracted every passage that names something feeding a rank, a score or a weight. A factor appears below only if a patent states it. Where the wording is conditional, which in patents it almost always is, that is preserved rather than smoothed over.
Documents read in full: US9405832B2, US9280595B2, US20120191694A1, US10394838B2, US8364694B2, US10678832B2, US9104670B2, US11853306B2, US11360958B2 and US8095533B1.
What was not previously known
- There is a published formula. US10394838B2 gives the strength of association between a query and an app as
QueryScore(Q, App A) = log(volume of Q) × (number of downloads of App A for Query Q). Query volume enters logarithmically, downloads linearly. - Title and description are counted separately and then weighted. US9280595B2: “separate counts are performed for separate sections of the document (e.g., a title versus a description)” and “each count can be scaled by a weighting factor”. This is the closest thing to field weighting anywhere in Apple’s portfolio, and it does not name any specific field beyond title and description.
- Developer reputation is a signal. US11853306B2 describes fraud information carrying “a reputation status—e.g., good, bad, unknown” assigned to the developer, and whether the developer “is known as a trusted developer within the software application store, e.g., a partner company, a large-scale/well-known company”.
- Staying in a chart earns an accolade. The same patent says accolades can be assigned “by way of milestones that were satisfied, e.g., when the software application is the most downloaded and installed software application within the scope of a particular timeframe, when the software application remains within a particular chart for a particular timeframe”.
- Apple discounts the rich getting richer. Groupings “can be configured to disregard downloads that correspond to software applications that were highly ranked at the time the downloads were performed, as such downloads can inappropriately skew the download counts”.
- Downloads outrank taps, explicitly. US10394838B2: “downloads may be considered more relevant and more important information than user selections for more information about applications which do not result in downloads”.
- Classical IR maths is named. US8095533B1 uses Robertson’s term frequency score with document length normalisation, and US10678832B2 names inverse document frequency “to distinguish between common and rare phrases”.
The factors the patents actually name
Text and metadata
| Factor | What the patent says | Source |
|---|---|---|
| Count of query terms in title and metadata | “a ranking score is generated for each app in the app database, the ranking score being based on a comparison between app characteristics and search-query terms (e.g., a count of search-query terms in a title or a metadata)” | US9405832B2 |
| Separate counting by section, then weighted | “separate counts are performed for separate sections of the document (e.g., a title versus a description)”; “each count can be scaled by a weighting factor” | US9280595B2 |
| Co-occurring indicator vocabulary | Apps with high term counts “but include few or no related indicator terms can be eliminated from search results or assigned a low rank”; apps with low counts but many indicator terms “can be returned in search results and/or highly ranked” | US9280595B2 |
| Document length normalisation | “the score can normalize counts based on a number of terms in a document” | US9280595B2 |
| Inverse document frequency | “inverse document frequency (e.g., to distinguish between common and rare phrases)” | US10678832B2 |
| Topic model word association values | “The word association values are calculated based on the probability that a topic contains a word and the probability that a document contains a topic” | US20120191694A1 |
| Terms earned from query logs | “relevant query terms are added to the app’s language model (e.g., word and corresponding association value)” | US20120191694A1 |
| Term rank by historical occurrence | Terms are “assigned a ranking based on a historical occurrence of each term”, refreshed periodically “to reflect a current term usage trend” | US11360958B2 |
Behavioral
| Factor | What the patent says | Source |
|---|---|---|
| Download frequency or count | “App database 160 can include titles, metadata, download frequency or count, user ranking, and/or the apps themselves” | US9405832B2 |
| Popularity score | “a popularity score can depend on a number or frequency or previous downloads or user ratings” | US9405832B2 |
| Downloads attributed to a specific query | QueryScore(Q, App A) = log(volume of Q) × (number of downloads of App A for Query Q), described as “the strength of association between a particular query and the app” | US10394838B2 |
| Downloads weighted above taps | Downloads are “more relevant and more important information than user selections for more information about applications which do not result in downloads” | US10394838B2 |
| Click and download weighting of vocabulary | Documents are weighted “according to a frequency which a user clicked on or selected for download the associated search result” | US9280595B2 |
| Click through rate and buy rate per term | Stored in three variants each: top, cumulative and exact term | US9405832B2 |
| Concentration of downloads per query | Decides the query class, which decides the weighting applied to everything else | US9405832B2 |
| Whether the chosen app ranked well | The learning algorithm is trained using “a ranking of a selected or downloaded app amongst the presented search results” | US9405832B2 |
| Preview, download, rating and ranking popularity | Search hints “are ordered using media popularity indications, the media popularity indications being based on previews, downloads, ratings, and rankings” | US8364694B2 |
Quality, trust and reputation
All of these come from the app profile described in US11853306B2, the granted personalization patent. This is the richest single list of signals in the corpus.
| Factor | What the patent says |
|---|---|
| Retention rate | Named directly in the user response information |
| Ratings and reviews, by version | “user feedback—i.e., ratings/reviews—for previous and current versions of the software application, a relevance of the feedback” |
| Overall response rate from users | “whether there is a positive overall response rate from users” |
| Trending factor | “any information pertaining to the current (or past) popularity of the software application” |
| Stability factor | Named among the derived information |
| Compatibility | Named among the derived information |
| Existing ranking positions | Named among the derived information, so current standing is an input to future standing |
| Accolades | Awards assigned “by way of engagement by the users and/or by editors”, and by milestones including being most downloaded in a timeframe or remaining in a chart for a timeframe |
| Curation history | “a record of past actions by editors (e.g., editorial accolades, semantic/quality tags)” |
| Developer reputation | “a reputation status—e.g., good, bad, unknown”; whether the developer is “a trusted developer within the software application store, e.g., a partner company, a large-scale/well-known company” |
Query side
- Query class changes the weighting. US9405832B2 gives worked numbers: a navigational query can apply “a weight of 0.8” to the text based search and “0.2” to other techniques, and a functional query can flip that to “0.4” and “0.6”.
- The query can be rewritten before ranking. US11853306B2 describes a query modifier that modifies the search query, including “based on a spell-check that is performed”, and elsewhere by adding or removing words according to user history.
- Synonym and equivalent term expansion. US9405832B2 describes searching for “the term or equivalent terms (e.g., ‘strategic game’, ‘tactical puzzle’, or ‘planning game’)” in the title or metadata.
Personalization
- Results are ranked so that assets “more likely to be of interest to the user (e.g., based on the usage data) can be ranked higher”, and this ranking “can be performed at the user computing device or at the online media server” (US9104670B2).
The correction nobody mentions
US11853306B2 describes disregarding “downloads that correspond to software applications that were highly ranked at the time the downloads were performed, as such downloads can inappropriately skew the download counts and decrease the overall relevance of the groupings”.
In plain terms: installs you received because you were already ranking can be excluded from the data that decides whether you keep ranking. If something equivalent runs in search, it caps the compounding advantage of incumbency, and it means a burst of installs from a temporary high position is worth less than the same installs earned from a low one.
Factors the industry names that the patents never mention
These appear in the major ASO guides, usually stated with confidence and without a source. None of them appear in any Apple patent we read. To be explicit, because this is the point most easily misread: absence from the patents is not evidence that a factor is wrong. Apple patents only a fraction of what it builds, patents lag implementation by years, and several of these features did not exist when the relevant documents were filed. In-app events, custom product pages and the modern subtitle field all postdate most of this corpus. What the table below shows is where a claim has no documentary support, so it should be presented as practitioner inference rather than as fact. Several of these are probably true.
| Commonly claimed | Status in the patents |
|---|---|
| The subtitle is a heavily weighted field | The word subtitle does not appear in any Apple search patent we read. Only title and description are named as separately counted sections |
| The 100 character keyword field has its own weight | No patent describes a keyword field as a distinct entity or assigns it a weight |
| Screenshot text is read for keywords | Nothing on image or text recognition in any search patent here |
| In-app events are indexed for search | Not described anywhere |
| Custom product page keywords affect organic rank | Not described anywhere |
| A 3.5 or 4.0 star threshold governs visibility | Ratings are named repeatedly as an input. No threshold of any kind appears |
| Download velocity, meaning recency weighted installs | Download frequency and counts are named. A trending factor covering current popularity is named. Velocity as a distinct recency weighted metric is not |
| Update cadence is a ranking factor | A stability factor and version level feedback exist. Release frequency does not appear |
| App size affects ranking | Not described anywhere |
| Apple Ads spend lifts organic rank | Not described anywhere |
What this means for how you work
- Optimize the title first, then the surrounding vocabulary. Title is the one field named as separately counted and weighted, and indicator terms are the documented route to being ranked when your literal counts are low.
- Concentrate conversion on fewer queries. The QueryScore formula multiplies downloads for that specific query. Spreading acquisition thinly across many terms produces weak associations everywhere.
- Treat retention, crash behavior and review sentiment as ranking inputs, not just product metrics. They are in the same profile the ranker reads.
- Pursue editorial features and chart persistence deliberately. Accolades from editors and from staying in a chart are stored signals with a life beyond the traffic they deliver.
- Be careful with star thresholds. Ratings are named as an input in several patents. The specific 3.5 and 4.0 cut off points are not, so quote them as practitioner observation rather than as platform behavior.
- Do not expect an install spike to compound. There is explicit machinery for discounting downloads earned from an existing high position.
Sources and caveats
Primary sources, all read in full: US9405832B2, US9280595B2, US20120191694A1, US10394838B2, US8364694B2, US10678832B2, US9104670B2, US11853306B2, plus US11360958B2 and US8095533B1.
Caveats that matter more here than in any other article on this site:
- A patent describes what a company designed and claimed. It is not documentation and it is not proof of what runs today.
- Patent language is deliberately permissive. “Can”, “may” and “in some embodiments” are everywhere, and a named signal is an option the design allows rather than a switch known to be on.
- Several of these documents have lapsed or expired, and two describe surfaces other than App Store search. Each factor above carries its source so you can check its standing.
- Apple’s own 2026 paper describes the production ranker as a learned multi-objective model over feature vectors. In that architecture nothing has a fixed published weight, so treat this list as an inventory of inputs rather than a ranking of importance.
Bir yanıt yazın