Growth covers the full user journey
A Chrome extension marketing plan should start with the step where people get stuck. For an Edge or Firefox extension, use that store’s reports and requirements. Check what the available evidence can show before choosing a change.
| What you observe | Evidence to check | Question to investigate |
|---|---|---|
| Few people reach the listing | Store discovery or listing-visit reports, where available, using comparable dates and locale filters | Does the title and description explain the product's purpose in a language it supports? |
| People visit the listing but rarely install | Listing visits and install reports with matching scope, plus screenshots and requested permissions | Can a visitor understand the benefit and what installation requires? |
| Installs arrive, but first use is unclear | Owner-authorized product data or user feedback about a named first useful action | Where does the first-run flow stop, and what would confirm that the user completed the action? |
Store reports vary. Chrome’s Users statistic, for example, records installations rather than product activity. If first-use data is missing, record that gap before drawing a conclusion about onboarding or retention.
Sources: Chrome Web Store metrics and listing information.
Choose one growth question to test
Choose the step you want to understand: reaching the listing, installing or completing the first useful action. Describe who needs the extension and where they look for a solution. Decide which available report or product observation could show what happens at that step.
Store discovery, a product website and a relevant community offer different contexts to consider. A store listing needs a clear explanation at the point of choosing an extension. A product website can show a longer workflow or answer a compatibility question. A community discussion may reveal the vocabulary people use for the problem, subject to that community’s rules. Work on any of these channels needs to be included in the agreed project scope.
For an illustrative page-annotation extension, a useful message might show how to save a highlight and find it again. The next question could be whether visitors reach the matching listing. That observation would still leave installation and first use unresolved. Channel reach, listing visits, reported installs and completion of the useful action each need their own evidence.
Record one proposed change, its observation period and the data available before changing several parts of the journey. If acquisition itself is the task, extension install campaigns have a separate scope and measure.
If a Chrome listing is absent from search
First check whether the item is available. Open its exact store URL and record the region and account context. Check the publication status, keeping the public version separate from any update awaiting review.
Next check Chrome’s distribution settings. Public lists the item; Unlisted permits installation through its URL; Private restricts access to designated users. Geographic distribution also limits where the item can be viewed and installed.
In an illustrative example, an Unlisted item installs through its URL but is absent from store search. The visibility setting explains that observation. If a published Public item is missing for a particular query, these checks alone do not identify the ranking cause.
Record the item URL, published version, draft status, visibility, region, exact search query, observed result and date. Keep URL availability and search appearance as separate observations. These Chrome checks do not establish how Edge or Firefox store search works.
Choose a Chrome category from the main task
Start with one sentence: what does the extension help someone do? Chrome’s categories group extensions by their main function. That makes the product’s central task a useful basis for choosing a category.
- Name the task a new user expects to complete. Keep optional features separate.
- Compare that task with Google’s current category descriptions. Its examples place web-development utilities in Developer Tools and task or time management in Workflow & Planning.
- If two categories seem suitable, compare their descriptions with the main use case. Save the chosen category and a short reason for choosing it.
- Check that the title, screenshots and first-use instructions describe the same task. A category change alone cannot explain a product whose listing remains unclear.
Google documents the category selector under Store Listing, then Product Details, in the Developer Dashboard. See Chrome’s category and discovery guidance. Category fit alone does not tell you where the listing will rank. For Edge or Firefox, check that store’s category guidance separately.
Record the first useful action
For the illustrative annotation extension, the useful result is seeing a saved highlight again. A walkthrough should say what was expected and what actually happened:
| Record | What to write |
|---|---|
| Version and browser | The extension build and browser used for the check. |
| Starting condition | Whether setup is complete and the permissions or sign-in needed for this action are in place. |
| Action and expected result | The steps taken and the visible result that would confirm completion. |
| Observed result | What appeared, where the flow stopped and any error shown. |
| Next unresolved step | The question still open, who will check it and what information they need. |
One walkthrough checks behavior under those recorded conditions. To measure activation across users, define the completion event, the group of users being counted and the observation period, then use product data the owner is permitted to collect and share. Without that data, the completion rate remains unmeasured. Chrome’s Users statistic cannot supply it.
These observations can help scope a growth review. Any product-code changes are agreed separately through extension development.
Keep the listing and product in the same language
Choose a locale using available listing evidence, product data and user requests. A country and a language are different choices. Chrome documents localized listing assets and distribution regions separately; its localized descriptions should represent the same feature set. See Google’s listing guidance.
Walk through the product in the proposed language and record gaps in:
- The main interface, permission explanation, first-run messages and recovery instructions.
- The listing title and description, including any limits on the advertised feature.
- Screenshots or demonstrations that show the actual localized experience.
- Help, support instructions and explanations of changes in later releases.
When the useful result comes later
Consider an illustrative extension that shows saved annotations when a person returns to a page. Setup can finish before that useful result appears. Explain what the user has completed, which later action makes the result visible and how to return to the relevant page. A translated success message alone would leave that next step unclear.
A local walkthrough can check this behavior and find untranslated screens. Estimating how many users complete it requires suitable product evidence. Keep that figure marked as not measured when the evidence is absent; a store install report cannot supply it.
A language review can produce a specific change request without proving demand in a country or a future increase in installs. If the change needs product code, discuss its implementation through extension development.
What the service can cover
The scope may include the following areas, depending on the project:
- Store metadata and positioning review for Chrome Web Store, Microsoft Edge Add-ons and Mozilla Add-ons.
- Creative direction for screenshots and listing visuals without fake ratings, reviews or rankings.
- Localization planning based on real product and market priorities.
- Permission and trust communication review.
- First-run and onboarding flow recommendations.
- Measurement planning for activation and retention questions where the owner has appropriate product data.
Growth review process
- Describe the problem. Share the listing and the step you want to improve. The review scope is agreed before work starts.
- Check the available evidence. Consider listing content, permissions and the first-run flow. Mark questions that need product data or user feedback.
- Choose the next change. The agreed review can identify a change list and measurement questions. Implementation is scoped separately through extension development.