# The Demand-Signal Reference for Sizing a Market Category *You will pick the right public proxy for each part of a category-size estimate, convert it into a defensible number, and state how far each proxy can be trusted.* - Canonical URL: https://www.refolk.ai/guides/demand-signal-market-sizing-reference - Pillar: Market and talent intelligence - Format: Reference - Published: 2026-08-14 - Last reviewed: 2026-08-14 - Reading time: 16 min You need to estimate how big a market category is and how fast it is growing from public signals, before you trust a vendor's number or a deck's TAM slide. This reference is for strategy and research teams, talent-intelligence analysts, and operators sizing a category. It defines each public demand proxy - aggregate job postings, web traffic, business-registry counts, review volume, search interest, funding inflow - and states exactly how each one over- and under-counts, so you can pick the right proxy per component, convert it into a defensible number, and say how far to trust it. The step-by-step TAM formula is not the hard part. The hard part is knowing which proxy to trust for a given category and what error each one carries. That is what you jump into this document to look up. ## Why no single proxy sizes a category No single public signal sizes a market. The reliable approach triangulates several, because each proxy answers a different question and misleads in a different direction. One market-sizing write-up frames it directly: conference sponsorships indicate budget priority, job listings are the best proxy for operational pain, academic citations spot emerging categories, and supplier revenues provide the financial reality check. The most reliable read combines them. The reason to triangulate is that each proxy measures a slice of demand, not demand itself. Public business data shows local supply, not full market demand; to size a market you still need population, income, category penetration, and average spend on top of any supply count. Reviews show relative visibility, not revenue. Job postings show hiring intensity, not headcount. Read any one alone and you inherit its blind spot as if it were the answer. > Each proxy answers a different question and lies in a different direction, so a single-signal TAM is a hypothesis, not a number. The bottom-up spine is always the same equation: Total Addressable Market equals Annual Contract Value times the total number of potential accounts. Every proxy in this reference feeds one of two slots in that equation - it either estimates the account count or anchors the price. The skill is choosing a proxy whose known error you can bound, then correcting for it before you multiply. ## The demand-proxy reference Here is the lookup table. Each row names a proxy, what it proves, how it misleads, and its update cadence. Read the row for the component you are sizing, apply the correction, and move on. | Proxy | What it proves | How it misleads | Update cadence | |---|---|---|---| | Aggregate job postings | Operational pain and hiring intensity | Duplicates and evergreen reposts inflate; over-weights high-skill roles, misses gig labor | High-frequency, daily | | Web traffic | Relative attention across sites | Counts bots as demand; 40%+ can be automated | Near real-time | | Business-registry counts | Number of legal entities | Shell, shelf, and dormant entities inflate the count | Slow, annual filings | | Review volume | Relative visibility inside one category and area | Not a revenue number; 40% review share is not 40% revenue | Continuous, lagged | | Search interest | Near real-time attention on a term | Relative and sampled; low-volume terms decay to noise | Near real-time | | Funding inflow | Budget priority and investor conviction | Lags real demand; concentrated in fundable categories | Event-driven | A practitioner note on the labor row. Job-posting datasets are large enough to feel authoritative - one research aggregator pulls postings from over 220,000 websites and holds more than 435 million US postings since 2010 - but scale does not fix the systematic skews. Online vacancy data tends to disproportionately represent high-skill occupations, so a tech category will look relatively larger than a service category even when the underlying demand is comparable. > **Rule:** Name what each proxy feeds > > Every proxy you pull must map to a slot in TAM = ACV x accounts. If a number does not estimate the account count or anchor the price, it is context, not an input, and it should not appear in the arithmetic. ### Labor proxies: two traps built into the title A labor proxy is only as good as the title you count. Refolk's index makes both failure directions concrete. First, naming conventions split one pool across titles. In the US, "Machine Learning Engineer" and "AI Engineer" describe largely overlapping work, yet the counts diverge sharply. | Title | US count | Share of pair | |---|---|---| | Machine Learning Engineer | 10,614 | 70.2% | | AI Engineer | 4,515 | 29.8% | Count either title alone and you under-count the real category by more than half. The two together total 15,129, and the split is 70/30 - so a proxy built on the more visible title still misses a third of the pool. **2.35x - How much "Machine Learning Engineer" outnumbers "AI Engineer" in the US** From Refolk's index; two titles for largely one talent pool, so a single-title proxy under-counts the category by more than half. Second, geography swings the same title fourfold. The identical "Data Analyst" title returns very different densities across two mature markets. | Title | US count | UK count | US/UK ratio | |---|---|---|---| | Data Analyst | 63,161 | 15,420 | 4.10x | A cross-border TAM built on one market's density will mislead by about 4x if you project it onto the other. In Refolk's index of professional profiles, that 4.1x gap between US and UK "Data Analyst" counts is exactly the kind of correction a single-market proxy hides. #### What a labor proxy is actually made of 1. **Raw title count** - what one search returns for one job title 2. **Title synonyms** - the adjacent titles naming the same work 3. **Geography** - the market density that scales the count up or down 4x 4. **Skew correction** - the high-skill over-representation that inflates tech categories *Every layer above the raw count is an error you inherit if you skip it.* ## Converting a proxy into a defensible number The conversion is a multiplication, and its honesty lives entirely in the ratio you multiply by. The core bottom-up move is account count times price: TAM equals ACV times the number of potential accounts. For platform and payments models, substitute a take-rate. A worked example makes the shape clear: roughly 30,000 US SaaS platforms process payments, at about 2 million dollars a year each, and a 0.5% take rate yields 10,000 dollars of revenue per customer, so TAM is 30,000 times 10,000, or 300 million dollars. When you lack a direct ACV, anchor price to spend benchmarks. Average business IT spend runs roughly 1.5 to 8% of revenue, about 3.6% across all industries, which lets you back into a per-account budget from a company's revenue band. Treat that as a range, not a point. Two reconciliation thresholds govern whether the number is trustworthy, and the published sources disagree. Hold both. > **Watch out:** The 15% rule is meaningless with shared inputs > > Top-down and bottom-up often reuse the same industry figure, which manufactures false agreement. Convergence within 15% only proves accuracy when the two methods use genuinely independent inputs. Check the disjointness before you trust the threshold. The tight rule: cross-check your top-down estimate with a bottom-up calculation, and if the two land within 15% of each other you can be confident; a gap over 15% is a signal to revisit your ratios. The looser consulting rule: a 2 to 3x divergence signals a structural gap, usually an excluded segment, and reconciling the two estimates is one of the highest-leverage moves in a sizing exercise. Use the 15% rule when your inputs are clean and independent; fall back to the 2 to 3x rule when they are rough. One realism check on the far end. Market-leading companies often reach only 10 to 15% share, and a company generally needs about 200 million dollars in revenue to go public. If your captured-revenue scenario implies a share far above 15%, the assumption, not the market, is wrong. I ran this search: `Machine learning engineers and AI engineers at Series B fintech companies in the United States.` - [see the full result list](https://www.refolk.ai/s/9qweg4pnpd). *Returns the current people matching both titles at that stage and sector, so you can count the real pool across synonymous titles instead of guessing from one.* Counting the account universe by hand across synonymous titles, subsidiaries, and geographies is where proxy work stalls. [Refolk](/) resolves a plain-English description into the actual people or companies that match, which turns the labor-proxy step from a spreadsheet estimate into a headcount you can defend. When the category spans two titles like the ones above, asking for both at once removes the under-count baked into a single-title search. ## The step-by-step sizing procedure This is the procedure the reference supports. Each step ends in a concrete artifact, so you can stop, hand off, or audit at any point. #### From category definition to a trust-tagged estimate 1. **Define the category and unit** - Pick whether the unit is accounts, users, or transactions, then fix the revenue unit as ACV or ARPU. The unit choice materially changes TAM, so write it in one sentence. 2. **Pick the proxy per component** - Map each part of the estimate to its best proxy and plan to triangulate. Produce a table of component to proxy with a one-line rationale each. 3. **Pull the raw proxy counts** - Gather job postings, registry counts, traffic, search interest, funding, and index headcounts. Record dated raw numbers with their sources. 4. **Clean and de-duplicate** - Remove duplicate and evergreen postings, map subsidiaries to parents, strip bot traffic, and exclude dormant entities. Keep the reduction factor written down. 5. **Convert to revenue or units** - Apply count times ACV or ARPU, or a take-rate. Show the base-case number with its ratio on its own line. 6. **Run the second method and reconcile** - Build the other of top-down or bottom-up from independent inputs and compare against the 15% or 2 to 3x threshold. Flag both thresholds. 7. **Run sensitivity scenarios** - Produce low, base, and high cases benchmarked against comparable companies' ARPU. Name the comps that anchor the ends. 8. **Document freshness and trust** - Tag every row with its update cadence and error range. Deliver a per-row confidence note. The cleaning step is where most of the accuracy is won or lost, so give it real time. A rough rule of thumb for effort: definition and proxy selection take a few hours, pulling and cleaning takes the better part of a day, and reconciliation plus sensitivity takes another half-day. If any step produces a number you cannot trace to a dated source, it is not done. ## How each proxy over- and under-counts This is the section to keep open. Every proxy fails in a documented way, and each failure has a false positive you can name and a check you can run. Read the row for the proxy you are using before you trust its number. #### Web traffic from raw hits to human demand | Stage | Figure | Note | | --- | --- | --- | | Raw traffic 2025 | 100% | everything the counter logs | | After bad-bot strip | 60% | removing the 40% bad-bot share | | Human traffic | 47% | what is left after all bots in 2025 | *Bot share is a haircut you take before the number means anything.* **Job postings over-count via duplicates and reposts.** The false positive is a hiring surge that is really one role syndicated across boards. Raw counts are distorted by duplicates, reposting, evergreen roles, and aggregation bias, so the investable signal comes from changes in normalized posting intensity, not absolute levels. Check: de-duplicate and map subsidiaries to parents before counting. **Job postings under-count low-skill and gig demand.** The false positive is concluding a labor category is small when platform roles are simply invisible to vacancy data. Online vacancy data over-represents high-skill occupations and misses platform and gig labor. Check: cross-reference official labor statistics for any service or gig-heavy category. **Web traffic counts bots as demand.** The false positive is a market that looks like it is growing when 40% or more of its traffic is automated. Apply the human-share haircut from the table below. | Year | Total bot share | Bad bot share | Human share | |---|---|---|---| | 2023 | 49.6% | 32% | 50.4% | | 2024 | 51% | 37% | 49% | | 2025 | 53% | 40% | 47% | 2024 was the first year automated traffic passed human. Multiply any traffic-derived demand figure by the human share for the relevant year before you use it. **53% - Share of global web traffic that was bots in 2025** Bad bots alone were 40%; uncorrected traffic overstates human demand by roughly its bot share, so a traffic proxy needs a human-share haircut. **Reviews mistaken for revenue.** The false positive is "Competitor A owns 40% of revenue" when it owns 40% of review visibility. A 40% review share is not a 40% revenue share. Check: use reviews only as a relative visibility signal inside one category and one trade area, never as a level. **Registry counts inflated by shell, shelf, and dormant entities.** The false positive is counting paper-only companies as customers. Shell companies are legal entities that exist on a registry with no physical presence, no activity, and no purpose - and there is nothing illegal about them, which is why they are abundant. One indicator dataset has flagged over 655,000 dormant companies and 3.4 million with financial anomalies. The problem concentrates where incorporation is cheapest: one global sample found a single tax-haven jurisdiction holding about 0.3% of registered companies despite roughly 0.0005% of world population. Check: filter for active-trading status and treat tax-haven registration densities as red flags. **Search interest read as absolute volume.** The false positive is a rank-100 spike that is really sampling noise on a low-volume term. Trends data uses random samples of anonymized searches, and for high-volume terms above about 10,000 monthly searches the relative patterns are reliable; below that, the same query produces results that swing widely day to day. Check: confirm the term clears the volume floor and average several extractions. **False convergence.** The false positive is top-down and bottom-up agreeing within 15% only because both reuse the same industry number. Check: confirm the two methods draw on independent inputs before you trust the threshold. #### Which proxy to trust for a given category Horizontal axis runs from Slow to update to Fast to update. Vertical axis runs from Captures little of the category to Captures most of the category. | Quadrant | What it means | | --- | --- | | Registry counts | Slow and partial; useful only after dormant-entity filtering | | Job postings | Fast but skewed to high-skill; correct for title synonyms | | Review volume | Slow and narrow; relative visibility only, never a level | | Search interest | Fast but relative; trust only above the volume floor | *Trust follows both how fast the proxy updates and how much of the category it captures.* ## Which proxies update fastest, and how they decay Search interest and job postings update fastest; registry counts update slowest, on annual filing cycles. Freshness matters because a growth read is only as current as its slowest input, and each fast proxy decays into noise in its own way. Search interest is near real-time but non-absolute. It is a relative index built from a sample, so high-volume terms give reliable patterns while low-volume terms decay to zero under integer reporting - the same query can return materially different numbers day to day. Job postings are high-frequency and good for velocity, but their absolute levels are noisy, so read the change in normalized intensity rather than the raw count. Registry data is the opposite: stable but stale. It reflects last year's filings and lags real activity, which is fine for a slow-moving account count and useless for a growth rate. Funding inflow is event-driven, arriving in lumps that lag the demand that justified the round. **Per-row freshness and trust tag** ``` Proxy: Raw value + date: Cleaning applied: Reduction factor: Update cadence: Error direction: Trust: ``` *Attach one of these to every proxy row in your model so a reader knows how far to trust it.* The discipline is to make freshness and error visible on the face of the model, not buried in a footnote. A reader should be able to point at any row and say how old it is and which way it lies. ## Before you call the estimate done Run this checklist before you circulate a number or use it to sanity-check someone else's TAM. It maps directly onto the failure modes above. #### Sizing estimate sign-off - [ ] The unit of analysis and revenue unit are stated in one sentence each - [ ] Every component maps to a named proxy with a one-line rationale - [ ] Job-posting counts are de-duplicated and subsidiaries mapped to parents - [ ] Job-posting categories that are gig-heavy are cross-checked against official labor statistics - [ ] Title synonyms are combined, so no single-title count stands in for a two-title pool - [ ] Web-traffic figures have the year's human-share haircut applied - [ ] Registry counts are filtered for active-trading status with dormant entities removed - [ ] Review figures are used only as relative visibility, never as revenue levels - [ ] Search-interest terms clear the ~10,000 monthly-search floor and are averaged over multiple pulls - [ ] Top-down and bottom-up use independent inputs before the 15% rule is applied - [ ] The captured-share scenario stays below the 10 to 15% realism ceiling - [ ] Every row carries a date, an update cadence, and an error-direction note ## Keeping the estimate current A market size is a dated artifact, not a fact, so plan to re-run it rather than cite it forever. The fastest-decaying inputs set the refresh cadence: if your growth read leans on search interest or posting velocity, revisit it monthly, because those signals move and the sampling noise averages out only over repeated pulls. If it leans on registry counts and funding, an annual refresh is enough, since those inputs barely move between filings. Re-check the mechanism, not the value. Bot share, for example, has climbed year over year - from under 50% in 2023 to 53% in 2025 - so the traffic haircut is a moving number; pull the current figure rather than reusing last year's. The same holds for title conventions in a labor proxy: as a category renames itself, the synonym set you combine has to grow with it, which is why re-counting the pool from a live index beats reusing a frozen number. When a category is young, its most sensitive input is which titles or terms even name it yet, and that is precisely the input a stale estimate gets wrong first. ## Frequently asked questions ### How do I size a market from public data without buying a vendor report? Triangulate across public proxies rather than trusting one. Count potential accounts from a business registry or a labor-demand proxy, multiply by a defensible ACV or ARPU, then build the same number top-down from an industry figure and reconcile. If the two methods use independent inputs and land within 15% of each other, you have a defensible estimate. The proxies to combine are job postings, web traffic, registry counts, review volume, search interest, and funding inflow. ### Which public signal proves market demand best? None on its own. Job listings are the best proxy for operational pain, funding inflow signals budget priority, review counts signal relative visibility, and search interest signals near real-time attention. Each over- and under-counts in a known direction, so the reliable read triangulates several and reconciles them. Treat any single-signal TAM as a hypothesis, not a number. ### How much should I discount web-traffic numbers for bots? By roughly the current bot share. Bots were 51% of all web traffic in 2024, the first year automated traffic passed human, and reached 53% in 2025 with bad bots at 40%. Uncorrected traffic overstates human demand by about its bot share, so apply a human-share haircut before treating traffic as demand. Human share was about 50.4% in 2023, 49% in 2024, and 47% in 2025. ### What divergence between top-down and bottom-up means my assumptions are wrong? Two published thresholds disagree, so hold both. The tight rule says results within 15% are trustworthy and a gap over 15% means revisit your ratios. A looser consulting rule says a 2 to 3x divergence signals a structural gap, usually an excluded segment. Reconciling the two estimates is one of the highest-leverage moves in a sizing exercise, but only when the inputs are genuinely independent. ### Why do labor-demand proxies under-count a category? Two reasons. Naming conventions split one pool across titles, so a single-title proxy misses the rest: in Refolk's index US Machine Learning Engineer outnumbers AI Engineer by about 2.35x for largely the same work. Separately, online vacancy data over-represents high-skill roles and misses platform and gig labor, so service categories look smaller than they are. Cross-reference official labor statistics for low-skill categories. --- *From the Refolk guide library. I revise these guides rather than replacing them, so the current version is always at https://www.refolk.ai/guides/demand-signal-market-sizing-reference*