Open a homeowner record and it presents as one thing: a person, with forty facts about them. Name, address, two phones, an email, an age band, an income band, a length of residence, an equity figure, a homeowner flag, a household size.
Those forty fields were not produced the same way, and they do not deserve the same trust. Some were transcribed from a document somebody signed in front of a notary. Some were computed from those documents by arithmetic. Some were predicted by a model that has never seen this household. The record does not label which is which, and the whole practical skill of buying homeowner data is knowing anyway.
Three kinds of field
Every column on a homeowner record falls into one of three tiers, and the tier — not the vendor — sets the ceiling on how much weight the field can carry.
| Tier | How it was produced | Fails by | Safe to use for |
|---|---|---|---|
| Recorded | Transcribed from a document filed with a public office | Being out of date, or transcribed with the clerk’s spelling | Hard qualification. If the deed says it, you can build on it |
| Derived | Computed from recorded fields by a rule you could reproduce | Inheriting every error in its inputs, silently and with compound interest | Ranking, and qualification only when you know the rule |
| Modelled | Predicted from patterns across a population this household resembles | Being right about the average and wrong about the individual | Sorting and prioritisation. Never a hard exclusion |
Notice what the third row implies. A modelled field is not bad data — it is data about a group, printed on a row about a person. Used to decide which two hundred doors a rep walks first, it earns its keep. Used to decide that a household is disqualified, it is throwing away customers on the strength of a statistical resemblance.
Where the common fields actually land
| Field | Tier | What it really is |
|---|---|---|
| Owner name | Recorded | The name on the last recorded deed, as transcribed |
| Mailing address | Recorded | Where the county sends the tax bill |
| Last sale date and price | Recorded | The last recorded transfer — which was not necessarily a sale |
| Homeowner flag | Derived | Usually situs matching mailing, sometimes a homestead exemption |
| Length of residence | Derived | Time since the last transfer, reset by refinances into trusts and by intra-family transfers |
| Estimated equity | Derived from two models | A valuation estimate minus a projected loan balance. Both terms carry error and the errors add |
| Age or age band | Modelled or third-party sourced | Rarely a birth date. Usually inferred from records associated with the identity |
| Household income | Modelled | A prediction from geography and household attributes, not an observation |
| Presence of children, marital status | Modelled | Population-level inference attached to a row |
| Phone number | Resolved | An identity match, not a fact about the property. Its own tier, and its own failure mode |
The fields buyers trust most are the ones doing the most guessing
There is an unfortunate inverse relationship here. The fields that sound most like facts — homeowner, length of residence, equity — are all derived, and they are derived from the same two or three recorded inputs. That means they fail together. A property that transferred into a family trust three years ago will simultaneously report a new owner name, a short length of residence, and a tenure-based model output that treats a thirty-year household as a recent arrival.
The correlation matters because it defeats the instinctive defence. Requiring two signals to agree only helps when the signals are independent, and most of these are not. Two derived fields agreeing is one recorded fact, counted twice.
The phone is its own thing
Contact fields do not fit the three tiers because they are not attributes of the property at all. A phone number arrives on the record through identity resolution: something decided that the owner of record is a specific person and that this person is associated with this number. Two decisions, two chances to be wrong, and neither of them visible in the output.
This is why a homeowner record with a phone on it should always carry line type alongside the number, and why match rate is a poor proxy for anything you care about. Skip tracing accuracy covers the difference between a match and a right-party connect, and skip tracing vs data append covers which of the two operations produced the number in front of you.
Four questions that sort any field in a minute
- What is the underlying source? A named public record, a licensed third-party file, or a model. If the answer is a model, everything below still applies but the ceiling is already set.
- What triggers an update? A recorded event, a refresh schedule, or nothing. Fields that only change when something is re-recorded age in a very specific way: they are right until the day they are badly wrong.
- What does a blank mean? Not present in the source, or present and unknown? Vendors routinely collapse those into the same empty cell, and a filter written against it excludes the wrong rows.
- What does the field do when the input is missing? The honest answer is “returns nothing”. The answer that costs you money is a default that looks like a measurement — a zero equity, a national median income, a length of residence counted from the earliest date in the file.
Question four catches the single most common way a homeowner file misleads a buyer. A defaulted value is indistinguishable from a measured one in a spreadsheet, and it will pass every sanity check you run on the sample.
How to shop with this
Do not ask a vendor for a field list; you will get one and it will be long. Ask for the tier of the six fields your campaign actually depends on, in writing, along with what a blank means in each. A vendor who can answer that quickly is telling you they know how their own file is built. A vendor who treats the question as unusual is telling you something else.
The property-side vocabulary underneath all of this — APN, situs, grantor, deed type, assessed versus market value — is defined in the property data glossary. And once the file is bought, the fields you chose to trust become the fields your CRM will believe forever, which is a separate discipline: data hygiene for CRM imports.
Disclosure: Scout Data sells homeowner data, so we are describing a product category we compete in. Our own file has all three tiers in it, because any homeowner file does. The position we will defend is that the tier should be visible to the buyer — List Builder anchors qualification on the recorded layer and treats the modelled layer as ranking, which is the same advice this page would give about anyone’s data.
Frequently asked questions
Which homeowner data fields are actually recorded somewhere?
A short list: the owner name on the deed, the transfer, the loan instrument, the assessed value, the exemptions, and the building characteristics the assessor captured. Everything else on a typical homeowner record — income, age, equity, length of residence, household composition, marital status, presence of children — is derived from those or modelled from something else entirely.
Is estimated income on a homeowner record reliable?
It is reliable as a sort and unreliable as a gate. Household income estimates are models, and models are built to be right on average across a population rather than right about the person whose door you are knocking. Ranking a territory by estimated income is a reasonable use. Excluding a household because its estimate fell one band short is throwing away real customers to honour a number nobody measured.
Why do two vendors disagree about the same homeowner?
Because most of the fields are not copied, they are produced. Two vendors reading the same county deed will agree on the owner name. Two vendors modelling length of residence, equity or household composition are running different models over different inputs, and disagreement is the expected outcome rather than evidence that one of them is broken. Ask both what the field is derived from before deciding who is wrong.
What does a confidence score on a contact field mean?
Whatever the vendor decided it means, which is why it needs a definition in writing before it is worth anything. Useful questions: is it the confidence that this phone belongs to this person, or that this person matches your input record? Is it calibrated against observed outcomes, or is it an internal ranking? A score that has never been checked against a dialer log is a sort order, not a probability.