How many property attribute fields does a typical AVM feature set use?
If you've ever sat in a model review and watched someone ask "do we really need all these fields," you know the answer is almost always no. Most production AVMs don't run on hundreds of attributes. They run on a tight core, and everything past that core earns its place or gets dropped.
What a typical feature set contains
Strip an automated valuation model down to what the regression or gradient-boosted tree actually weights, and you're usually looking at a schema in the low dozens, not the hundreds. The count clusters around the same handful of categories every time:
- Physical basics: beds, baths, finished square footage, lot size, year built, stories.
- Location and comps: distance to recent sales, school zone, flood zone, census tract, walk score if you license it.
- Transaction history: last sale price and date, assessed value, tax history.
- Market conditions: days on market in the area, inventory trend, price-per-square-foot trend by zip or block group.
That's maybe thirty to fifty fields once you count dummy variables and derived ratios. Add a condition score if your data source has one, and you're still well under the triple digits most people assume a "real" model needs. The feature count isn't the hard part. Sourcing clean values for each field, for every parcel, is.
Where the field count stalls
The part that doesn't show up in the schema diagram is the physical-condition layer. Driveway material, garage presence and size, outbuildings like sheds or ADUs, pool presence, tree cover over the lot, and the general upkeep visible from a photo. These fields sit right next to beds-and-baths on a feature importance chart in plenty of published AVM research, and they're also the fields most portfolios leave blank, estimate from stale permit data, or assign a flat market-average value to across tens of thousands of parcels.
The reason is simple. Nobody's manually reviewing listing photos at scale for a county with four hundred thousand parcels. A field team scoping it by hand would take months and go stale before the report ships. That's a sourcing gap, and it caps your feature set at whatever you can fill in reliably.
What this means for schema size
If you're sizing a new schema or auditing an existing one, count how many of the fields you already list you can populate above a reasonable coverage threshold, portfolio-wide, without a manual review step. That number is usually smaller than the schema suggests, concentrated in the physical-condition category, and the gap doesn't close by adding more fields. It closes by filling the ones already sitting empty.
That's the specific gap Property Attributes is built to close: it adds driveways, garages, outbuildings, pools, tree cover and visible lot condition to the property record from very-high-resolution imagery, delivered as attribute fields keyed to your property IDs and refreshed annually, so the schema you've already built has values in those columns instead of blanks.
If your feature set has a column for lot condition that's been sitting empty since the schema was drafted, it might be worth seeing what fills it.