Chrome Web Store Data Collection Disclosure: What Your Extension Must Declare

If the Chrome Web Store dashboard is blocking your submission on the Privacy practices tab, the short answer is this: you have to declare every category of user data your extension collects, certify that you follow the Limited Use rules, and (in almost every case) link a privacy policy. The Chrome Web Store data collection disclosure is not optional boilerplate. An item that leaves it incomplete or inconsistent with its manifest permissions will not pass review. This post walks through exactly what the form asks, what each data category means, and how adding analytics changes what you have to check.

What the Privacy practices tab actually asks for

Every extension has a Privacy practices tab in the Developer Dashboard, and you cannot publish or update an item until it is filled in. It has five sections:

1. Single purpose. A short description of the one narrow thing your extension does. Chrome's single-purpose policy means everything else on this tab is judged against it.
2. Permission justifications. For each permission in your manifest.json (and each host permission), a sentence explaining why the extension needs it. Reviewers cross-check these against your actual code.
3. Remote code. A declaration of whether your extension runs any code that is not bundled in the package. Manifest V3 bans remotely-hosted code, so for most extensions this is a plain "no."
4. Data usage. Two groups of checkboxes in one section: the first discloses which categories of user data you collect, the second certifies that your use follows the Limited Use rules.
5. Privacy policy. A field for the public URL of your privacy policy.

The friction most developers hit is the data usage disclosure, because it is easy to under-declare by accident. Google's guidance is that all data collection must be prominently disclosed, regardless of whether it is closely related to your single purpose. "We only send anonymous usage counts" is still data collection and still has to be declared.

The data categories you choose from

The disclosure form uses a fixed list of categories. You check the ones that apply:

• Personally identifiable information (name, address, email, phone number, age, ID numbers)
• Health information
• Financial and payment information
• Authentication information (passwords, credentials, security questions, PINs)
• Personal communications (emails, texts, chat messages)
• Location (region, IP-based or GPS location, anything more precise than country)
• Web history (the list of pages a user visits, including URLs and page titles)
• User activity (network monitoring, clicks, mouse position, scroll, keystroke logging)
• Website content (text, images, or other content on pages the user visits)

Chrome applies its strictest rules to what it calls personal and sensitive user data, a broad umbrella that spans personally identifiable information, financial and payment information, authentication information, health data, personal communications, web browsing activity, and website content. Collecting anything in that umbrella raises the bar: you have to limit use to your disclosed purpose and you cannot transfer it except where the policy specifically allows.

The category that trips up analytics is User activity. If you record how people interact with your extension, such as which buttons they click or which features they open, that is user activity and it belongs on this list. Web usage analytics that watches the pages a user browses would additionally pull in Web history and possibly Website content, which is a much heavier disclosure and a much harder privacy policy to write.

The three Limited Use certifications

Under the data categories, you must affirm that your data handling meets the Limited Use policy. In practice that is three commitments:

1. Data is not sold or transferred to third parties, outside of approved use cases.
2. Data is not used or transferred for purposes unrelated to your item's single purpose.
3. Data is not used or transferred to determine creditworthiness or for lending purposes.

Chrome also expects an affirmative statement of Limited Use compliance to appear on a page your extension owns, such as a linked section of your homepage or privacy policy. The dashboard checkbox and the public statement are meant to match.

When you need a privacy policy URL

You must provide a privacy policy if your extension handles any user data, or requests a permission that can access user data (which covers most non-trivial extensions). Only an item that collects zero user data and requests no data-related permissions can skip it, and even then Google recommends having one. The policy has to live at a public, persistent URL that anyone can open without logging in, and it has to comprehensively describe what you collect, why, who you share it with, and how users reach you. Reviewers compare that policy against your manifest permissions and your dashboard disclosures, so all three have to tell the same story. If your privacy policy says "we collect nothing" but you ship an analytics call, that inconsistency is a rejection.

One more requirement sits alongside disclosure: secure handling. Chrome requires user data to be transmitted over a secure connection such as HTTPS or WSS. If you roll your own telemetry endpoint over plain HTTP, that is a policy violation independent of anything on the disclosure form.

How analytics changes your disclosure

Here is the honest tradeoff. Any analytics that describes how users interact with your extension adds User activity to your disclosure. There is no analytics tool that makes that box go away. What a tool can do is keep the disclosure from expanding beyond that single box.

The variables you control are what leaves the extension and what permissions you have to request to make it leave. A telemetry setup that reads page URLs, injects into every site, or attaches an email address to each event forces you to check Web history, Website content, or Personally identifiable information, request broad host permissions, and defend all of it to a reviewer. An anonymous, in-extension approach that never touches page content or identity keeps you at User activity and nothing more.

This is where Moderok is deliberately narrow. The SDK assigns a random analytics profile id, stores it with the extension's data, and may recover it through browser sync for a signed-in browser user. It sets no cookies, builds no fingerprint, and does not add PII on its own. The context it attaches to each event is coarse: SDK version, extension id and version, browser and browser version, OS, locale, and which surface fired the event (background, popup, options, and so on). Beyond that it sends the flat properties you pass to track(). It reads no page content and requires no host_permissions, but it does require you to add the storage permission.

Two things to declare honestly. First, automatic error tracking is on by default: uncaught exceptions and unhandled promise rejections are sent as __error events carrying the error message and stack trace from your own code (uncaught exceptions also include the filename and line number), and you can turn it off with trackErrors: false. Second, whatever you put in custom event properties is yours to account for, so if you pass an email address or a full page URL into track(), you are the one collecting PII or web history. Keep both minimal and, for most extensions, your disclosure stays at User activity while you can still truthfully sign all three Limited Use certifications.

If you are weighing this against wiring up your own pipeline, it is worth reading why Google Analytics does not run in an MV3 extension before you build one, and how Chrome's uninstall tracking fits into the same disclosure once you add it.

Before you hit submit

Walk the form once more against your code. Every permission in the manifest has a justification. Every category of data you actually send is checked, including the analytics you just added. Your privacy policy URL resolves publicly and matches what the checkboxes say. Your data leaves the browser over HTTPS. Get those four lined up and the Privacy practices tab stops being the thing that holds up your release.

Want extension analytics with a narrow default identity model and developer-controlled event properties? Moderok was built for exactly this environment.