Analytics for browser extensions
Do you know how many of your users actually pinned your extension?
The Chrome Web Store won’t tell you. Neither will Google Analytics. One SDK call gives you pin rate, permission declines, uninstall reasons and release impact — from the day you ship.
SDK 0.6 · MV3-ready · Remote modules · Chrome / Firefox / Edge / Safari
Events stream over SSE when the public demo is active
The difference
Four numbers nobody else can give you.
Mixpanel, Amplitude and PostHog are excellent at web products. None of them knows what a toolbar is. The figures below are live from the public demo.
Pin rate
21%
1,364 of 6,516 known toolbar states
Is your icon still on the toolbar?
Chrome reports whether each user kept your extension visible. An extension nobody can see is an extension nobody opens — and no store dashboard exposes this.
Permission declines
—
no permission prompt in the last 7 days
Who said no to the prompt?
Optional permissions are where activation quietly dies. You see requested, granted, declined and revoked — not just the users who made it through.
Uninstall reasons
Not working
14 of 29 answered uninstalls
Why did they actually leave?
The uninstall opens a feedback page in the user's language. Seven reasons, one optional comment, landing next to your churn numbers.
Release impact
5%
v1.1.8 share of the observed base
What did this version change?
Adoption, update lag and churn per version, so a regression shows up as a shape in the data instead of a one-star review three weeks later.
Why extensions are different
You ship, then wait days to find out what happened.
Web teams deploy in five minutes and roll back in one. You submit a build, wait for review, then watch it reach users gradually — with no way to hotfix. Every analytics tool on the market was designed for the first world.
Store dashboard only
Day 0
You submit the release
The build leaves your machine. Nothing about it is observable yet.
Day 1–5
Store review
You cannot ship a fix, and you cannot see who received what.
Day 5+
Gradual rollout
Some users are on the new build, some are not. The store shows one rounded weekly number for both.
Week 3
A one-star review
That is your regression report. You still do not know which version, which browser, or how many users.
With extension.report
Hour 1
The version appears
First installations report the new version. Adoption starts as a curve, not a guess.
Hour 6
Behaviour is comparable
Pin rate, open rate and permission outcomes for the new version sit next to the previous one.
Day 1
A regression has a shape
Errors group by version. Uninstalls carry reasons. The affected population is a list you can open.
Any moment
You act without republishing
Remote config reduces telemetry modules, targets compatible clients, caps traffic or stops collection — no second review.
The last step matters most. Because a fix takes days to reach users, the only thing that can act immediately is configuration the SDK fetches at runtime. See how remote modules work.
The gap
Store dashboards stop before the product work starts.
The store can tell you a rough audience number. It cannot tell you which release hurt retention, which browser keeps users, or what people say when they uninstall.
One SDK, one install base, broken down across Chrome, Edge, Firefox and Safari.
The product
Follow the full extension lifecycle.
Sample data — the public demo is warming up.
Micro → macro
Every metric opens the people behind it
Start with the signal. Open its exact population, inspect a real installation, then follow milestones and source events without rebuilding the query.
Retention
Find the versions and markets that keep users
Read retention curves, version adoption, update paths and country breakdowns in one place. When a release changes behavior, the dashboard should make it obvious.
Churn
Turn uninstalls into product feedback
When someone uninstalls, a feedback page opens in their language and asks why — seven reasons, one optional comment. Pair that with observed churn and heartbeat silence.
Integration
Wired in one call.
Initialize the SDK once and it tracks lifecycle, active usage, toolbar state, permissions, context menus, shortcuts, omnibox, and notification engagement when those browser APIs are present. Add explicit product events only where they matter. Adoption, Engagement, and Reliability remain remotely adjustable as coherent groups.
Chrome
Firefox
Edge
Safariimport { initExtensionReport } from "@extension-report/js";
// initialize lifecycle and automatic extension signals
const sdk = initExtensionReport({ projectPublicKey: "pk_er_..." });
// optional: track specific UI or configuration moments
await sdk.popup.opened();
await sdk.trackCustomEvent("settings_saved");SDK permissions are lightweight: "storage", "alarms", and your extension.report host permission. Feature permissions stay tied to the features your extension already uses.
Need server-side exports? Owner Stats API is available on plans with API access.
Pricing
Start with evidence. Scale with usage.
No trial clock and no invitation. Every plan uses the same owner-first telemetry pipeline; paid plans add capacity, history, and automation.
Prices exclude applicable taxes. You can change or cancel a paid plan from your workspace once billing is enabled.
Questions
Asked, answered.
Will this get my extension rejected from the store?
The SDK collects a random installation ID and coarse context (browser, OS, version) — no cookies, no browsing history, no personal data. Country is derived from the IP at ingestion and the IP isn't stored. You disclose the telemetry in your privacy policy like any analytics, and you stay well inside Chrome Web Store and AMO data policies.
How accurate is uninstall tracking?
Honest answer: it's best-effort, like everything built on setUninstallURL — some uninstall pages never open. That's why the dashboard pairs observed uninstalls with churn estimated from heartbeat silence, so the trend is reliable even when individual events are missed.
How do I learn why users uninstall?
The moment an uninstall happens, the browser opens your feedback page — localized in six languages — asking one question: why? Seven reasons, one optional comment. Reasons and quotes land on your report next to the churn numbers. No store dashboard does this.
Does it survive MV3 service workers going to sleep?
Yes — it was designed for that. Events queue persistently in storage.local, ship in batches with retry and exponential backoff, and heartbeats piggyback on alarms or the next wake. A worker being killed mid-flight loses nothing.
Which browsers are supported?
Chromium (Chrome, Edge, Brave, Arc…), Firefox, and Safari WebExtensions. One dashboard, one install base, broken down by browser, version and country.
What happens if my extension suddenly takes off?
Remote config is fetched by the SDK, so you can reduce Adoption, Engagement, or Reliability as coherent groups, roll changes out progressively, target compatible clients, cap noisy traffic, or stop telemetry entirely — without waiting for another store review.
I already use PostHog / Amplitude / Mixpanel. Why a second tool?
Because they cannot see the four things on this page. They are excellent at products that live in a page — but a toolbar pin, a permission prompt, an uninstall and a store rollout are not web events with different names, they are platform primitives their SDKs never receive. Most teams keep their product analytics for the web app and use extension.report for the extension.