Skip to content

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

6 min readModerok 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.

The dashboard does slice some of this: the Weekly Users page breaks retention out by country, language, operating system, and item version. What it does not give you is a queryable, real-time active-user number, because those stats count installations rather than activity.

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's breakdowns still count installations, delivered on its reporting schedule rather than on demand.

After the service worker starts, the Moderok SDK sends a __daily_ping when its stored UTC date says that analytics profile has not emitted one that day. The profile id and date can be recovered through browser sync, so this is a deduplicated analytics-profile heartbeat, not a guaranteed once-per-installation counter. Count the distinct profile ids that sent a __daily_ping in a rolling seven-day window and you get a weekly-active profile measure computed under one consistent rule.

This number counts a different denominator than Weekly Users, on purpose. Moderok keys activity to its random profile id, while the Web Store metric counts browsers that loaded the extension. Treat Moderok's result as a consistent anonymous-profile metric, not a claim about unique people.

That is the point. Weekly Users answers "how many browsers loaded my extension." A distinct-profile count of __daily_ping answers "how many analytics profiles were active under this rule." It is not a count of unique people or devices, and browser sync can allow the same profile id to appear on more than one device. Moderok's current dashboard shows the aggregate active-profile trend; browser, OS, and extension version remain available in raw event context rather than as chart breakdowns.

After installing the SDK and adding the storage permission, calling Moderok.init() in your background service worker enables this ping alongside __install, __first_open, and __update lifecycle events. You do not add host_permissions or build the reporting pipeline yourself. 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.