ASO Patents

Publication number	US20240086412A1
Official title	Techniques for personalizing app store recommendations
Assignee	Apple Inc.
Inventors	Jayasimha R. Katukuri, Peter Leong, Chandrasekar Venkataraman, Rabi S. Chakraborty, Hardik Vala
Priority date	June 3, 2018, via provisional application 62/679,949
Filed	November 17, 2023, as a continuation of application 16/147,058
Published	March 14, 2024
Status	Pending
Source	patents.google.com/patent/US20240086412A1

What This Patent Covers and Why It Matters for ASO

Feature it describes: personalized app recommendations, and, in a section most readers miss, personalized search results including outright rewriting of the user’s query.

The title undersells this document. It is not only about the Today tab and recommendation shelves. Figures 5A through 5C cover personalized search results refinement, and the description introduces a query modifier that can add, modify or remove words from a user’s search query based on their history before results are ranked. The worked example is a user interested in gaming whose query gets “game”, “gaming” or “games” appended to narrow the results, and Figure 5B contrasts the default results for the query “Baseball” against the personalized ranking.

If that runs in production, the keyword a user typed is not necessarily the keyword your app was matched against. That is the single most consequential idea on this site for anyone who reports keyword rankings as facts.

The other half of the document, the app side profile, is almost as useful, because it enumerates what Apple considers worth knowing about an app. Two entries in that list deserve immediate attention: an installation retention factor and a stability factor, sitting alongside a trending factor, ranking positions, compatibility and accolades.

What follows for practice:

• Retention is a discovery input, not only a business metric. An installation retention factor in the app profile means uninstalls plausibly cost you visibility, not just revenue.
• Editorial features are structured data. Accolades appear as a named signal in the app profile, so being featured has an afterlife inside the recommendation system beyond the traffic it delivers on the day.
• Your app is characterized by topics derived from its text. The worked example gives a math tutoring app the topics math, number, answer, problem, addition, subtraction, multiplication and division. Write metadata that makes the topic set you want unmistakable.
• Users are clustered and labeled, with “sparse gamer” and “reader” given as examples, each with weighted correlation strengths. You are matched against cluster profiles, so the question is not who your user is in the abstract but which cluster your app correlates with.
• Demographic attributes including age and gender appear in the user profile signals. Keep that in mind when interpreting performance differences you have attributed to creative.

The 2018 priority date matters. This is not a recent experiment. Apple has been filing on personalized app recommendations since before most of the current ASO tooling existed, and this continuation, filed in late 2023, shows the family is still being actively prosecuted.

Patent Summary

“Disclosed herein is a technique for providing software application recommendations to a user of a computing device. The technique can include: (1) receiving, from the computing device, a request for at least one software application recommendation, (2) identifying, among a plurality of user profiles, a user profile associated with the user, (3) accessing a plurality of software application profiles (SAPs) … (4) analyzing the user profile against a subset of the plurality of SAPs to identify … at least one software application to recommend … and (6) causing the computing device to display the at least one software application recommendation.”

US20240086412A1, abstract, abridged

Two profile types sit at the center of the design. A user profile aggregates behavioral and demographic signals about a person and is used to place them into clusters of similar users. A software application profile, abbreviated SAP in the document, aggregates signals about an app drawn from user behavior, derived quality metrics, usage patterns and content metadata.

A recommendation is produced by matching a user profile against a subset of app profiles using weighted correlations and machine learning, then ranking the matches by relevance. The same profile machinery is then applied to search, where a query modifier can rewrite the query before ranking and the results are reordered for the individual.

Detailed Explanation

What goes into a user profile

Figures 3A through 3E cover user profile generation and clustering. The signals named are behavioral and demographic: downloads, in app purchases, ratings and reviews the user has left, search queries they have run, click and impression behavior, and demographic attributes including age and gender.

From those, the system derives affinities, and the vocabulary is specific: purchase affinity, tag affinity, genre affinity and topics affinity, plus demographic correlations. Each affinity is a weighted statement about what this person reliably engages with.

Impression behavior is the signal worth pausing on. The system is not only learning from what users chose. It is learning from what they were shown and did not choose. An app that gets impressions and no taps is teaching the system something, and it is not flattering.

Clustering and labeling

Users are grouped by machine learning on shared characteristics. The example given is clustering users who show the highest number of downloads in a gaming genre. Each cluster profile aggregates the characteristics of its members and keeps references back to the individual profiles, so the system can reason at both levels.

Users then carry classifications with weighted correlation strengths, and the document’s examples are worth quoting for their bluntness: “sparse gamer” and “reader”. These are readable labels, not opaque embedding coordinates, which tells you something about the generation of system this is. Compare it with the 2025 filing on song search, where the user is a concatenated vector with no human readable structure at all. The direction of travel is from labels to geometry.

For ASO the label era is easier to work with. If clusters are named and interpretable, then the practical question is which named behavior pattern your app is the obvious answer for.

What goes into an app profile

Figures 2A and 2B cover app profile generation and the derivation of quality and ranking signals. Four categories are described.

Category	Signals named	Under your control
User behavior	Downloads, ratings, demographics of the audience, search conversions	Indirectly
Derived metrics	Ranking positions, trending factor, stability factor, compatibility, accolades	Partly
Usage patterns	Frequency metrics, installation retention factor	Yes, through the product
Content metadata	Curation information, developer descriptions, tags	Yes

Three of these are unusual enough to name individually.

Installation retention factor. A measure of whether installs stick. Its presence in the app profile means retention is an input to what the store shows people, which closes the loop between product quality and acquisition in a way that marketing led ASO often ignores.

Stability factor. Not defined in detail in the available material. The plain reading is consistency of performance over time, which would sit naturally alongside the trending factor as its counterweight: one rewards acceleration, the other rewards reliability. Crash rate is another possible reading. The document does not settle it.

Accolades. Editorial recognition, stored as a signal. This is the clearest available evidence that a feature has compounding value: the traffic is the visible part, and the entry in the app profile is the part that keeps paying.

Search conversions appearing under user behavior is the fourth thing worth noting, because it is the same loop that shows up in the 2012 query classification family and the 2025 vector family. Conversion on a query is, in every generation of these filings, an input rather than an output.

How topics get derived from your text

The worked example is concrete. A math tutoring app is assigned the topics math, number, answer, problem, addition, subtraction, multiplication and division.

Read that list carefully. Only the first is a keyword anyone would bid on. The rest are the ordinary vocabulary of the subject, and they are what the system uses to decide what the app is about. This is the same principle as the indicator terms in US9280595B2, arriving from a different direction: describe the domain thoroughly and the classification follows, target the head term alone and it does not.

The query modifier

This is the part of the document with the sharpest implications. For search, a query modifier can add, modify or remove words from the query based on the user’s history, before results are ranked.

The example: a user with gaming interest searching a term gets “game”, “gaming” or “games” added, narrowing the result set toward games. Figure 5B shows default results for “Baseball” against the personalized ranking, where presumably a gaming inclined user sees baseball games and another user sees news, scores or ticketing apps.

Three consequences follow, and they are uncomfortable ones for standard ASO reporting.

• A keyword ranking is an average across users whose effective queries differ. Two users typing the same thing may be running two different searches.
• Ambiguous head terms are the most affected. “Baseball” is exactly the kind of term where modification changes everything, while a long specific phrase leaves less room for rewriting.
• Being unambiguously in one category is an advantage under query modification, because the modifier adds category words. An app that straddles two categories is easier to filter out of both.

One honest limit: the query modifier is described in the specification. Whether it survived into granted claims in this family is not something the published record for this continuation settles, and the application is still pending.

Matching and ranking

The matching method is weighted correlation. Signal pairs are compared across the two profile types, for instance the user’s purchase affinity against the app’s purchase related signals, and each pair carries a weight that determines its influence on the final relevance judgment. The ranker applies machine learning when comparing the information to identify correlations, and returns apps ordered by relevance.

Note the abstract’s wording: the user profile is analyzed against a subset of the app profiles, not all of them. There is a candidate selection step before scoring, as in every system of this kind. The document available does not specify how that subset is chosen, which is a meaningful gap, because in practice candidate selection often determines the outcome more than the ranking does.

Privacy framing

The application carries a substantial privacy discussion, acknowledging that personal data such as demographics, location data, telephone numbers, email addresses and health information could be involved, and emphasizing opt in and opt out control plus notification about access and use.

Worth noting for accuracy: no on device processing is described. The architecture as presented is server centric, with profiles held and matched at the server. That is a contrast with other Apple filings of the same era which push processing to the device, and it is a distinction to preserve rather than blur.

How to use this in practice

• Treat day 7 and day 30 retention as ASO metrics. The installation retention factor sits in the same profile that decides recommendations.
• Write metadata to nail one topic set completely rather than to reach across two categories. Query modification and topic derivation both reward clarity of category.
• Stop treating a single keyword rank as the measure of success on ambiguous head terms. Use install volume and conversion by term instead, which survive personalization.
• Pursue editorial features for their durable profile value, not only for the day of traffic.
• Watch your impression to tap ratio on recommendation surfaces. Impressions without taps are a negative signal in this design, so broad exposure to a poorly matched audience is not free.

Related patents on this site

WO2023235143A1 covers the suggested results surface with a bandit approach and shares an inventor, Chandrasekar Venkataraman, with this filing.