Moderok SDK

Appearance

Why your Moderok install count differs from Chrome Web Store ​

Your Moderok dashboard and Chrome Web Store's developer dashboard almost never show the exact same install number, even after Moderok's filters are applied. This page explains where the remaining gap comes from and which number to trust.

TL;DR ​

  • Moderok's Installs metric is already filtered to strip ephemeral Chromebook phantoms — there's no "raw" install view in the UI, because the raw number is not a useful metric.
  • Moderok will still typically run ~1.5–2× higher than Chrome Web Store, for reasons that are inherent to how the two systems define and measure "an install."
  • Use Moderok's number for directional movement (up/down tracks with CWS), not as an exact match to CWS.

What Moderok counts ​

Moderok records an __install event whenever Chrome's extension runtime fires chrome.runtime.onInstalled with reason: "install". Each event is tied to a per-user anonymous id that the SDK stores in chrome.storage.local (and mirrors to chrome.storage.sync since version 0.1.1).

The dashboard's Installs metric strips one class of noise before showing you the number: ephemeral Chromebook profile phantoms, explained below. Everything else is passed through unchanged.

What Chrome Web Store counts ​

Chrome Web Store's developer dashboard has three related views:

  • Installs & Uninstalls — daily bars of new installs and removals, aggregated from the store.
  • Weekly Users — a rolling 7-day count of users who had the extension installed and opened Chrome in that window. This is not a count of installs; it's an activity proxy.
  • Impressions — how often your listing was shown in the store.

Google doesn't publicly document how CWS dedupes across profiles, devices, or accounts. The community consensus on the Chromium extensions group is that the methodology is intentionally opaque. What is documented: CWS data is delayed at least two days and refreshes once per day.

The ephemeral Chromebook problem, and how Moderok filters it ​

School-managed Chromebooks can be configured in ephemeral mode, which wipes the user's Chrome profile — including every extension's chrome.storage.local — at logout. When the student signs in the next morning, Chrome re-syncs the extension onto a fresh profile and fires chrome.runtime.onInstalled with reason: "install" again. The SDK has no way to tell this apart from a genuinely new install, so it records a new event with a new anonymous user id.

The same physical student on the same physical Chromebook can generate dozens of __install events over a single school term — one per school day, effectively. And because Chrome's uninstall URL mechanism only fires on user-initiated removes, the profile wipe at logout generates no offsetting __uninstall — so the phantom installs accumulate unbounded.

How Moderok strips them ​

The Installs query filters out any ChromeOS user id that:

  1. Fired at least one __install event, AND
  2. Only ever shows activity on a single UTC day (i.e., never returned).

This signature catches roughly 94% of ephemeral Chromebook phantoms while removing 0% of Windows, Mac, or Linux installs. The filter has a 1-day latency on ChromeOS only: a ChromeOS user who installs today is not counted until they return tomorrow. Windows, Mac, and Linux installs are counted in real time. This is why "today" on the Installs chart has immediate data for desktop platforms but a small delay for ChromeOS specifically.

Net churn and the tenure-panel retention rate apply the same filter under the hood. Tenure histograms are naturally unaffected — they only count users who fired both install and uninstall events, and phantoms never uninstall.

Why the filtered number is still higher than Chrome Web Store ​

Even after stripping phantoms, Moderok typically reports 1.5–2× what CWS shows for the same extension and window. The remaining gap has four contributing factors, in rough order of impact:

1. CWS reporting delay (~2 days) ​

CWS install and user data is at least two days behind real time. If you compare "Moderok today" to "CWS today," you're comparing a live number to a snapshot that doesn't include the last two days of activity. For an extension adding ~100 installs/day, that's already a ~200-install gap baked in.

What to do: When comparing, offset your Moderok window by two days. Look at Moderok's number for "two days ago, back N days" instead of "today, back N days."

2. Multi-profile Chrome users ​

A single person with three Chrome profiles on one laptop (work + personal + guest) generates three __install events and three user ids in Moderok. Chrome Sync persists the Moderok user id across profiles if it's enabled, but many users don't sign into every profile, and Chrome Sync can be disabled or scoped. Google doesn't disclose whether CWS collapses these into one user — the answer is probably "yes, sometimes" but the rules are opaque.

What to do: Nothing on the dashboard side — there's no reliable way to dedupe profiles on the same device without identifiers the SDK doesn't collect. The good news: on Chromebooks where ephemeral mode is off, this is already close to correct because most Chromebook users are on a single profile.

3. Chrome repair reinstalls ​

When Chrome detects a corrupted extension — failed signature check, malformed manifest, damaged storage — it silently re-downloads and re-installs the extension. This fires chrome.runtime.onInstalled with reason: "install", which Moderok records as a new install. It's unclear whether CWS counts these the same way.

What to do: Nothing. The events are indistinguishable from real installs without additional signals Chrome doesn't expose.

4. UTC vs. Pacific Time day boundaries ​

Moderok buckets days in UTC. CWS buckets days in Pacific Time. When you're comparing "today's installs" in each, you're comparing two 24-hour windows that are shifted by 7–8 hours. For extensions with steady traffic, this doesn't much matter over longer periods, but for single-day or single-hour comparisons the mismatch can be real.

What to do: Compare weekly or longer windows when aligning against CWS. Avoid same-day comparisons.

What's not on the list ​

Two common explanations that I initially thought were factors but turn out not to be:

  • "Edge users inflate Moderok" — no. Almost all Edge users of a Chrome-Web-Store-only extension install it by visiting chromewebstore.google.com in Edge and clicking "Add to Chrome." That flow goes through the Chrome Web Store, so CWS records the install too. Unless users are sideloading .crx files manually (extremely rare), Edge users show up in both counts.
  • "CWS rounds aggressively" — only true for very small extensions (under a few hundred users). For extensions in the thousands, CWS daily install bars are exact integers.

Which number should you trust? ​

For directional signals — "is my install rate going up?", "did the blog post drive traffic?", "is my new version converting better?" — Moderok is strictly better than CWS because it's real-time, queryable, and broken down by OS/browser/version.

For absolute numbers — "how many users do I have?" — CWS's Weekly Users is the closest thing to ground truth, even though it's lagged and its methodology is opaque. Moderok's Installs metric is counting a different thing (new install events in a window, filtered for ephemeral phantoms), not "current installed base."

If Moderok's Installs is consistently ~1.5–2× CWS, that's normal. If it's 5× or more, something unusual is happening — contact support with your app key and we'll look.

Moderok: analytics for browser extensions