The Demand-Signal Reference for Sizing a Market Category

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.

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.

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.

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.

Second, geography swings the same title fourfold. The identical "Data Analyst" title returns very different densities across two mature markets.

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.

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.

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.

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.

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.

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.

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.

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 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.

Proxy: <e.g. aggregate job postings>
Raw value + date: <number as of YYYY-MM-DD>
Cleaning applied: <de-dup / subsidiary map / bot haircut / dormant filter>
Reduction factor: <e.g. -22% after de-dup>
Update cadence: <daily / near real-time / annual / event-driven>
Error direction: <over-counts because ... / under-counts because ...>
Trust: <high / medium / low, and why>

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.

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.