Introduces an explicit per-query location sensitivity factor that decides how much the location score should influence ranking for that specific query, rather than applying location ranking uniformly.
Patent Overview
- Inventor
- Amit Singhal
- Assignee
- Google LLC
- Filed
- 2003-09-22
- Granted
- 2012-05-01
- Application Number
- US 12/615,098
The Challenge
Not Every Query Is Equally Location-Sensitive
Uniform combination of topical and location scores under-serves both ends of the spectrum. Highly local queries ("plumber", "emergency room") need strong location bias. Non-local queries ("history of rome", "javascript tutorials") need none. Applying the same combination weights to every query produces local results for broad queries and broad results for local queries. The system needs a per-query estimate of how much location should matter.
- Uniform Weighting Misses Both Ends — If location always contributes the same percentage of the ranking score, local queries get too little location bias and broad queries get too much. The result is mediocre rankings for everyone.
- Location Sensitivity Is Inherent To The Query — Some queries express local intent intrinsically (services, restaurants, shops). Others do not (information, entertainment, history). The query itself carries the signal of how much location matters.
- Need A Per-Query Sensitivity Estimate — The system needs to compute, per query, how location-sensitive the query is. The estimate becomes the weight applied to the location score.
- Sensitivity Cannot Be Hand-Coded — Query patterns evolve; manually labeling every query type by location sensitivity is unsustainable. The estimate must be derived from data, not curated lists.
- Borderline Cases Are Common — Queries like "coffee shops" are moderately location-sensitive; "coffee history" is not at all. The sensitivity must be continuous, not binary, to handle the spectrum properly.
Innovation
Per-Query Location Sensitivity Factor
For each query, the system computes a location sensitivity factor representing how much the location score should influence ranking. The factor is derived from query terms, query patterns observed in logs, and the geographic distribution of past clicks on results for similar queries. The factor weights the location score in the final combined ranking, producing continuous trade-offs between local and global emphasis.
- Analyze Query Terms For Location Cues — Scan the query for terms that signal location intent: explicit place names, service verbs ("near me", "in my area"), category words associated with local services ("plumber", "restaurant", "clinic").
- Look Up Query Pattern Data — Match the query against patterns seen in logs. Patterns associated with high click concentration on local results have high sensitivity. Patterns with global click distribution have low sensitivity.
- Compute Sensitivity Factor — Combine the term-level cues and pattern-level data into a continuous sensitivity factor between 0 (no location influence) and some maximum value (strong location influence).
- Retrieve Candidate Documents — Standard topical retrieval produces the candidate set responsive to the query.
- Compute Per-Candidate Scores — Compute topical score and location score for each candidate as before.
- Apply The Sensitivity-Weighted Combination — Combine the two scores using the sensitivity factor as the location weight. High-sensitivity queries get location-heavy combinations; low-sensitivity queries leave topic dominant.
- Rank And Return — Order candidates by the sensitivity-adjusted combined score and return the top-k.
Sensitivity Per Query, Not Per System
Instead of one universal weight for location, the system computes a fresh weight for every incoming query. Queries that are obviously local get strong location bias; queries that are obviously global get none. The continuous middle gets continuous adjustment.
Query-Specific Weighting
The amount that location matters in ranking is a property of the query, not a property of the ranking system. The system reads that property per request.
- Term-Level Signals — Words and phrases in the query that imply location intent. Place names, proximity terms, locally-bound service categories. Fast to compute per query.
- Pattern-Level Signals — Historical patterns observed in similar queries. If past users clicked on local results when searching this kind of query, sensitivity is high. The signal is derived from log analysis.
The same ranking system serves local and global queries by reweighting per query.
<\/section>Technical Foundation
What The Factor Is Built From
The sensitivity factor combines term-level evidence (immediate, query-local) with pattern-level evidence (aggregate, log-derived).
- Location Sensitivity Factor — A continuous value representing how much location should influence ranking for the given query. The factor weights the location score in the combined ranking formula.
- Term-Level Cues — Words in the query that signal location intent: explicit place names, proximity terms, locally-bound service categories. Fast to compute per query.
- Pattern-Level Cues — Aggregate signals from past similar queries: click concentration on local results, geographic spread of clicked documents. Derived offline from logs.
- Combination Formula — How the sensitivity factor weights the location score. Linear scaling is straightforward; learned combinations can produce non-linear adjustments.
Quality Metrics
- Location Sensitivity Factor — Bounded between 0 and a maximum value. The function combines fast term-level signals with offline-derived pattern data.
sens(Q) = f(terms(Q), pattern(Q)) - Sensitivity-Adjusted Combined Score — The location score contributes only as much as the sensitivity factor allows. Non-local queries (sens=0) ignore location entirely.
rank(D, Q) = top_score + sens(Q) * loc_score
Key Insight: The sensitivity factor turns location-aware ranking from a one-size-fits-all setting into a per-query decision. The factor is the key technical addition over the prior US7606798: same two-score framework, but with explicit sensitivity gating that lets the same ranking system serve very different query types well.
<\/section>The Process
How Sensitivity Gets Computed
The sensitivity factor runs per query. Term analysis is fast and per-request; pattern matching uses precomputed log-derived data.
- Tokenize And Tag — Split the query into tokens. Tag tokens that match known location cue dictionaries (place names, proximity terms, local service categories).
- Score Term-Level Cues — Sum the term-level location signals. Queries with many location cues score high on this component.
- Match Pattern Library — Match the query against the library of query patterns built offline from logs. Each pattern has an associated sensitivity score from historical click behavior.
- Combine The Two Components — Combine term-level and pattern-level scores into the final sensitivity factor. Bounded to a maximum value to prevent over-weighting.
- Pass To Ranking — The factor flows into the ranking combination formula, where it weights the location score relative to the topical score.
Quality Control
Quality Control
Avoiding Over- And Under-Weighting
Bad sensitivity estimates produce bad rankings in both directions. Several controls keep the factor honest.
- Maximum Sensitivity Cap — Even the most location-sensitive queries cap their sensitivity factor at a configured maximum. The cap prevents pathological cases where topical relevance is entirely suppressed.
- Minimum Floor — Some location bias may be applied universally (very small weight) so that location signals never disappear entirely. The floor prevents the factor from going fully to zero.
- Pattern Confidence Gate — Pattern-level sensitivity is only applied when the matched pattern has enough historical data to be reliable. Low-confidence patterns contribute less to the factor.
- Calibration Against Click Data — Periodic calibration compares predicted sensitivity against observed click behavior on served results. Drift in either direction triggers retuning of the sensitivity computation.
What This Means for SEO
What This Means for SEO
Per-query location sensitivity is why some keywords are clearly local battles and others are not. Understanding this changes how you map keyword intent and prioritize geographic targeting.
- Map Queries By Location Sensitivity — Before targeting a query, estimate its sensitivity by checking whether current SERPs are dominated by local results, mixed, or globally diverse. The SERP itself is the system’s answer to the sensitivity question.
- Highly Sensitive Queries Need Geographic Specificity — Queries like "plumber" or "emergency room" demand explicit location coverage on your pages. Without it, your content is invisible to the location-heavy ranking that high-sensitivity queries receive.
- Non-Sensitive Queries Don’t Need Location Signals — Information queries with low location sensitivity get little benefit from local optimization. Investing in NAP, schema, and per-city pages for these queries is wasted effort.
- Borderline Queries Reward Both Strategies — Queries with moderate sensitivity (e.g., "coffee shops") reward content that is both topically deep and locally specific. Cover the topic comprehensively AND name your locations explicitly.
- Service Verbs Tilt Sensitivity Up — Adding verbs like "hire", "near me", "in [city]" to a query raises its sensitivity factor. Long-tail content targeting these forms benefits more from location optimization than head terms in the same topic.
- Sensitivity Can Drift With User Behavior — Pattern-level sensitivity is derived from historical clicks. If user behavior shifts (e.g., a topic becomes more local over time), the sensitivity factor adjusts. Monitor your topic’s SERP composition over months, not days.