US 2013/0325892 A1: Application Search Querry Classification

This article is the applied companion to Apple’s query classification family. It takes the three class framework from the patent and turns it into a working method for keyword research and Apple Search Ads structure. For the mechanics of the invention itself, see US9405832B2. For the publication history and citation guidance, see US20130325892A1.

Publication number	US 2013/0325892 A1
Official title	Application search query classifier
Assignee	Apple Inc.
Inventors	Catherine A. Edwards, Alexander F. Braunstein, Eva H. Mok, Natalia Hernandez-Gardiol
Priority date	May 31, 2012
Granted as	US9405832B2, August 2, 2016
Source	Full text PDF

What This Patent Covers and Why It Matters for ASO

Feature it describes: query intent classification in App Store search, and with it, the reason a single keyword strategy cannot work across a whole keyword list.

Apple’s filing describes classifying every search into a type, primarily navigational, functional or browse, and then switching the search and ranking technique to match. The important consequence for practitioners is not the classification itself. It is that the levers available to you change depending on which class a keyword falls into, and you have no direct control over which class that is.

Most keyword lists are built as a flat set, scored on search popularity and difficulty, then optimized as one problem. If Apple is running anything like the method in this patent, that is the wrong shape. A list of two hundred keywords is really three lists that need different metadata treatment, different Apple Search Ads match types, different creative, and different success criteria.

This article sets out how to do that split with data you can actually get, and what to change once you have.

The caveat stands as always. This is a patent, not documentation. It describes what Apple designed and claimed in 2012. Treat the framework as a well evidenced hypothesis worth structuring work around, not as confirmed store behavior.

Patent Summary

The application describes classifying each app store search into a type and then selecting the search and ranking technique accordingly. Navigational queries are searches for a specific app by name. Functional queries are searches for an app that performs a task. Browse queries are exploratory. Location based and price based categories are also named but not developed.

Classification blends three evidence types: textual signals in the query such as capitalization, quotation marks, query length and characteristic words, the shape of a preliminary result set, and empirical data from past identical queries, above all the distribution of which apps people downloaded afterward. A concentrated download distribution indicates navigational intent. A dispersed one indicates functional intent.

The techniques then diverge. Navigational queries weight exact title matching and term frequency in metadata. Functional queries broaden to semantically similar metadata and weight popularity signals such as downloads and ratings far more heavily. Browse queries lean on ratings and popularity with reduced reliance on text.

Detailed Explanation

Step 1: classify your own keyword list

You cannot read Apple’s classification. You can infer it, because the patent tells you what the classification is based on, and two of the three inputs are observable from outside.

The strongest available proxy is concentration of outcome, which is the patent’s own primary test. Run the query and look at the result set.

Classifying a keyword from observable signals

Signal	Points to navigational	Points to functional	Points to browse
Top of results	One app holds rank 1 across storefronts and over time	Top 10 reshuffles, no permanent owner	Top results are broad category leaders
Title matching	Winner contains the term exactly in the title	Winners often do not contain the term literally	Winners rarely contain the term
Query length	One or two words	Two to five words, often a task phrase	Contains “best”, “top”, “free”, a category noun
Ratings profile of winners	Mixed. A brand can win with mediocre ratings	Skews toward high rated apps	Strongly skews to high rating and high volume
Apple Search Ads exact vs broad	Large gap in tap through and conversion between exact and broad	Broad performs comparably to exact	Broad delivers volume, conversion is weak

Tag every keyword in your list with one of the three. Expect roughly a quarter to be genuinely ambiguous, and leave those unlabeled rather than forcing them, because ambiguity is itself information: the patent notes that navigational and functional can be mutually exclusive, so a term that looks like both is usually a term in transition.

Step 2: change what you optimize per class

Navigational terms, including your own brand. Text weighting is at its highest here, so exact presence in the title and subtitle is the lever that works. Defending your own brand term is non negotiable, and competitor brand terms are an organic dead end since the incumbent owns the exact match and the download concentration that reinforces it. Put budget here in Apple Search Ads rather than metadata effort, because paid placement is the only way onto a navigational query you do not own.

Functional terms. This is where metadata work pays. Text weighting drops and semantic matching plus popularity rise, which means the win condition is being recognizably about the function, not repeating the phrase. Build out the vocabulary of the task, not the keyword. Conversion rate matters more here than on navigational terms, both as a ranking input and because a dispersed download distribution is exactly the condition under which a new entrant can take share.

Browse terms. Ratings and popularity dominate and text barely matters, so metadata optimization has close to no leverage. Do not spend keyword slots on “best” and “top” constructions. If you want browse traffic, the levers are rating volume, rating average, and category level visibility, plus paid placement. Treat browse terms as a rating strategy problem rather than an ASO problem.

Step 3: map the classes onto Apple Search Ads structure

The classification maps onto campaign architecture cleanly, and it gives you a principled reason for a structure that many accounts arrive at by trial and error.

Campaign treatment by query class

Class	Campaign	Match type	Product page	Primary metric
Navigational, own brand	Brand defense, isolated	Exact	Default or a page matching brand expectation	Impression share, cost per acquisition
Navigational, competitor	Competitor, isolated per competitor	Exact	Custom page arguing the switch	Conversion rate, then cost per acquisition
Functional	Generic, grouped by task	Exact for proven terms, broad for expansion	Custom page per task cluster	Conversion rate and retention of the cohort
Browse	Discovery	Search match and broad	Default	Cost per acquisition, with a low ceiling

Two points about this table are worth making explicit. Custom product pages earn their keep on functional terms because the query states the task, so the page can answer it. On browse terms the query states nothing specific, so a custom page has little to respond to. And negative keywords matter most between the functional and browse campaigns, because browse constructions leaking into a task campaign will quietly destroy its conversion rate.

Step 4: use search popularity correctly within each class

Apple Search Ads search popularity is the only first party demand signal available for App Store queries, and it should be read per class rather than as one scale.

A high popularity navigational term is almost worthless to you unless you own it, because concentration means one app absorbs the outcome. A mid popularity functional term with a dispersed result set can be worth far more than its score suggests, because the class is winnable. A high popularity browse term is usually a trap: real demand, negligible text leverage, and expensive paid competition.

Ranking a keyword list by popularity alone therefore sorts your opportunities in close to the wrong order. Sort within class, not across classes.

Step 5: watch for class migration

The patent describes the empirical database as continuously updated with older data progressively down weighted. Classification is therefore not fixed, and a term can move between classes as behavior changes.

The migration that matters commercially is functional to navigational. When one app accumulates enough download concentration on a generic task query, the query starts behaving like a brand query, text weighting rises, and the incumbent’s exact title match becomes a moat that was not there before. This is the mechanism by which a category term quietly becomes owned.

Practical monitoring: track rank 1 stability per keyword monthly. A term where the leader has not changed in six months and holds across storefronts has probably migrated. If that term is strategically important to you, the window to compete on metadata has closed and the remaining route is paid.

Where this framework breaks

Honesty about the limits matters more than the framework itself.

The patent is from 2012 and the family has lapsed. Apple’s later filings on semantic embeddings and personalized ranking describe a substantially different architecture, in which a hard three way classification may no longer exist as a discrete step.
Personalization undermines the observability the method depends on. If results are tuned per user account, then rank 1 stability measured from your own device is a weaker proxy than it looks.
The three classes are not exhaustive even within the patent, which names location based and price based categories without describing them.
Nothing here is measurable directly. Every signal in the classification table is an inference from output, and inferences accumulate error.

Used as a way of organizing a keyword list and choosing where to spend effort, the framework is sound. Used as a claim about what the App Store is doing right now, it is not.