| name | ai-app-opportunity-mvp-research |
| description | Use this skill whenever the user asks to research AI app opportunity keywords, Sensor Tower-style app intelligence, ASO keyword opportunities, App Store or Google Play competitor analysis, Diandian popularity metrics, Similarweb/Semrush website-to-app opportunity discovery, or whether an AI keyword/direction is suitable for an iOS/Android MVP. This skill is especially relevant for prompts like "帮我调研这个 AI App 机会词", "这些词哪些可以先做", "用 Sensor Tower / 点点 / Similarweb 看看能不能做 App", "输出 Go/No-Go MVP 判断", or when the user provides screenshots, tables, chat notes, app store search results, competitor reviews, pricing notes, or website traffic data and expects a decision-oriented MVP research report. |
AI App Opportunity MVP Research
This skill turns messy AI app opportunity notes into a decision-oriented MVP research report. It combines:
- App Store Optimization discipline: keyword classification, search result structure, competitor metadata, review pain points.
- Startup validation discipline: market evidence, problem-solution fit, monetization proof, risks, next validation steps.
- Deep research discipline: source discipline, data completeness, explicit citations when web sources are used.
- The user's practical workflow: Sensor Tower is the main commercial validator, Diandian is auxiliary, website tools discover demand but do not prove app opportunity.
Core Principle
Separate three levels of judgment:
| Level | Question | Allowed conclusion |
|---|
| Trend discovery | Is this topic growing on the web/search side? | "worth app-side validation" |
| App opportunity | Do app store search structure and competitors show a real app market? | "promising / weak / unclear" |
| MVP decision | Is there enough evidence to design an MVP now? | "Go / Conditional Go / Observe / No-Go" |
Do not jump from trend discovery to MVP decision. Website traffic, Google Trends, SEO volume, or social buzz can generate candidate keywords, but they must be validated against Sensor Tower and app store evidence before recommending development.
When Starting
First identify the research mode:
| Mode | User input | Primary task |
|---|
| Keyword triage | Many candidate keywords | Rank which terms deserve deeper validation |
| Single direction validation | One keyword or app idea | Decide Go / Conditional Go / Observe / No-Go |
| Competitor deep dive | One or more apps | Extract monetization, keyword, review, and positioning lessons |
| Website-to-app discovery | Websites, SEO keywords, Similarweb/Semrush data | Turn web demand into app-side validation candidates |
| MVP design | Direction already selected | Produce positioning, V1 scope, monetization hypothesis, and next actions |
Ask a question only when a missing detail changes the research scope. Otherwise proceed and mark missing data explicitly.
Data Source Priority
Use this priority order when sources conflict:
- Sensor Tower or equivalent mobile intelligence data: downloads, revenue, keyword coverage, ranking, geography, platform split.
- App Store / Google Play live evidence: search result structure, titles, screenshots, ratings, reviews, update activity.
- First-hand product experience: onboarding, paywall, pricing, trial, generated output quality.
- Competitor reviews: 1-2 star pain points and 4-5 star praise.
- Diandian data: keyword popularity and search result count as auxiliary ASO signals.
- Similarweb / Semrush: website-side demand and SEO keyword discovery.
- Google Trends: early trend discovery only.
If the user provides screenshots or copied tables, treat them as user-provided evidence. Preserve uncertainty and do not invent missing fields.
Required Workflow
Step 1: Audit Data Completeness
Create a data completeness table before analysis. Mark each item as available, partial, or missing, and explain how missing data affects the conclusion.
Required items:
- Sensor Tower revenue/downloads for top competitors.
- Sensor Tower keyword coverage/ranking for core competitors.
- App Store search result structure.
- Google Play search result structure.
- Diandian popularity and search result count, if available.
- Competitor reviews, especially 1-2 star reviews.
- Competitor paywall/pricing/product experience.
- Similarweb/Semrush website signals, if the direction came from web demand.
- Google Trends signal, if used for discovery.
If Sensor Tower revenue is missing, do not claim commercialization is proven.
Step 2: Classify Keywords
Classify every keyword into one of:
| Type | Meaning | Example |
|---|
| Main keyword | Broad category term | AI headshot, PDF scanner |
| Scenario keyword | Specific use case | LinkedIn headshot, invoice generator |
| Audience keyword | Clear user segment | resume photo for job seekers |
| Function keyword | Product capability | video translator, image translator |
| New/rising keyword | Fresh term from website/search trends | AI tattoo generator |
Prefer MVP entry through scenario, audience, or function keywords when the main keyword is dominated by large general tools.
Step 3: Analyze App Store Search Structure
For each target keyword and platform, summarize the top results:
- Top 10 composition: exact vertical apps, broad/general AI tools, unrelated apps, incumbents.
- Whether smaller vertical apps appear.
- Ratings, review counts, freshness/update activity.
- Screenshot/message patterns.
- Whether the search page reveals a realistic entry wedge.
Do not treat search result count alone as opportunity. A low result count with no monetizing competitors is weak evidence.
Step 4: Validate Commercialization With Sensor Tower
Use Sensor Tower-style evidence to answer:
- Are top exact competitors earning meaningful revenue?
- Are downloads and revenue both present, or only downloads?
- Is revenue concentrated in one head app, or distributed across smaller vertical apps?
- Is there iOS-only, Android-only, or cross-platform evidence?
- Which countries drive demand?
- Which keywords do the competitors actually rank for?
Small vertical proof is especially important: a smaller app with modest downloads but meaningful revenue is often a better MVP signal than a giant general app earning money.
Step 5: Use Diandian as Auxiliary ASO Validation
Treat Diandian popularity as a directional signal, not a replacement for Sensor Tower:
| Diandian signal | Interpretation |
|---|
| popularity < 40 | likely low volume unless it is a new/rising term |
| 40-49 | basic demand; observe or validate further |
| 50-59 | worth focused Sensor Tower/app store validation |
| 60-69 | strong demand; competition likely stronger |
| >= 70 | high demand and usually competitive |
The user's working heuristic:
- Popularity around 40 may correspond to roughly 500 daily organic downloads for the first result.
- 50 may correspond to roughly 1000 daily downloads.
- 60 may exceed 1500.
- 70 may exceed 3000.
Always label this as experience-based, non-official, and directional. If Diandian conflicts with Sensor Tower revenue/keyword coverage, prefer Sensor Tower.
Step 6: Analyze Reviews and Paywall
Review pain points become MVP opportunities only when:
- They appear repeatedly.
- They affect purchase, retention, trust, or output quality.
- A V1 product can realistically solve them.
- They map to a clear positioning or feature choice.
Common review categories:
| Review pain | Possible MVP implication |
|---|
| too expensive | lower price, credit pack, one-time purchase |
| forced subscription | transparent pricing or non-subscription option |
| not like me | similarity-first generation |
| poor quality | quality benchmark before launch |
| too slow | faster turnaround as differentiator |
| too few styles | narrower but better scenario templates |
| refund/trust issues | clearer payment promise and refund policy |
| bugs/crashes | reliability as a wedge only if competitors are weak |
Do not invent pricing or paywall details. If product experience is missing, say so.
Step 7: Map Website Signals Back to App Validation
Similarweb, Semrush, Google Trends, and competitor websites help discover new AI use cases. They do not prove app opportunity.
For each website-side signal, map it back:
| Web signal | Required app validation |
|---|
| SEO keyword growing | Check App Store / Google Play top 10 |
| High website traffic | Check whether app competitors monetize |
| Many web tools, few apps | Check whether app workflow is natural |
| Rising Google Trends query | Check Sensor Tower keyword and competitor revenue |
| Paid web tool exists | Check whether mobile willingness-to-pay exists |
State clearly when the finding is "web-side only."
Step 8: Score the Opportunity
Use the 100-point score as an auxiliary decision tool:
| Dimension | Points | What to check |
|---|
| Sensor Tower revenue validation | 25 | at least one exact/near competitor earns meaningful revenue |
| Platform validation | 10 | iOS/Android evidence matches the intended launch platform |
| Keyword opportunity | 15 | there are usable scenario/audience/function entry terms |
| Small vertical proof | 15 | smaller focused apps can earn, not only head/general tools |
| Competitive entry feasibility | 10 | top results are not fully locked by incumbents |
| Review pain point opportunity | 10 | repeated pain points are V1-solvable |
| Monetization feasibility | 10 | pricing/paywall/revenue model evidence exists |
| Website-side supporting signal | 5 | web demand supports discovery but does not carry the decision |
Interpretation:
| Score | Conclusion tendency |
|---|
| 80-100 | strong candidate for MVP design |
| 65-79 | worth deeper validation |
| 50-64 | signal exists but not ready for MVP |
| 30-49 | low priority, observe |
| <30 | not recommended |
Step 9: Apply Downgrade Rules
Downgrade the conclusion when:
- Sensor Tower revenue data is missing.
- Only trend or website data is available.
- Exact competitors have weak revenue.
- Only broad/general tools make money while vertical apps do not.
- The keyword is dominated by large incumbents with no realistic entry wedge.
- The main user pain points cannot be solved by a V1 product.
- Only one platform has data but the conclusion claims both platforms.
- Pricing/paywall is missing but the report makes a confident monetization recommendation.
Step 10: Decide
Use one of four conclusions:
| Conclusion | Use when |
|---|
| Go | enough evidence supports MVP design now |
| Conditional Go | direction is promising but key evidence is missing |
| Observe | signal exists but commercial or execution proof is weak |
| No-Go | evidence does not support continuing |
Always include conditions. Example:
Conclusion: Conditional Go. The direction has commercial signal from [competitor/source], but still lacks [missing evidence]. Do not enter development until [next validation] is completed.
MVP Recommendation Rules
If recommending an MVP, define:
- One target user group.
- One main entry keyword and up to two auxiliary keywords.
- One positioning sentence:
For [target user] in [specific scenario], provide [core outcome], differentiated by [evidence-backed wedge].
- No more than five V1 core functions.
- Pricing only if competitor paywall, pricing, or revenue evidence exists.
- Differentiation only from evidence: keyword gap, review pain, paywall weakness, vertical proof, search structure, or product experience.
- First-month validation metrics.
Use P0/P1/P2 priority for features:
| Priority | Meaning |
|---|
| P0 | required to test the core paid hypothesis |
| P1 | improves conversion but can be delayed |
| P2 | nice-to-have, not in V1 |
Output Format
Use the full template in references/report-template.md for complete reports.
For quick triage, use this shorter structure:
# [Keyword/Direction] App MVP Research
## One-Sentence Decision
Conclusion: [Go / Conditional Go / Observe / No-Go]. [Core reason].
## Data Completeness
| Data item | Status | Impact |
## Keyword & Search Structure
| Keyword | Type | Platform | Search structure | Opportunity |
## Commercial Proof
| Competitor | Platform | Downloads | Revenue | Evidence quality | Interpretation |
## Key Risks
| Risk | Evidence | Mitigation / next validation |
## Score
| Dimension | Points | Reason |
## MVP Recommendation
Only include if Go or Conditional Go.
## Next Actions
| Priority | Action | Tool/source | Expected output |
Forbidden Behavior
- Do not invent downloads, revenue, ranking, popularity, prices, reviews, search volume, or screenshots.
- Do not use Google Trends as core MVP evidence.
- Do not treat website traffic as app revenue proof.
- Do not recommend development only because a head competitor earns money.
- Do not ignore small vertical competitors.
- Do not turn every negative review into an opportunity.
- Do not output vague conclusions like "market is promising" without evidence.
- Do not give more than five V1 core features.
- Do not claim both iOS and Android are viable when data covers only one platform.
- Do not produce a strong Go when critical data is missing; use Conditional Go or Observe.
Reference Files
references/data-source-playbook.md: how to interpret Sensor Tower, Diandian, app stores, reviews, website tools, and Google Trends.references/report-template.md: full decision-report template.references/trigger-examples.md: examples of prompts that should and should not trigger this skill.
