Chrome extension developers have a churn problem, and it's worse than most realize.
Studies of extension retention show that a significant portion of installed extensions — estimates range from 40% to 60% — are uninstalled within the first week. Most users try an extension, hit some friction, and quietly remove it. No review. No support ticket. No explanation.
And Chrome tells you nothing about any of it.
What the churn numbers actually mean
High early churn isn't unique to Chrome extensions — mobile apps have the same problem. But extensions have a few characteristics that make the churn-to-signal problem especially acute:
Friction to install is low. Users add extensions impulsively, sometimes without a strong intent to use them. The install bar is lower than mobile apps, which means a higher percentage of installs come from users who were never deeply committed.
The use case is narrow. Most extensions solve one specific problem. If the user doesn't encounter that problem in the first few sessions, or if the solution is slightly off from what they needed, they uninstall.
There's no onboarding forcing function. Mobile apps can gate features behind onboarding flows. Extensions activate immediately, and if the first experience is confusing or incomplete, there's no recovery mechanism.
The result is a retention curve that drops steeply in week one and then flattens. The users who stay past week one tend to be long-term users. The users who leave in week one are often leaving because of something fixable.
What Chrome actually gives you
The Chrome Web Store developer dashboard provides:
- Weekly active users — the number of users who used your extension in the past week
- Install and uninstall counts — raw numbers, no breakdowns
- Star ratings and reviews — public reviews, visible to everyone
That's the full dataset. There's no uninstall cohort analysis, no reason codes, no segmentation by user type or install source. You can see that uninstalls happened; you cannot see who uninstalled or why.
Reviews are helpful but systematically biased. Users who bother to leave a review are not representative of users who quietly uninstall. Reviewers are more likely to have strong opinions — either very happy or very angry — than the median churned user, who probably had a mild negative experience and just moved on.
Relying on reviews as your primary feedback signal means you're optimizing for the vocal minority, not the silent majority who left without saying anything.
The setUninstallURL() API
Chrome provides a hook that most extension developers don't use: chrome.runtime.setUninstallURL().
When you call this API in your extension's background script, Chrome stores the URL you provide. When a user uninstalls your extension, Chrome automatically opens that URL in a new tab. That's it — one redirect, one chance to ask a question before the user is gone.
The API was designed for custom goodbye pages, and that's the right way to think about it. You have one moment of user attention, immediately after they've made the decision to leave, to find out why.
// In your background script (service worker in Manifest V3)
chrome.runtime.setUninstallURL("https://yourapp.com/uninstall-feedback");
That URL should lead to a short feedback form. Not a retention flow, not a "please reconsider" plea — just a quick question: why did you leave?
Building a feedback collection flow
The form that lives at your uninstall URL should follow a few principles:
Keep it short. You have about 30 seconds of goodwill from a just-uninstalled user. A 10-question survey wastes it. A 2-question form might get answered.
Lead with structured reasons. Give users checkboxes with plausible reasons so they can answer in one click:
- It had a bug or didn't work correctly
- It slowed down my browser
- It was missing a feature I needed
- I found a better alternative
- I no longer need this type of tool
- Other
Follow with an optional open text field. The checkbox tells you the category; the text field tells you the specifics. "Missing a feature" is a category. "I needed it to work on YouTube Music, not just YouTube" is actionable.
Don't require an account or email. If your feedback form asks for a login, almost no one will fill it out. Anonymous responses are fine — the signal comes from the aggregate, not the individual.
Acknowledge completion gracefully. A simple "Thanks — this genuinely helps us improve" is enough. Don't oversell it.
What the data tells you
Once you have a few weeks of responses, the breakdown of reasons tells you what kind of churn you're experiencing:
Bug and performance churn is the most fixable. If 40% of your churned users cite bugs or slowness, that's a clear prioritization signal. These are users who wanted to use your extension and couldn't. Fixing the underlying issue may not recover the churned users, but it will reduce future churn from the same root cause.
Missing feature churn is a product gap signal. Look at the open-text responses here — users will often name the exact feature they wanted. If the same feature appears in 15% of responses, it belongs in your roadmap. If it appears in 1% of responses, it's probably not worth building for the handful of users it would serve.
"Found a better alternative" churn is competitive intelligence. Sometimes users name the alternative. That's direct market research: go use that tool, understand what it does better, and decide whether you want to compete on that dimension.
"No longer needed" churn is lifecycle churn — the user's situation changed. This is the least actionable category because there's nothing wrong with your extension. These users may come back if their situation changes again. A low-pressure "we'll be here if you need us again" message is appropriate; a retention push is not.
Acting on the data
Triage by volume first. One bug report in open text is a data point. Twenty bug reports describing the same problem is a crisis. Sort by frequency before deciding what to fix.
Cross-reference with star reviews. If the same theme appears in your uninstall feedback and in your 1-2 star reviews, that's a confirmed problem from two independent sources. Prioritize these over issues that appear in only one channel.
Distinguish between bugs and opinions. "It crashed when I clicked the icon" is a bug. "The icon is in the wrong place" is a preference. Bugs should be fixed. Preferences should be weighed against how many users share them.
Set a response threshold. Decide in advance that you'll address any category that represents more than X% of responses. This prevents bikeshedding — spending time on a niche request that one vocal user submitted four times.
Close the loop. If you fix a bug that was cited frequently in uninstall feedback, consider whether there's a way to reach churned users who cited that bug specifically. Not always possible, but for users who left an email address, a short note saying "we fixed the issue you mentioned" occasionally brings someone back.
ExtFeed is purpose-built for this workflow — structured uninstall feedback with one line of code. Drop in the
setUninstallURL, point it at your ExtFeed endpoint, and you'll have categorized feedback data within hours of your next release.