Moderok

Blog

Chrome Web Store Weekly Users vs. Installs: Why They Don't Match

Moderok team

What Chrome Web Store Weekly Users and Installs actually count, why Weekly Users is not installs minus uninstalls, and which number to trust.

Chrome Web Store's developer dashboard shows two numbers that new extension developers expect to line up and never do: Installs and Weekly Users. They don't match because they count different things. Installs counts install requests. Weekly Users counts Chrome browsers that loaded your extension in the last seven days. Neither one is "how many people use my extension," and Weekly Users is not Installs minus Uninstalls. If your Weekly Users runs higher than your net installs, or lower, that is expected, and this post explains exactly why so you stop trying to reconcile two numbers that were never meant to be equal.

What "Installs" actually counts

Chrome defines the Installs metric as the number of install requests from Chrome users. That bundle includes successful installs, failed installs, and installs whose outcome the store recorded as unknown. Two consequences fall out of that definition:

  • It is a count of events, not people. One request equals one increment. If the same person triggers two install requests, that is two installs.
  • It is a flow, not a stock. The daily Installs bar tells you how many install requests happened in a window, not how many copies of your extension are currently installed and enabled somewhere. There is no "currently installed" total on that chart; you are looking at throughput.

You cannot add up the daily install bars and call the sum "my user base": it ignores everyone who has since removed the extension, and double-counts people who installed more than once.

What "Weekly Users" actually counts

Weekly Users is a rolling seven-day count of the number of Chrome browsers that loaded your extension at least once in that window. Three things follow from that definition:

  • It is keyed on the browser profile, not on the person and not on an install request.
  • It is a presence-and-load signal, not a usage signal. A browser counts if it loaded your extension during the window, whether the extension was enabled, disabled, or in an unknown state. Loading is not the same as the user opening or interacting with your extension, so "Weekly Users" is not a count of people who actively used it. A profile that never ran Chrome during the window does not show up at all.
  • It is a windowed count, not a cumulative total. It moves up and down week to week as browsers come and go, independent of your install and uninstall bars.

So Installs answers "how many install requests came in?" and Weekly Users answers "how many browsers loaded the extension recently?" Those are genuinely different questions, which is the root of the mismatch.

Weekly Users is not Installs minus Uninstalls

The tempting mental model is: current users = total installs minus total uninstalls. It does not hold, and the reason is structural rather than a rounding quirk.

Installs are counted per install request. Uninstalls and Weekly Users are counted per browser. When you subtract total uninstalls from total installs, you are subtracting two quantities measured against different denominators, then comparing the result to a third quantity (Weekly Users) measured against yet another. There is no arithmetic that makes those three reconcile, because they are not three views of one underlying number. They are three different measurements.

This is the mirror image of a problem that shows up on the churn side too. Chrome's uninstall signal undercounts for its own structural reasons, which is worth understanding if you care about retention; see how to track Chrome extension uninstalls with setUninstallURL for why raw uninstall counts always run low.

Chrome Sync: one install, several weekly users

The single biggest driver of divergence is Chrome's account sync. When a user is signed into Chrome with sync enabled, installing your extension on one machine propagates it to every other browser signed into that same Google account. That is still one install request. But if the user then opens the extension on their laptop, their desktop, and their work machine during the same seven-day window, that is three Weekly Users.

This is why Weekly Users can legitimately exceed your net installs. A single human with three synced machines is one install and up to three weekly users. Scale that across a synced user base and the two numbers pull apart in a direction that looks alarming until you know the mechanism. It is not inflation or a bug; it is sync doing exactly what it is designed to do, measured by a metric that counts browsers.

Sync cuts the other way too. A browser only contributes to Weekly Users if it actually loaded your extension during the window, so a synced machine that was switched off all week does not count, even though the extension is technically installed on it. Weekly Users is bounded by which browsers ran, not by how many browsers have the extension.

The dashboard is not real-time

Both numbers lag. The Chrome Web Store developer dashboard refreshes on its own schedule rather than live, and the figures you see trail actual activity by some amount. Practically, that means comparing "today" in the store dashboard against anything you measured in real time will always show a gap that is pure latency, nothing to do with the definitions above.

The dashboard also buckets days on its own clock and rounds aggressively for small extensions. The safe move when you are trying to line numbers up is to compare over weekly or longer windows, never single days, so day-boundary and timezone offsets wash out.

Which number should you trust?

It depends on the question:

  • "Am I growing?" Either series works directionally. Watch the trend, not the absolute value.
  • "Roughly how many people use my extension right now?" Weekly Users is the closest official proxy, as long as you hold the caveats in mind: sync can inflate it (one person, several browsers), and a browser that did not run during the window drops out of it entirely.
  • "How many new installs did my launch drive?" The daily Installs bar is the right series, read as install requests over time rather than net-new humans.

What none of these give you is a queryable, real-time active-user number you can slice by browser, OS, or version. The store simply does not expose that.

Getting an active-user number you own

If you want a weekly-active count you control, you have to instrument it yourself, because the store will only ever hand you these two aggregate numbers with no breakdowns and no real-time view.

The Moderok SDK sends a __daily_ping event at most once per UTC day from each installation, fired after the service worker starts up. Count the distinct anonymous users who sent a __daily_ping in a rolling seven-day window and you get a weekly-active number computed the same way every day, yours to query and broken down by OS, browser, and extension version, without the store's reporting lag.

This number counts a different denominator than Weekly Users, on purpose. The SDK stores its anonymous id in chrome.storage.local and mirrors it to chrome.storage.sync, so a user signed into Chrome on several machines shares one id across those synced browsers. Counting distinct users therefore collapses one person's synced machines into a single weekly-active, the exact opposite of what per-browser Weekly Users does. Expect Moderok's distinct-user count to run lower than Weekly Users for a heavily synced audience: it counts people, not browsers. (With Chrome Sync off there is nothing to share the id across, so each profile counts on its own, as Weekly Users would.)

That is the point. Weekly Users answers "how many browsers loaded my extension." A distinct-user count of __daily_ping answers "how many anonymous users were active," which is usually the number you actually wanted, sliced by OS, browser, and version so you can ask "how many active users on Firefox?" instead of squinting at two aggregate bars.

The SDK ships this ping automatically the moment you call Moderok.init() in your background service worker, alongside __install, __first_open, and __update lifecycle events. You do not add host_permissions and you do not write any of the plumbing. If the gap between the store's numbers and reality has been bothering you, the fix is not to reconcile Installs and Weekly Users. It is to measure the thing you actually care about directly.