Methodology · v0.7

Portfolio Size Estimator

The estimator answers a single question: about how many units does this operator actually manage? Operator IQ observes only listing activity — the subset of an operator’s portfolio that hits the open rental market in a given window. A unit only appears when it lists, and it only lists on turnover, so observed units are a fraction of the managed book. The estimator scales that observable signal back up.

The model

The key idea is that turnover differs by unit type. A scattered single-family house re-lists roughly every 3.3 years; an apartment unit turns over faster, roughly every 2.6 years. So each observed unit is scaled by a multiplier keyed to its own type, and the two are summed:

The two multipliers are applied uniformly to every operator, keyed on each unit’s own observed type — not on the operator’s dominant-type label and not on building-level dominance. For a genuine apartment operator, apartment URUs × 2.6 reproduces the declared building count without ever attributing a whole building from a single listing. The multipliers are stored as admin settings (portfolio_k_house, portfolio_k_apt) and applied at seed time, so a change takes effect on the next data refresh.

Why we report a band, not a number

The formula produces a single number, but we don’t show you one. Every surface — scorecard, PDF, comparison table, rankings, export — reports the estimate as one of seven bands:

• <50
• 50–100
• 100–200
• 200–400
• 400–800
• 800–1,600
• 1,600+

The edges are log-scaled and drawn from the actual distribution of estimates across the tracked book — median 170 units, 75th percentile 331 — rather than from round numbers. They spread operators 2.7 / 20.5 / 33.8 / 22.4 / 12.3 / 5.0 / 3.3 percent across the seven bands, so the discrimination sits where operators actually are. The bands do not overlap: every operator falls in exactly one, which is what lets them sort and filter without ambiguity.

Banding is not a presentation preference. It is what the evidence below supports. A point estimate implies a precision this model cannot deliver, and stating one would be a claim we can’t defend to an operator who knows their own count.

What calibration showed

We tested the estimator two ways: across the full book of 4,219 actively-listing operators, and against operators who told us their own unit count directly.

The bias is not one bias — it splits by archetype. Measuring declared building sizes against what we observe, a scattered single-family operator shows 1.4 units per building— a house is its own building, so the declared figure adds nothing we didn’t already see. An apartment-heavy operator shows 37.4, because one observed listing stands for a whole property. Declared unit counts are therefore an informative size signal only for apartment operators, and those are exactly the operators the turnover model handles worst.

Against operator-reported counts, both apartment-heavy:

The decisive result is the last two rows. Even the strongest signal we hold is roughly half the reported count, on both operators. That residual is not a multiplier that needs tuning. It is coverage— units that never list with Dwellsy at all, because they sit with long-staying tenants, lease through channels we don’t see, or belong to a portfolio the operator only partly markets publicly. No multiplier recovers a unit that was never observable.

So the honest reading of any listing-derived size estimate, ours included, is a floor rather than a census. We say so on every surface that shows one.

We have deliberately not recalibrated the multipliers on this evidence. Two ground-truth points, both apartment-heavy, cannot justify moving a number that also governs the ~900 scattered-house operators for whom we hold no validated count at all. Tuning to n=2 would replace a known bias with an unmeasured one. We are collecting more reported counts and will revisit when there are enough to separate archetypes.

Turnover uncertainty, separately

Turnover rates aren’t exact either. Plausible low and high multipliers bracket the defaults — houses roughly 2.5–4.2, apartments roughly 2.0–3.3:

This range is type-aware, and it drives the shaded region on the scorecard’s size bar. It is worth being precise about what it does notrepresent: it captures variation in how fast units turn over, not the coverage gap above. The coverage gap is larger, and it runs in one direction — down. Read the shaded region as the model’s internal uncertainty, not as a claim about how close the estimate is to the truth.

When we don’t estimate

• No listings — an operator with zero observed units in the trailing 12 months gets no estimate.
• Too little history — under three months of observation is too short to project; the scorecard shows the observed count without an estimate.
• No typed units — if no observed unit can be classified as a house or an apartment, there is nothing to scale.

Unlike the earlier cohort-banded model, there is no “insufficient calibration data” refusal for large multifamily operators — every operator with typed trailing-12-month units is estimated on the same uniform formula.

Known limitations

• Coverage is the big one, and it only runs one way. We can scale what we observe; we cannot scale what never listed. On both operators we have checked against a reported count, the gap after every available signal was roughly 2×, and it was always in the same direction — we were low. Treat the estimate as a floor. This limitation is structural, not a bug we intend to fix, because no model can recover a unit it never saw.
• Apartment-heavy operators are understated the most. A single observed listing can stand for a large building. The turnover model scales that one listing by 2.6, which is right for one unit and badly short for a property.
• Mixed-type edge case. A lone apartment or condo held by an otherwise-scattered single-family operator gets the faster apartment multiplier even though it likely turns over slowly. This is a second-order effect on operators whose portfolio is overwhelmingly one type.
• Turnover drift. The multipliers are population averages. An operator that turns over faster or slower than the norm will be over- or under-stated in that direction; the turnover range absorbs ordinary variation, not extremes.
• Context only — not in ranking. The estimate never feeds the composite or star assignments. It exists to give readers a scale anchor, not a precision figure.

Operator-reported counts

When an operator tells us their own unit count, we record it — dated, attributed to how we heard it, and kept alongside what we observe.

It does not change anything you see. A reported count never replaces the estimate, never moves the size band, and never enters cohorts, peer sets, or rankings. Every operator on Operator IQ is measured on the same observed basis, whether or not we have ever spoken to them — the moment that stops being true, no two operators are comparable.

Reported counts exist to be the yardstick the estimator is measured against. A number folded into the estimate can no longer check it.

Estimator version v0.8-house-apt-turnover. Computed at seed time and surfaced on the scorecard; also available through the Ask Operator IQ tools and the market-brief generator. See the full methodology for the rest of the stack.