Why Chrome Web Store Analytics Are Inaccurate (And What to Use Instead)

Every Chrome extension dev has had the moment: the Web Store dashboard says one thing, your own data says another, and you can't reconcile them. It's not a bug. The Chrome Web Store analytics page has six structural accuracy problems that Google has never documented and isn't going to fix — they come from the shape of the data Google is willing to share, not from a glitch. This guide is what those problems are, what numbers should diverge between CWS and your own SDK (and what each gap means), and what CWS is still legitimately useful for.

The CWS dashboard, ranked by what it tells you

Before the problems, an honest catalogue. The Chrome Web Store Developer Dashboard exposes:

• Total installs (cumulative) — count of distinct profiles that have installed your extension and have not uninstalled. Useful, lags by 2–3 days.
• Weekly users — "active" users in the trailing 7 days, by an undocumented definition. Opaque.
• Weekly impressions — your listing card appearing in a CWS surface (search, category, related). Only counts CWS surfaces, not Google Search. Useful as a ceiling, not a denominator.
• Ratings + reviews — current rating, count by star, recent review text. Useful and timely.
• Country and language splits — coarse breakdown of installs. Useful for marketing, not for product decisions.
• Items per week — installs minus uninstalls per week. The closest you get to net growth, and even this lags.

Notable absences: no DAU, no MAU, no retention curve, no cohorts, no per-version uninstalls, no install source, no activation rate, no funnel. The dashboard is built to answer "is this extension growing?" — not "is it healthy?".

Problem 1 — weekly aggregation + multi-day lag

Install counts on CWS update once per day at best, often with a 2–3 day lag, and several user-facing tiles (weekly users, items per week) are 7-day rolling windows that don't update mid-week. Practical consequences:

• You ship version 4.2 on Monday. By Tuesday the worker is crashing for 8% of users. CWS won't show the uninstall spike until next week, by which time you have a full week of churn baked in.
• You launch on Hacker News. CWS install count looks flat for two days, then jumps. The actual install moment is invisible — you can't verify your landing-page funnel against any CWS metric in real time.
• A/B-test-via-listing-change comparisons are gated on at least two full weekly cycles per variant, per the discussion in CWS conversion rate.

Your own SDK doesn't have this lag. Every event lands within seconds; counts are live. If you compare an SDK-reported 24-hour install count to the CWS daily count, the SDK number should look 2–3 days ahead of CWS.

Problem 2 — "weekly users" is undocumented

The single most-cited CWS number is also the one Google has documented the least. "Weekly users" appears as the big headline on every extension's public listing. Nobody outside Google can audit what it counts. Practical observations from comparing it to instrumented data:

• It's not unique installs in the last 7 days — it's far lower than that for most extensions.
• It's not DAU × 7 — for engaged extensions it's much lower than that too.
• It's closest to some opaque definition of "Chrome connected to a profile that has the extension enabled and signed in" — but the exact mechanism isn't shared, and changes to it (which have happened) are never announced.

Translation: you can watch the trend, but you cannot reason about the absolute number. If you want a definition you control — one you can defend in a board meeting and audit against your event stream — the only path is your own DAU/MAU. The patterns for that are in the DAU/MAU guide.

Problem 3 — no retention, no churn

Total installs goes up. Weekly users stays flat. There is one thing this can mean: your churn matches your acquisition. CWS will never say that sentence. There is no retention cohort, no D7/D30 curve, no churn rate metric on the dashboard at all.

The closest you can compute from CWS-only numbers is 1 − weekly_users / total_installs as a very rough "dormancy ratio" — and even that is meaningless given the opacity of weekly users. Your own SDK gives you per-cohort retention because you control the install event and the activity events. Combine the two and you find the leaky bucket, per the uninstall diagnostic guide.

Problem 4 — no per-version split on uninstalls

CWS reports total weekly uninstalls. It does not tell you which version of your extension those users were on when they uninstalled. This makes regression detection from CWS data alone impossible.

The fix from your own side: send extension_version as a property on every event (from chrome.runtime.getManifest().version) — same pattern as the error tracking guide. Then group uninstalls by properties->> 'extension_version'. That single grouping turns a flat uninstall number into a release-quality monitor: version 4.2 with 3× the uninstall rate of 4.1 is the bug you couldn't see from CWS.

-- Uninstall rate by extension version, last 30 days.
WITH installs AS (
  SELECT properties->>'extension_version' AS version,
         COUNT(DISTINCT anonymous_id) AS install_users
  FROM events
  WHERE project_id = $1 AND event_name = 'ext.installed'
    AND timestamp >= now() - interval '30 days'
  GROUP BY 1
),
uninstalls AS (
  SELECT properties->>'extension_version' AS version,
         COUNT(DISTINCT anonymous_id) AS uninstall_users
  FROM events
  WHERE project_id = $1 AND event_name = 'ext.uninstalled'
    AND timestamp >= now() - interval '30 days'
  GROUP BY 1
)
SELECT
  COALESCE(i.version, u.version) AS version,
  i.install_users,
  u.uninstall_users,
  ROUND(100.0 * u.uninstall_users / NULLIF(i.install_users, 0), 1) AS uninstall_rate_pct
FROM installs i
FULL OUTER JOIN uninstalls u USING (version)
ORDER BY uninstall_rate_pct DESC NULLS LAST;

Problem 5 — multi-profile / multi-device double-counts

CWS counts installs at the Chrome-profile level. One human with work + personal Chrome profiles is two installs in your CWS total. If they sync the extension across devices, it's ambiguous whether they're also two "weekly users" or one — Google doesn't say. The result:

• Install counts are inflated relative to humans, by an amount that varies with your audience (developer-heavy audiences have more profiles per human).
• Weekly users is somewhere between "profiles" and "humans" in a way that can't be predicted.
• Country/language splits inherit the inflation, so a power user in the US who uses three profiles looks like three US users.

Your SDK has the same property at the storage-of-each-profile level — that's correct and documented, per the identity rules in the DAU/MAU guide. The difference is your SDK doesn't pretend to count humans, it counts profiles, and you can name that limitation explicitly in the dashboard.

Problem 6 — no funnel beyond install

The Chrome Web Store sees installs because the install happens on its surface. It never sees what happens after. The single most important post-install metric — what % of installers actually used the extension at least once — is invisible to CWS. So is everything downstream: D1 retention, D7 retention, D30 retention, conversion to paid, feature adoption.

For most extensions, the gap between install and activation is the single biggest churn driver. CWS will tell you 1000 people installed last week. It will not tell you that 420 of them never opened the popup. The methodology is in the CWS conversion rate guide.

What numbers should diverge from your SDK

Once you have a CWS dashboard and your own SDK pipeline, comparing them is a sanity check, not a source of confusion. Here's how each line should differ, and what the gap actually means:

• SDK installs > CWS installs (slightly) — your SDK fires ext.installed on every install event including reinstalls in the same profile within the dedup window. CWS counts net installs (install minus uninstalls). Expected divergence: 2–10%, SDK higher.
• SDK installs < CWS installs — your SDK isn't firing reliably. Almost always the service-worker-died-before-fetch issue from the service worker survival guide, or a schema rejection on the receiving side. Investigate validation logs first.
• SDK uninstalls << CWS uninstalls — by far the most common gap. Users uninstalling without a post-uninstall page or without sendBeacon on the final event don't make it to your SDK. We documented this exact failure mode in the Crxlytics uninstall guide. Fix the snippet, not the analysis.
• SDK weekly active users > CWS weekly users — almost universal. Your "engaged DAU × 7" will be higher than CWS "weekly users" because your definition is stricter and CWS's isn't. Doesn't mean either is wrong.
• SDK country counts ≠ CWS country counts — CWS uses Google's country attribution (likely Google account locale + IP); your SDK uses whatever you implement (probably navigator.language or IP geocode). The gap is usually 5–15%; if it's 50%, one source has a method bug.

A clean SDK-vs-CWS reconciliation page in your dashboard — showing the deltas and what each implies — is a high-value addition that GA4 and PostHog can't build (they don't know about CWS). It's also a strong on-ramp for new Crxlytics users: the first thing they see is "here's what you couldn't see before".

What CWS is still legitimately good for

Not throwing the dashboard away. CWS is the ground truth on a few specific things that your SDK structurally can't provide:

• Total install count. Net of uninstalls, deduplicated at the profile level by Google. Use it as your authoritative number for marketing claims ("10,000 installs").
• Listing impressions. The only signal you have on store-internal discovery (CWS search, category, related). Your SDK can't see this — the user never reaches your code.
• Ratings and reviews. CWS owns this surface; your SDK can't. Watch it daily; it's an early-warning signal for the error patterns covered in error tracking.
• Listing position in search (indirectly, via impression count vs install count). Tracking these over time tells you whether your CWS SEO is working.
• Policy notices and review status. Operational, but the dashboard is the only channel. Don't miss messages.

The split is clean: CWS is your store/marketing source of truth; your SDK is your product/health source of truth. Stop asking either one to do the other's job and the contradictions resolve.

FAQ

Why is my CWS install count different from last week's number?

CWS install count is net of uninstalls. If 100 people installed and 30 uninstalled this week, your headline number went up by 70, not 100. The dashboard also occasionally back-corrects late-counted profiles, so historic numbers can shift by a few percent over a few days.

Why does CWS show fewer users than my SDK reports?

Usually because CWS "weekly users" is stricter than whatever you've defined as "active" in your SDK — likely Google requires a signed-in profile, while your heartbeat fires regardless. The opposite gap (CWS higher than SDK) means your SDK is dropping events. Patterns for reliable delivery are in the metrics tracking guide.

Can I trust the country breakdown on CWS?

For broad strokes, yes. For long-tail country signals (anything with <5% share), Google's bucketing has known noise from VPNs and multi-locale accounts. If a small-share country suddenly moves 50%, suspect the methodology before celebrating a marketing win.

Do reviews affect install-count timing?

Not directly. Reviews update on the dashboard within hours; installs lag 2–3 days. If your install count starts dropping the same day a 1-star review appeared, the review caught up first and the install dip is the reaction to whichever bug the review described — which means the bug existed and was churning users before the review.

Why doesn't Google publish what "weekly users" means?

Unknown. The most generous reading is that the definition has changed enough times that committing to one would invalidate historic comparisons; the less generous one is that it's operationally cheaper to keep the definition opaque. Either way, treat it as a trend signal only and define your own DAU.

When should I trust CWS over my own SDK?

Two cases: (1) reporting total install count in marketing material — CWS is the canonical number; (2) anything about listing impressions or ratings — your SDK can't see those surfaces. For everything else (DAU, MAU, retention, churn, version splits, funnel, attribution), trust your SDK once you've verified delivery.

Does GA4 fix any of this?

No. GA4 in an extension is, separately, a difficult fit (see GA4 in a Chrome extension), and even when you force it to work, the problems above are about CWS data, not your own. GA4 sits on the same product/health side as your SDK; the CWS gap is structural and unfixable from anywhere downstream.