Web Opportunity Validation

Find a user task that can be reached, solved, and monetized. Follow the same funnel on each zero-to-one search: scope → source candidates → quick gates → deep evidence → economics → score and compare → smallest live test → review. Read the field workflow for required observations, quotas, tool alternatives, and the report format; read the scorecard before ranking. The quotas and weights are repeatable operating conventions created for this skill, not claims from any author or guaranteed success thresholds.

This workflow synthesizes Liangzhu's original article, Gefei's first-hand posts and case studies, and other founder notes. A post can supply a discovery technique or a failure mode; it does not validate a new candidate. Keep the author's anecdote, current observable evidence, third-party estimate, and our inference separate. Do not copy another person's reported revenue, CTR, conversion rate, RPM, KD cutoff, or ranking outcome into a forecast.

Run the funnel

1. Scope. Record target language–country pairs, user or buyer, current skills and assets, time and cash limits, permitted tools, and whether the goal is practice or commercial income. The standing search scope is English plus two selected non-Chinese smaller-language locales; exclude Chinese-language markets. Choose the specific locales from the user's stated abilities and current evidence, and label any provisional choices. For other missing constraints, provisionally assume public or free tools, a small web MVP, and a commercial goal, and revise when the user supplies constraints. Do not create accounts, buy subscriptions or domains, launch ads, publish, or contact people without authorization.
2. Source candidates. For a broad request, collect 12 distinct user-job × locale opportunities by default: three each from stable search queries, rising queries, competitor reverse research, and firsthand complaints or purchase behavior; aim for six English and three in each selected smaller-language locale. Include the exact local-language phrase, source URL, date, locale, user job, and plausible payer. Treat social virality as a lead, not search or revenue proof. Deduplicate near-synonyms within each locale; count the same job in another locale only when local evidence exists. For a supplied idea, use the same checks on that idea and at least two nearby alternatives when comparison would change the recommendation.
3. Quick gates. Search each phrase in the target locale; identify intent and inspect the first results. Remove entries with no clear task, no lawful way to deliver it, no credible reachable channel, or no plausible revenue route for a commercial goal. Mark a candidate unknown rather than rejected when decisive evidence is merely inaccessible. Keep up to five for deep review and show the rejected or deferred ones with reasons.
4. Deep review. For each survivor, record demand over time, exact search intent, the visible top ten results and three closest alternatives, a specific underserved task, likely acquisition path, payment/ad evidence, and build and operating costs. Verify the actual use rights for branded, game, media, and user-uploaded content. Check local-language quality, support, and payment friction; compare search and price evidence within the same locale and period. Use paid reports only for a named uncertainty that could change the verdict; follow tool access notes and label inaccessible metrics.
5. Economics. Name the payer and transaction or ad event. Work backward from a break-even or user-specified profit target using measured inputs and explicit low/base/high assumptions. Separate visits, pageviews, clicks, qualified users, orders, gross revenue, payment fees, variable delivery cost, refunds, and fixed costs. CPC is an advertiser price, not publisher earnings. A competitor's public price is not proof of its sales. If the model depends on an implausibly large audience or loses money per order, mark that clearly.
6. Rank and decide. Apply the seven-dimension 100-point scorecard only after the gates and evidence table. Score unknowns conservatively and list the observation that would change each weak score. Output reject / cheap probe / MVP test / expand with separate product and business confidence. A high score earns a test, not a claim of validated profit. Recommend one primary candidate and a backup; explain the tradeoff against the other survivors.
7. Run or specify the smallest test. Define one user task and working interaction, one acquisition route, one useful-action event, and one payment or qualifying revenue event. State an explicit time/budget cap and review date. If asked to build, verify the interaction and instrument it. If asked to launch, inspect the live page, analytics, and Search Console separately. Judge the test from observed behavior and net contribution; iterate, pivot, or stop by the predeclared rule.

Important interpretation rules

• Search volume, Google Trends indices, KD, Similarweb traffic, CPC, ad RPM, and competitor earnings are different measures. Google Trends is sampled and relative; Ahrefs KD is a backlink-oriented estimate; third-party traffic is modeled. Record tool, plan, date, country, and limitations beside each number.
• Exact-match domains, a big site's inner page, forum-heavy results, intitle counts, and low KD are leads for manual SERP review. They are not automatic ranking advantages or hard gates. Google's ranking guide gives exact-match domains limited weight; Google's spam policies constrain manipulative links and low-value scaled pages.
• Gefei's beginner “practice site” path is for learning indexing, analytics, and distribution. Label it practice, with a learning success measure, instead of presenting it as a business opportunity. For a commercial run, require an actual payer or ad economics and a realistic acquisition path.
• Build focused pages that complete the user's task. Do not treat a domain purchase, rapid launch, mass-produced pages, directory submissions, or an indexing request as evidence of demand or ranking. Google's crawling FAQ says indexing requests are not guarantees.

When the user sends another post

Read the original post and any quoted or reposted source. Record author, date, direct experience versus commentary, exact claim, evidence shown, applicability, and conflicts in the relevant source notes. Update a workflow rule only if it improves a real decision; keep an anecdote as a case when it does not generalize. Recheck drifting tools, prices, and platform policies against primary current sources. Run the scorecard on a realistic candidate after substantial changes and report what passed, what is assumed, and what remains unverified.