Chrome Extension Growth Data: How Every Chart Is Built
This page documents every rule behind our Chrome extension growth data — where numbers come from, how growth is computed, what confidence means, and the failure modes we publish rather than hide. If a chart on this site cannot be explained from this page, that is a bug.
Where the Chrome extension growth data comes from
Three supply lines feed the Chrome extension growth data pipeline. Weekly, we ingest the public Parquet datasets published by Extension Tracker, which carry store snapshots, history, and change events for hundreds of thousands of listings. Daily, we sweep the Chrome Web Store sitemap itself, catching listing IDs the moment they appear. On top of both, a budgeted sampler visits selected store pages to add fresh observations for the extensions that matter most right now.
Every observation is stored as an immutable record: extension ID, metric type, value, raw display string, precision class, timestamp, source, and parser version. Chrome store user counts and Firefox daily-user figures are kept strictly separate — different metrics never blend into one ranking. When two sources disagree, the conflict is recorded, not averaged away, because honest Chrome extension growth data starts with honest inputs.
Weekly bulk import of Chrome extension growth data
Extension Tracker's datasets arrive on a published cadence with checksums and schemas we validate before anything is written. A failed validation stops the batch, never overwriting good data with bad.
Daily sitemap sweep
The store sitemap is public, and we read it politely to feed the Chrome extension growth data: full-shard integrity checks, backoff on errors, and a rule that incomplete sweeps never produce "new listing" diffs.
Targeted sampling
A daily budget of store-page samples prioritizes fresh launches, rising candidates, and entries whose windows need one more point to be scoreable.
From observations to Chrome extension growth data
In this Chrome extension growth data, a growth figure is only ever the difference between two valid observations. For a 7-day number, the two samples must sit 5 to 9 days apart; for 30-day numbers, 25 to 35 days. The true gap in days is stored with the result and printed on detail pages. Windows that do not fit are labeled insufficient history — the row stays visible, the growth column stays empty, and no Chrome extension growth data is invented to fill the gap.
Deduplication in the Chrome extension growth data happens on the tuple of extension, metric, source, and timestamp, so re-fetching the same page twice can never inflate a trend. Removals, renames, and category changes are kept as history rather than silently overwritten, which is how long-running Chrome extension growth data can still answer questions about last month, not just this morning.
Two samples, minimum
No observation pair, no growth number. One snapshot is a fact about a moment; two are the beginning of a trend.
True gaps, printed
A "7-day" delta computed from samples 6.2 days apart says so. The window tolerance exists for reality, not for marketing.
Immutable history
Corrections append; they never rewrite the Chrome extension growth data underneath them. If a number changes, the record of the change survives alongside it.
Confidence rules in our Chrome extension growth data
Every figure in the Chrome extension growth data carries one of four confidence labels. High means both samples are well-timed, the counts are exact, and the sources agree. Medium tolerates mild rounding or a slightly stretched window — the number is printed with an approximation mark. Low means the samples are stale, heavily rounded, or in conflict; low-confidence entries are excluded from the main ranking rather than displayed as fact, because Chrome extension growth data that cannot defend itself should not sit at the top of a chart.
The fourth label, insufficient history, is the most common on the newest listings. It is not an error state — it is the correct answer for anything younger than its first valid window. Publishing Chrome extension growth data responsibly means showing that answer instead of a plausible-looking guess, even when an empty column is less glamorous than a number.
High
Well-timed window, exact counts, consistent sources. Scores count at full weight in every chart.
Medium
Minor rounding or slight window stretch. Counted at 70% weight and displayed with an approximation mark.
Low / insufficient
Stale, rounded, conflicting, or simply too young. Held out of rankings; shown only with an explanation.
Freshness, failure modes, and fail-closed publishing
The Chrome extension growth data rebuilds once a day from the latest validated snapshot, and every page prints the exact data-as-of timestamp. If an upstream source fails, the last successful chart is served with a stale marker rather than an empty table; if freshness exceeds 48 hours, "new today" claims are suppressed until the pipeline recovers. No ranking is ever silently degraded to keep a page looking alive — the state of the Chrome extension growth data is part of the page.
Rounded store badges receive special discipline. A listing that displays "10,000+ users" contributes a range, not the number 10,000, and ranges are never converted into precise-looking percentages. Zero baselines make percentages inapplicable rather than infinite. These rules make our Chrome extension growth data less spectacular — and considerably more useful to anyone making decisions with it.
Stale, never empty
Pipeline failure keeps the last good chart with a visible staleness notice. Empty charts erode trust; honest lags do not.
Ranges stay ranges in our Chrome extension growth data
"10K+" never becomes exactly 10,000. Precision labels travel with every number, all the way to the page.
No infinity, ever
Growth from zero is marked not-applicable. A division by zero is a math lesson, not a ranking signal.
The growth score, in the open
relative_component = log1p(max(pct_growth, 0))
absolute_component = log1p(max(delta_users, 0))
score = 0.55 * normalized(relative_component)
+ 0.35 * normalized(absolute_component)
+ 0.10 * freshness_component
score *= confidence_multiplier # high=1.0 medium=0.7 low=excludedNormalization is computed per platform and per window across the current candidate set, so large incumbents cannot dominate by scale alone. These weights are our starting hypothesis, versioned with the dataset — when they change, this page changes with them, and the chart history keeps the version it was built under. Every figure produced by this formula is Chrome extension growth data you can recompute from the published observations.
What this dataset cannot do
Coverage is not the whole store
Weekly bulk data and daily sampling cover a great deal, but not every listing every day. Charts describe observed growth, and we say observed, not “the entire store”.
Store numbers are self-reported
We measure what the store displays. Installs that the store rounds, delays, or batches are invisible to everyone, including our Chrome extension growth data.
The youngest listings are unscorable
Hours-old extensions have one observation. That is a fact about time that Chrome extension growth data cannot engineer away before week one ends.
Ranking is a lens, not a verdict
Scores compress several dimensions into one order. Use them to find candidates in the Chrome extension growth data; use the detail pages and the store itself to judge them.
Sources and attribution
Growth history in ExtensionRadar's Chrome extension growth data builds on the public weekly datasets published by Extension Tracker, used under Creative Commons Attribution 4.0, combined with our own daily sitemap sweeps and store-page samples. We recommend reading their methodology alongside this page. ExtensionRadar is an independent project and is not affiliated with Google or the Chrome Web Store.