Chrome extension analytics starts with a mismatch: the number Chrome puts in front of you is install count, and install count is close to the least useful number for deciding what to build next. The Web Store dashboard will tell you installs, weekly users, and uninstalls. It will not tell you why someone left, whether the people who stayed are actually opening your extension, or which feature made them stick around. Those numbers only exist if you go get them yourself.
This is a practical guide to doing that: what the dashboard gives you for free, the five metrics worth instrumenting, where to fire the events, and how to close the loop between "someone left" and "why."
What the Web Store dashboard gives you
Start with what's already there, because it's a real foundation and there's no reason to duplicate it.
- Installs and uninstalls — raw daily counts. No breakdown by cohort, no reasons attached.
- Weekly users — the count of installs that are still active as of that week, segmented by country, language, OS, and version. This is Chrome's closest thing to an active-user metric, and it's coarser than it sounds — more on that below.
- Impressions and listing conversion — if you opt your listing into Google Analytics 4, you get
page_view,session_start, and similar events for the store page itself, which lets you see how many people who viewed your listing actually installed. - Ratings and reviews — your public star rating and the text behind it.
That's a decent read on acquisition: how people find you and whether they install. It's a blank on everything after. Two blind spots do the most damage:
"Weekly users" isn't daily-active, and it isn't engagement. Chrome reports on a weekly cadence and counts an install as a "user" if it's still present and technically running — not if anyone opened it, clicked anything, or got value. An install that's sat forgotten for two months counts identically to someone who uses your extension ten times a day. You cannot tell them apart from the dashboard.
Uninstalls come with no reason attached. Chrome shows you the count that left. It does not show you a single word about why. That gap is the subject of its own section below, because it's the one most worth fixing first.
The metrics that matter
Five numbers cover most of what you actually need to know, and none of them come from Chrome. You have to fire the events yourself.
Install → activation rate. The percentage of new installs that complete the first meaningful action — not "opened the popup," but the thing that proves your extension did what they installed it for. A tab manager's activation event might be "grouped their first set of tabs"; a transcript exporter's might be "exported one transcript." It's the single best predictor of whether an install becomes a real user, because it measures intent meeting outcome, not just presence. There's no universal benchmark worth quoting — measure your own baseline first, then work to raise it by shortening the distance between install and that first win.
DAU/WAU (stickiness ratio). Daily active users divided by weekly active users. Near 1 means people who use you in a given week use you almost every day — high habitual engagement. As a rough illustration, a ratio down around 0.15–0.2 would suggest people dip in occasionally rather than daily — which could be fine for a narrow-utility extension (a screenshot tool, say) and a problem for a daily-habit one. There's no universal benchmark here either — the number only means something relative to what your extension is for, so track your own trend over time rather than a cited norm.
Uninstall rate. Uninstalls divided by installs over a comparable window — the one metric here you can compute from Chrome's raw numbers alone, just not pre-calculated for you. Treat it as a lagging indicator: by the time someone uninstalls, whatever went wrong already happened. Useful for tracking trend release over release, nearly useless for telling you what to fix — which is why it needs to be paired with reasons, covered next.
Week-1 retention. The share of an install cohort still active seven days after install. Extension retention differs from mobile apps here: install friction is much lower, so a meaningful chunk of any cohort was never strongly intentional to begin with, and week one is where that shakes out. Track it as a cohort metric over time — did this month's cohort retain better than last month's — rather than chasing a single external benchmark.
Feature usage. Which parts of your extension people actually touch, tracked as events per feature per active user. This is the metric most developers skip, and the one that saves the most wasted engineering time — it tells you which features are load-bearing and which are dead weight, so roadmap decisions stop being guided by the loudest reviewer instead of the median user.
Instrumenting your extension
None of the five metrics above exist until you fire events yourself. A few things worth getting right:
Where events fire. In Manifest V3, your persistent logic lives in a background service worker, which Chrome spins down when idle and wakes on demand — it's not a long-lived process, so batch events locally and flush them on a timer rather than assuming a connection stays open. Content scripts (code injected into pages) can fire events for in-page interactions too, but route them through the background worker or your extension's own pages rather than straight from a content script to a third-party endpoint — cleaner permissions model, one event pipeline.
Ad blockers mostly don't touch this. A common worry is that analytics get silently dropped the way they do on web pages with an ad blocker installed. Events fired from your extension's own pages and background context aren't running through a page's ad-blocked network stack the way a third-party tracking pixel is — capture from your own extension surfaces is close to complete. Worth knowing so you don't over-correct for data loss that mostly isn't happening.
GA4 on the listing is separate from in-extension analytics. Opting your Web Store listing page into Google Analytics 4 gives you funnel data for the page itself — impressions to installs. It tells you nothing about what happens after install. Treat it as the acquisition half and build activation/retention yourself.
Be transparent, and keep it light. Extension users are reasonably wary of tracking, and rightly so — you're often running with broad permissions. Aggregate events, avoid anything that fingerprints an individual, and say plainly in your privacy policy what you collect and why. A handful of well-chosen events — install, activation, a couple of core-feature triggers, a daily heartbeat — covers all five metrics above without a heavy analytics stack.
Why users leave (the metric behind the metric)
Uninstall rate tells you the scale of the problem. It never tells you the cause. Two extensions can have an identical uninstall rate for completely different reasons — one losing people to a bug, the other to a missing feature — and the number alone can't distinguish them.
Chrome gives you exactly one hook to reach someone in the moment they leave: chrome.runtime.setUninstallURL(). Call it in your background script and Chrome opens that URL the instant someone uninstalls — your one chance to ask why before they're gone for good. We cover the implementation in detail in the setUninstallURL tutorial, and the reasoning behind why this single API is worth wiring up before almost anything else is in the guide to reducing extension churn.
Point that URL at a short, structured form — a handful of one-click reasons (bug, missing feature, too slow, found an alternative, no longer needed) plus an optional text field — and uninstall rate stops being a dead-end number. It becomes a categorized breakdown you can prioritize against: fix the bugs cited most often, weigh the missing-feature requests against your roadmap, and stop guessing at what a lagging metric can't tell you on its own. We go deeper into the other blind spots the dashboard leaves — usage, feature demand, in-extension behavior — in the four analytics blind spots if you want the fuller picture beyond uninstalls specifically.
Turning numbers into decisions
None of this is worth collecting unless it changes what you build next. A rough loop that works:
- Activation rate low? Look at what stands between install and first value. Shorten it.
- DAU/WAU low relative to what your extension should be? Check feature usage — are people finding the habitual-use feature, or missing it entirely?
- Week-1 retention weak on recent cohorts? Cross-reference with uninstall reasons from the same period — a bug shipped in that window is a common culprit.
- Uninstall rate trending up? Pull the categorized reasons and triage by volume, not by whichever complaint is loudest.
This loop also feeds back into your Web Store listing itself — a lower uninstall rate is a ranking signal the store measures directly, so fixing the product problems this data surfaces pays off in discovery too, not just retention. We cover that side of the loop in the Chrome Web Store optimization guide.
The dashboard will always show you the outcome — installs, uninstalls, weekly counts. Everything upstream of the outcome — activation, engagement, and the reasons behind the losses — only exists if you build it. UserFeed is built specifically for extension developers who want the uninstall-reasons and feature-demand side of this without wiring it up from scratch, but whatever tools you use, the principle is the same: install count is a vanity number until you can explain the numbers behind it.
Last updated: August 2026