# Google NavBoost: What the Trial Record and Leak Confirm

> NavBoost is Google's click-based re-ranking system. See what DOJ trial testimony and the leaked schema confirm: its 13-month window, Glue, and what's myth.

- URL: https://missiongrowth.io/blog/navboost
- Published: 2026-07-13 · Updated: 2026-09-24
- Author: Ömer Furkan Aktaş, Founder, Mission Growth
- Publisher: Mission Growth. Company facts: https://missiongrowth.io/llms.txt

NavBoost is Google's click-based reranking system for organic web results, confirmed directly in the US v. Google antitrust trial and named inside [the leaked Content Warehouse documentation](https://missiongrowth.io/blog/google-leak-site-authority). As a Google click ranking system, it only touches the ten blue links, never the rest of the page.

This guide works from the primary record on google navboost directly: the trial transcript, the leaked schema's own field descriptions, and what Google's own witness said when a federal judge asked him to rank NavBoost's importance.

## What is NavBoost?

NavBoost is Google's click-based reranking system for organic web results, confirmed in the US v. Google antitrust trial and named directly in Google's leaked ranking documentation.

Under cross-examination, Google's head of Search, Pandu Nayak, confirmed NavBoost's exact scope in the [trial transcript](https://thecapitolforum.com/wp-content/uploads/2023/10/101823-USA-v-Google-PM.pdf) when cross-examining counsel put it to him: NavBoost "does web results," while a related system called Glue "does everything else that's on the page that's not web results" (Tr. 6403:3-11).

That's a specific, scoped claim. NavBoost isn't a synonym for "Google uses clicks somewhere." It's one reranking layer inside a much larger pipeline, and the rest of this guide follows the trial record and the leaked schema to show exactly where.

## Where NavBoost sits in Google's ranking pipeline

The navboost algorithm sits between Google's initial retrieval stage and its machine-learning rerankers, narrowing tens of thousands of candidate pages toward a few hundred before anything else touches them.

Retrieval alone produces "tens of thousands" of candidate pages. NavBoost and the other core ranking signals narrow that down to "the top few hundred" (Tr. 6407:14-6408:4).

Cross-examining counsel gave that narrowing a courtroom nickname, walking Nayak through a demonstrative exhibit that labeled the wider candidate set the "green ring" and the narrower one the "blue ring" (exhibit DXD17-4). Nayak's first response rejected the framing: "No, navboost doesn't help you -- I mean, it's certainly a factor, but it's not the only factor by any means" (Tr. 6403:16-19).

Only once counsel softened the question did he agree: "It helps. It's certainly a factor, yes." (Tr. 6404:5-9). The ring language comes from counsel's demonstrative, and that exhibit names NavBoost as one factor among several in the pipeline.

After NavBoost narrows the field, RankBrain and DeepRank take over. Asked directly, Nayak confirmed: "RankBrain looks at the top 20 or 30 documents and may adjust their initial score; is that right?" "That is correct." (Tr. 6431:11-14).

In parallel, a separate system handles everything on the page that isn't a web result. Nayak calls it Glue, "just another name for navboost that includes all of the other features on the page" (Tr. 6403:3-11).

Glue's output then feeds into a final assembly system named Tangram, formerly called Tetris internally, which combines it with other inputs to build the page a searcher actually sees (Tr. 6408:8-21).

Google iterates on this pipeline constantly. Asked about a figure of 616,386 test runs, Nayak told the court those were "individual experiments," adding: "because they're easy to run, people tend to run a lot of them" (Tr. 6427:12-15). That pace of testing is why NavBoost's weighting shifts over time even though its position in the pipeline stays fixed.

::figure{src="/blog/figures/navboost-1.svg" alt="Google's ranking pipeline: retrieval yields tens of thousands of candidates, NavBoost narrows them to a few hundred, then RankBrain and Tangram finish the page" caption="NavBoost narrows tens of thousands of candidates toward a few hundred before Google's machine-learning rerankers and Glue's SERP-feature system take over." width="720" height="385"}

## What NavBoost actually tracks: the click signals Google documented, and the ones it didn't

NavBoost's leaked schema names clicks, goodClicks, badClicks, lastLongestClicks and impressions, but the [schema itself](https://hexdocs.pm/google_api_content_warehouse/0.4.0/GoogleApi.ContentWarehouse.V1.Model.QualityNavboostCrapsCrapsData.html) defines only some of them.

Here's what the schema does and doesn't say about these navboost click signals: in the `QualityNavboostCrapsCrapsData` structure, the fields `clicks`, `goodClicks`, `badClicks`, `query` and `url` carry no description text at all. Only `lastLongestClicks` gets a real definition: "the number of clicks that were last and longest in related user queries."

That asymmetry matters. A guess that goodClicks means a long dwell and badClicks means a pogo-stick return might be right, but the schema never says so. Treat those two fields as genuinely undocumented, not settled fact, because that silence is itself the finding.

Two other fields get corrected here, because the schema is specific where a common claim isn't. `unicornClicks`, inside the nested ClickSignals structure, is often called unknown. It isn't. The schema defines it as "the subset of clicks that are associated with an event from a Unicorn user."

`unsquashed` is sometimes guessed to be a bot-detection field. The schema instead documents it as a migration note: "we will start using this one for the retuning rollout," with no bot-related role written anywhere. The field that actually does that job is separate: `unscaledIpPriorBadFraction`, an IP-address-based prior that feeds a transformation applied in `craps-penalty.cc`.

The schema also carries three fields built for the situations that break most click-based systems: brand-new pages with no history, and click floods designed to fake demand. `patternLevel` falls back from a single URL's own data to its site or host when that URL's history is thin. `sliceTag` is an arbitrary custom slice, device, country, locale or anything else the pipeline is told to track, aggregated separately per tag.

`voterTokenCount` sets a lower bound on distinct users behind a signal, filtering out entries that don't clear a privacy floor.

::figure{src="/blog/figures/navboost-2.svg" alt="NavBoost's CrapsData fields: lastLongestClicks and unicornClicks are documented, while clicks, goodClicks and badClicks carry no description" caption="Of NavBoost's leaked click-signal fields, only some carry a documented definition; clicks, goodClicks and badClicks do not." width="720" height="397"}

## The 13-month window, and what resets it

NavBoost stores 13 months of click history for every query-URL pair, down from an 18-month window before 2017.

That's the same window confirmed at trial. Nayak testified NavBoost keeps click history for 13 months, and before 2017, for 18 months (Tr. 6405:15-25).

::figure{src="/blog/figures/navboost-3.svg" alt="NavBoost's rolling click-history window compares 18 months before 2017 with the 13-month window it uses for every query-URL pair since." caption="NavBoost cut its rolling click-history window from 18 months to 13 months after 2017." width="720" height="182"}

The practical consequence is a cold start. A brand-new URL has zero click history on day one, so NavBoost has nothing to boost or bury yet. That gap doesn't close the moment a page gets indexed; it closes only as real clicks accumulate.

That's exactly the situation `patternLevel` exists for: with no URL-level history of its own, a new page borrows a signal from its site or host instead of carrying none at all.

## NavBoost, Glue and Tangram: three different systems

NavBoost reranks organic web results, Glue decides which non-web SERP features to show, and Tangram, formerly named Tetris, assembles both into the final results page.

Nayak drew the line when cross-examining counsel put it to him and he agreed: NavBoost "does web results," and, in his own words, Glue "is just another name for navboost that includes all of the other features on the page" (Tr. 6403:3-11). That's the core of any navboost vs glue comparison, but it stops one step short.

It's really three systems. Glue's output doesn't go straight to the page. It feeds into Tangram, which Nayak described as the system that "takes other inputs, other signals also" and does the actual assembly (Tr. 6408:8-21).

Here's how the three break down:

| System | Handles | Feeds into |
|---|---|---|
| NavBoost | Organic web results, the blue links | Tangram |
| Glue | Non-web SERP features: images, panels, other page elements | Tangram |
| Tangram (formerly Tetris) | Final assembly of web and non-web elements | The results page itself |

## How NavBoost slices data by locale and device

NavBoost keeps separate click datasets by country, language and device, so the same query can rank differently on mobile than on desktop.

Nayak confirmed the slicing directly: NavBoost "slices the data information that it has in it by locale" and "also slices the data information by mobile versus desktop," creating a separate dataset for each category (Tr. 6412:19-6413:6).

His own trial example makes the effect concrete. For the query "Bank of America," mobile searchers skew toward branch-locator intent, they want the nearest branch, while desktop searchers skew toward online-banking intent, they want to log in (Tr. 6413:8-15). Same query, two devices, two different click histories, two different result sets.

::figure{src="/blog/figures/navboost-4.svg" alt="NavBoost's device slicing for the query Bank of America: mobile searchers show branch-locator intent, desktop searchers show online-banking intent." caption="NavBoost keeps a separate click dataset for mobile and desktop, so the same query can rank differently by device." width="720" height="228"}

## Is NavBoost really Google's "most powerful" ranking signal?

NavBoost's own importance went unranked by Google's own witness when a federal judge asked him to rank it directly; he called it only "one of the important signals" Google has.

Two different framings repeat the same unsupported certainty. One states flatly that NavBoost is one of Google's strongest ranking signals. Another hedges the same idea: NavBoost "has been described as" one of Google's most powerful signals, without saying by whom. Neither survives what actually happened when the trial judge pressed Nayak on the question.

Asked directly where NavBoost sits in "the hierarchy of important variables," top 10%, top 25%, or top half, Nayak declined to give that ranking. His answer: "navboost is one of the important signals that we have" (Tr. 6472:15-6473:3).

Under direct questioning from the bench, that's the strongest claim Google's own head of Search would commit to. Not "the most powerful." For the other factors that shape a ranking beyond NavBoost, see [the full breakdown of Google ranking factors](https://missiongrowth.io/blog/how-to-rank-higher-on-google).

### Why the framing sticks anyway

There's a structural reason the "most powerful" framing sticks even though Nayak wouldn't endorse it. Google engineer Eric Lehman testified that evaluating NavBoost by looking at its own click data is "somewhat misleading," calling the pattern "almost circular": "The navboost system, what it does is observe documents that in the past got lots of clicks, and then it boosts those" (Tr. 1928:9-1929:1).

Two lines later he named it again, this time as a noun: "the near circularity."

Pages that got clicks in the past get boosted, which produces more clicks, which the evaluation system then reads as proof NavBoost is working.

That's the same shape a 2006 Science study found in a very different market. Salganik, Dodds and Watts ran an experiment with 14,341 participants downloading previously unknown songs, some of whom could see how many times each song had already been downloaded.

Increasing that visible social signal raised both inequality and unpredictability in which songs became hits, though the best songs rarely did poorly and the worst rarely did well regardless.

The mechanism is cumulative advantage: a stored signal of past popularity gets shown to future choosers, and their choices compound on it, independent of quality at the margin. That's the same shape Lehman described inside NavBoost's own click history.

For a new page competing in a crowded topic where several pages are similarly relevant, genuine early clicks (internal links, first-week distribution, direct traffic) matter more than content polish alone, because NavBoost's feedback loop compounds small early differences into larger ones over time.

The transfer has real limits: it applies to that unpredictable middle, not to genuinely bad or exceptional pages, and it wouldn't hold if Google's documented position-bias correction fully neutralized early-click advantage rather than merely discounting it.

## Does NavBoost use your Chrome browsing data?

NavBoost's leaked field list and Nayak's and Lehman's NavBoost testimony both stay silent on Chrome: neither names Chrome browsing data as an input.

A full-text search for "chrome" in both schema pages and in Nayak's and Lehman's NavBoost testimony returns zero matches; the word appears only in a different witness's unrelated browser-privacy testimony elsewhere in the same transcript. That's a real question, and nothing public confirms it either way. A claim that NavBoost "might" use Chrome data is speculating past what the documents support.

## What to actually do about NavBoost

NavBoost responds to real user satisfaction, so the fastest way to see whether it's helping or hurting a page is to read Search Console for the matching Craps pattern.

Here's how to map what you see in Search Console to the specific field that's most likely behind it, and what to try first:

| Search Console pattern | Likely Craps field behind it | What to try first |
|---|---|---|
| High impressions, flat position, low CTR | Weak clicks relative to impressions | Rewrite title and description to match query intent |
| Clicks land but position doesn't move for weeks | lastLongestClicks isn't accumulating | Deepen the page so a return visit becomes the last, longest click |
| New page, everything near zero | No click history yet inside the 13-month window | Expect a lag; internal links let patternLevel borrow a site-level signal |
| Clicks arrive, then a fast bounce back to search | A badClicks pattern | Fix the gap between what the title promises and what the page delivers |
| A click spike with no ranking gain | Possibly discounted by unscaledIpPriorBadFraction or the voterTokenCount privacy floor | Check for bot traffic or an unnaturally narrow audience before blaming the content |

That mapping only goes so far without knowing how much organic traffic AI Overviews are already intercepting before a click happens at all. See [the AI Overview CTR data](https://missiongrowth.io/blog/what-ai-overviews-mean-for-seo) for the fuller picture of where those clicks are going instead.

If you'd rather track these patterns systematically than pull Search Console exports by hand, [an SEO dashboard built on Search Console](https://missiongrowth.io/blog/seo-dashboard) catches a badClicks pattern earlier than a manual check will.

NavBoost is real, well-documented in the trial record and the leak, and exactly as powerful as Google's own witnesses were willing to say under oath: one important signal among several, not the single lever that decides a ranking. Every specific claim here, the pipeline position, the documented and undocumented Craps fields, the courtroom correction of "most powerful," traces to a transcript page or a schema entry you can open yourself.

Start there. Pull your own Search Console data against the table above and find which Craps pattern actually matches your traffic before you change anything.

## FAQ

### Does NavBoost use Chrome browsing data?

No, not according to NavBoost's own testimony or the leaked field list. A full-text search of both schema pages and the NavBoost testimony turns up zero mentions of Chrome; the word appears only in a different witness's unrelated browser-privacy testimony, so nothing public confirms it either way.

### Is NavBoost Google's biggest ranking factor?

No single factor holds that title. When a federal judge asked Google's own witness to rank NavBoost's importance directly, he declined and called it only "one of the important signals that we have," not the most powerful one.

### How long does NavBoost take to affect a new page?

It only accumulates once real clicks happen. A brand-new URL starts with zero click history inside NavBoost's 13-month window, so any effect builds gradually as impressions turn into clicks over the following weeks.

### What's the difference between NavBoost and Glue?

NavBoost handles organic web results only. Glue handles everything else on the results page, non-web features like images and panels. A separate system, Tangram, assembles both into the page a searcher sees.

### Is unsquashed clicks a bot-detection signal?

No. The schema documents `unsquashed` as a data-migration field tied to a retuning rollout. The field that actually flags suspicious click traffic is `unscaledIpPriorBadFraction`, an IP-based prior.