Distinct values in the email field. This is not automatically a count of unique people.
Dataset transparency
California Realtor Database Methodology
This page separates the California product facts supported by the current dataset record from operational details that still require documentation. It is a working transparency record, not a claim that every methodology control is complete.
- Real snapshot dates only
- Field metrics defined separately
- Unknown methods labelled as pending
Current product record
What the published snapshot supports today
The homepage API supplies a real snapshot timestamp and field-level unique totals. Those totals describe coverage by field; they should not be added together or treated as a single count of people.
California dataset snapshotAugust 24, 2026
The approved schedule is monthly. The current API does not expose whether each cycle is a full rebuild, incremental update or a combination of both.
Distinct values published in the cell-number field.
Distinct values published in the phone-number field.
Distinct office-address values; multiple professionals can share one office.
Distinct values published in the license-number field.
Distinct values published in the fax-number field.
Methodology controls
Documented, partial and pending evidence
A public methodology should show gaps as clearly as completed controls. These statuses reflect evidence available in the current frontend, product response and approved planning inputs.
| Methodology topic | Status | Evidence available today |
|---|---|---|
| Collection scope | Partial | California coverage totals and the included field list are published; row-level inclusion criteria and source dates are not exposed. |
| Source categories and permissions | Pending | The current frontend and product response do not identify source categories, licenses, permissions or acquisition dates. |
| Normalization | Pending | Formatting rules for names, addresses, phones, counties and license values are not documented in the current system. |
| Deduplication | Partial | Published metrics are labelled as unique by field, but matching keys, merge rules and cross-field deduplication are not documented. |
| Email and mailbox validation | Pending | No reproducible validation date, tool, test log, mailbox classification or denominator is available in the product response. |
| Manual review | Pending | Reviewer roles, exception criteria, sampling method and approval records are not currently published. |
| License-data handling | Partial | License type and number are included fields, but source jurisdiction, status interpretation and refresh rules need confirmation. |
| Suppression and deletion | Partial | Privacy and CCPA pages exist and support can receive requests; a dataset-level suppression workflow and audit trail still need documentation. |
| Update frequency | Partial | A recurring monthly schedule and snapshot timestamp are approved, but full replacement versus incremental-update steps are not documented. |
Monthly release standard
The auditable process this page must ultimately document
The monthly schedule is an approved product fact. The following controls are the minimum release standard being established; they are not represented as a completed historical process until operational records confirm them.
- 1
Record the real snapshot
Store a dataset identifier and UTC publication or verification timestamp rather than generating a freshness date in the browser.
- 2
Recompute field metrics
Count unique values separately for email, fax, cell, phone, office and license fields and preserve the calculation output.
- 3
Approve evidence and exceptions
Review validation evidence, unresolved records, exclusions and the customer-facing claim before publishing the new snapshot.
Deliverability evidence gate
A percentage needs a reproducible denominator and test record
The website currently publishes a more-than-97% email deliverability commitment. The present API and repository do not include enough evidence to independently reproduce that percentage, so this page does not describe it as a completed measurement.
The older Terms page still states a different 95% replacement threshold, while legacy FAQ copy includes 96%. Those pages and the final refund or replacement calculation must be reconciled before this methodology becomes indexable. Review the current conflict and pending decisions on the accuracy policy page.
Required validation record
- The exact validation date and the dataset version tested
- The validation tool or procedure and whether mail was actually sent
- The denominator and any excluded addresses
- Treatment of accept-all domains and role-based addresses
- Treatment of temporary failures, throttling and unknown results
- Classification of hard bounce, soft bounce, block and complaint events
- The time period during which the measured rate is expected to apply
- Evidence, threshold and calculation used for replacement or monetary remedy requests
Known limitations
What not to infer from the current metrics
- A unique email, phone, office or license value does not necessarily represent one unique person.
- Field totals have different denominators and should not be summed into a total contact count.
- The snapshot timestamp is product-level and is not proof that every record was checked on that date.
- Location products do not yet expose verified boundary, included-area or record-level update information.
Questions and corrections
Contact supportRequest clarification or report a concern
Contact support about field definitions, a correction, suppression or deletion request, or evidence needed for an invalid-contact review. Review the current Privacy Policy, CCPA information and Terms & Conditions before purchasing or using the data.