Chrome extension analytics tools compared: store dashboards, product analytics and public store data

"Which analytics tool should I use for my Chrome extension?" is one of the oldest questions in extension development. A Hacker News thread asking for the best tool for Chrome extension analytics dates back to 2015, and developers still ask it in every community. The reason it never gets a clean answer is that "Chrome extension analytics tools" covers three different jobs: counting installs and users in the store, measuring what people do inside the extension, and watching the public side of the store, including competitors. No single tool does all three.

This guide compares the options for each job: the store's own dashboards, the product analytics tools developers use most (Google Analytics 4, PostHog, Mixpanel, Amplitude, Plausible and Umami), and public store data trackers. It covers free tiers as listed on each vendor's pricing page in October 2026, what changes under Manifest V3, and a small vendor-neutral event queue that lets you switch tools without shipping a new version.

Key takeaways

• Extension analytics has three layers: store numbers (installs, uninstalls, weekly users), in-extension behavior (events, funnels, retention) and the public view (listing users, ratings, versions, competitors). Each needs a different tool.
• The Chrome Web Store dashboard is free and authoritative for your own installs and users, but it sees nothing inside your extension and nothing about anyone else's.
• Manifest V3 forbids remotely hosted code, and the service worker has no window or DOM. Bundle any SDK, or send events over HTTP from a small queue of your own.
• Free tiers in October 2026: PostHog 1M events a month, Mixpanel 1M, Amplitude 2M, Umami Cloud 100K. GA4 is free. Plausible is paid after a trial, and both Plausible and Umami can be self-hosted.
• Disclose analytics in your privacy practices and privacy policy, and collect only what you need. Firefox now asks users for consent through the manifest.

The three layers of Chrome extension analytics#

Start by deciding which questions you need answered, because each layer answers different ones:

Most small extensions start with the first layer only and add the second when they have a product question that store numbers cannot answer. The third layer is the one most teams forget, even though it is the only one that covers competitors.

What makes analytics in an extension different#

A website drops a script tag in its <head> and is done. An extension cannot, for four reasons:

1. No remote code. Manifest V3 forbids executing code that is not in the package. Chrome's guide to remotely hosted code says a "Blue Argon" rejection usually means the reviewer believes "your extension is using remotely hosted code", typically a script tag pointing at the open web. Analytics snippets that load from a CDN are the classic cause. Install the SDK from npm and bundle it.
2. The service worker is not a page. There is no window, no document and no localStorage in the background service worker, and it shuts down when idle. Browser SDKs that assume a page fail there. Popups, options pages and side panels are pages, but they live for seconds.
3. Several contexts, one user. The popup, the service worker and content scripts each run separately. Without a shared ID kept in chrome.storage, every popup open can look like a new visitor.
4. Privacy rules are stricter. Chrome's user data FAQ says extensions "may collect analytics or performance data where it is reasonably necessary to maintain" the extension, that collection must be proportionate, and that web browsing activity may only be collected "to the extent required for a user-facing feature." You must disclose analytics in the privacy practices section of the dashboard and in a privacy policy. Firefox goes further with data collection consent in the manifest.

Content scripts deserve a special warning. Analytics code running inside a web page sees that page, which is exactly the browsing activity the policies restrict. Send events from your own extension pages or the service worker, not from content scripts, unless the event is about your feature and contains nothing from the page.

Layer 1: the store dashboards#

Every store gives you a free dashboard for your own listings. They are the source of truth for installs and users, because they count what the store actually delivered:

• Chrome Web Store Developer Dashboard. Installs, uninstalls, weekly users and impressions, with breakdowns by country, language and operating system. The Users report can also be grouped by item version, according to Chrome's store listing metrics guide, and every report exports as CSV. Page views are broken down by UTM parameters, and an optional GA4 integration attributes installs to traffic sources. Our guide to Chrome Web Store conversion rate shows how to turn these into a funnel.
• Edge Partner Center. Weekly users, enabled versus disabled, installs and impressions. See Edge add-on analytics.
• addons.mozilla.org statistics. Daily users and downloads, with UTM breakdowns for listing traffic. See Firefox add-on stats.

The limits are the same everywhere. The numbers arrive with a delay, cover only your own listings, and stop at the store's door: you learn that 2,000 people installed, not whether any of them used the feature you built. Weekly users is also a footprint rather than engagement, which is why a drop can be hard to explain. Our post on why Chrome extension weekly users drop walks through the usual causes.

Layer 2: Chrome extension analytics tools compared#

For behavior inside the extension you need a product analytics tool, or your own endpoint. Here is how the common choices compare for an extension in October 2026:

Sources: the pricing pages of PostHog, Mixpanel, Amplitude and Umami, Plausible's self-hosting page, and each tool's API documentation linked below. Free tiers change often, so check them before you commit.

A few notes that the table cannot hold:

• GA4 is free and familiar, but gtag.js is remote code and the Measurement Protocol's API secret should not ship in a package anyone can unzip. Our guide to Google Analytics 4 in a Manifest V3 extension builds the small relay that solves both.
• PostHog, Mixpanel and Amplitude are full product analytics suites: funnels, retention curves, cohorts and, for PostHog, feature flags and session replay. Their project tokens are designed to be public, so a bundled SDK in your popup or options page is fine. In the service worker, use their HTTP APIs, such as Amplitude's HTTP V2 API or Mixpanel's ingestion API.
• Plausible and Umami are privacy-first counters, closer to "how many people opened the side panel today" than to cohort analysis. Both identify visitors partly from the User-Agent. Plausible's Events API marks User-Agent as required and warns that the API "always returns HTTP 202 Accepted, even when an event is dropped," so verify in the dashboard that events arrive. Umami's /api/send needs no token but rejects requests without a proper User-Agent.
• Error tracking is a separate tool. Exceptions from the service worker and content scripts belong in an error tracker, not in your product analytics, so keep the two apart and keep the event volume of each predictable.

How to choose#

• Solo developer, one extension: the store dashboard plus one free tier is plenty. Pick PostHog, Mixpanel or Amplitude if you want funnels and retention, Umami or Plausible if you only want counts.
• You already live in Google's tools: GA4 through a relay, and the store's GA4 integration for listing traffic.
• Strict privacy promise or EU-only data: self-hosted Plausible Community Edition or Umami, or your own endpoint.
• You are not sure yet: send events to your own endpoint first, as shown next, and decide later.

A vendor-neutral event queue for Manifest V3#

The most flexible setup is to keep the analytics vendor out of the package entirely. The extension queues events in chrome.storage, flushes them to a small endpoint you control, and that endpoint forwards them to whichever tool you use. You can switch tools, fix a broken API key or drop an event without a store review, and no third-party code runs in the extension. This is the whole client side:

// analytics.js (service worker module): a small event queue for Manifest V3 that sends to your own relay.
const ENDPOINT = 'https://telemetry.example.com/v1/events'; // your relay, never an analytics API key
const FLUSH = 'analytics-flush';

async function clientId() {
  const { cid } = await chrome.storage.local.get('cid');
  if (cid) return cid;
  const id = crypto.randomUUID(); // random, per install, not tied to a person
  await chrome.storage.local.set({ cid: id });
  return id;
}

export async function track(name, props = {}) {
  const { queue = [] } = await chrome.storage.local.get('queue');
  queue.push({ name, props, version: chrome.runtime.getManifest().version, ts: Date.now() });
  await chrome.storage.local.set({ queue: queue.slice(-500) }); // cap the backlog when offline
}

async function flush() {
  const today = new Date().toISOString().slice(0, 10);
  const { lastActive } = await chrome.storage.local.get('lastActive');
  if (lastActive !== today) {
    await track('active_day');
    await chrome.storage.local.set({ lastActive: today });
  }

  const { queue = [] } = await chrome.storage.local.get('queue');
  if (queue.length === 0) return;
  try {
    const res = await fetch(ENDPOINT, {
      method: 'POST',
      headers: { 'content-type': 'application/json' },
      body: JSON.stringify({ cid: await clientId(), events: queue }),
    });
    if (!res.ok) return; // keep the queue, retry on the next alarm
    const { queue: current = [] } = await chrome.storage.local.get('queue');
    await chrome.storage.local.set({ queue: current.slice(queue.length) }); // keep events added meanwhile
  } catch {
    // offline: retry on the next alarm
  }
}

chrome.runtime.onInstalled.addListener(({ reason, previousVersion }) => {
  if (reason === 'install') track('install');
  if (reason === 'update') track('update', { from: previousVersion });
});

// Alarms can be cleared on browser restart, so check on every service worker start.
async function ensureAlarm() {
  if (!(await chrome.alarms.get(FLUSH))) await chrome.alarms.create(FLUSH, { periodInMinutes: 30 });
}
ensureAlarm();

chrome.alarms.onAlarm.addListener((alarm) => {
  if (alarm.name === FLUSH) flush();
});

// Popup, options page and side panel: chrome.runtime.sendMessage({ type: 'track', name, props })
chrome.runtime.onMessage.addListener((message) => {
  if (message?.type === 'track') track(message.name, message.props);
});

It needs the storage and alarms permissions, neither of which shows a warning at install. Pages such as the popup send events to the service worker with chrome.runtime.sendMessage, as in the last listener, so there is one queue and one ID. The active_day event gives you daily active installs with nothing more than a random install ID, which is all a retention and uninstall analysis needs. The alarms API reference explains why the alarm is checked on every start: Chrome may clear alarms when the browser restarts. The queue does a read-modify-write on each call, which is fine at a few events per minute; batch in memory first if you send more.

What to send, and what not to:

• Send: install, update (with the previous version), daily active, the handful of feature events that answer a real question, and coarse properties such as extension version and browser.
• Do not send: URLs, page titles, page content, search terms, keystrokes or anything typed into a form. If a question seems to need these, it is a browsing activity question, and the policies above apply.

The relay is a few lines on any server or edge function: validate the payload, drop unknown event names, add the server time and forward to the tool's HTTP API with the key kept server-side. Because it runs on your side, it is also where you rate-limit and filter bots.

Layer 3: public store data and competitors#

The store dashboards show your own numbers, and in-extension analytics shows your own users. Neither tells you what the market sees: the user count and rating on your public listing, how they move day to day, the version each store is serving, and the same for every competitor. That data is public, but no store keeps its history for you. Our guide to the Chrome Web Store stats API explains what you can collect yourself, and the Chrome extension version history guide does the same for releases and permission changes.

This is the layer Extenify covers. The Chrome extension analytics dashboard records users, ratings, reviews, versions and category rank for any Chrome Web Store, Edge Add-ons or Firefox Add-ons listing every day, merges the same extension across stores, and sends a daily alert to email, Slack, Telegram, Discord or Teams when something moves past a threshold you set. It needs no SDK and no access to your accounts, so it works for competitors as well as your own extensions, and it complements the two layers above rather than replacing them. Tracking one extension is free; the Extenify pricing page lists the plans with more tracked extensions, longer history and CSV export. Reviews are part of the same picture: our guide to app review analysis with an LLM shows how to turn them into numbers too.

A setup that fits most extensions#

1. Day one: read the store dashboards weekly and track your public listing daily, so history starts before you need it.
2. First product question: add the event queue above and one tool's free tier. Track five to ten events, not everything.
3. First retention question: add the active_day event and read retention by install week.
4. First competitor question: add their listings to the same public data tracker you use for your own.
5. Every release: compare the store's users by version, your error and feature events, and the public rating in the same week.

Frequently asked questions#

What is the best analytics tool for a Chrome extension?#

There is no single best tool, because extension analytics has three layers. Use the Chrome Web Store dashboard for installs and users, a product analytics tool such as PostHog, Mixpanel, Amplitude, Umami or Plausible for in-extension behavior, and a public store data tracker for your listing's trends and competitors. For a solo developer, the dashboard plus one free tier is enough.

Can I use Google Analytics in a Chrome extension?#

Yes, through the GA4 Measurement Protocol rather than gtag.js, which Manifest V3 treats as remotely hosted code. Keep the Measurement Protocol API secret on a small server that forwards events, so it is not exposed in your package.

Does the Chrome Web Store provide analytics?#

Yes, for your own items. The Developer Dashboard shows installs, uninstalls, weekly users, impressions and page views, with breakdowns by country, language, operating system and, for users, item version. Every report exports as CSV. It does not show what users do inside the extension.

Do I need user consent to use analytics in a Chrome extension?#

You must disclose analytics in the dashboard's privacy practices and in a privacy policy, and keep collection proportionate. Chrome's policies require a prominent disclosure and consent in specific cases, especially for data not closely related to your extension's function. Firefox asks users for consent based on the data_collection_permissions manifest key. Collecting browsing activity for analytics is not allowed on Chrome.

Can I see analytics for someone else's Chrome extension?#

Not their private dashboard. You can see the public numbers on their listing (rounded users, rating, rating count, version and last update) and record them daily to build a trend. Firefox publishes more through the addons.mozilla.org API, including average daily users.

Summary#

Choosing Chrome extension analytics tools starts with the question you need to answer. Store dashboards are free and authoritative for installs and users of your own listings. Product analytics tools such as GA4, PostHog, Mixpanel, Amplitude, Plausible and Umami measure behavior inside the extension, as long as you bundle the SDK, avoid the service worker's missing window, and disclose what you collect. A small event queue that sends to your own relay keeps the choice of tool reversible. And a public store data tracker covers what neither sees: your listing's trends over time and every competitor's.

Image credits#

• Cover photo: Antique metal wrenches on a wooden board by Michelle Frechette on the WordPress Photo Directory, CC0.