Key takeaways
- Completeness measures whether required information is present for a defined purpose.
- A populated placeholder is not a completed fact.
- Field-level coverage and fully usable record coverage can differ substantially.
Overview
A completeness rate needs a denominator: required cells, eligible records or another clearly defined unit. Placeholders such as “unknown” should not count as useful completed values unless that status is itself the required information. Optional fields should not lower a task’s completeness score simply because they exist in the schema.
How it works
Define required fields for the specific workflow and eligible record set.
Classify missing, invalid, not-applicable and meaningful values separately.
Calculate coverage and route important gaps to enrichment or review.
Define required fields by the next action
A record used for company segmentation may need industry, region and a stable account identifier. A contact handoff may also need a current role and an appropriate channel. Requiring every possible field creates unnecessary work; requiring too few can send unusable records downstream. Start with the decision and distinguish mandatory, optional and conditionally required information.
Define what counts as present. Empty strings, placeholder text, zero values used for unknowns and default dates can all make a dataset appear complete. Preserve explicit missing and not-applicable states. A missing phone number is different from a phone field that the workflow does not need.
| State | Meaning | Possible action |
|---|---|---|
| Missing required fact | The next step cannot be completed as defined | Research, request input or hold the record |
| Optional field absent | The record may still be usable | Proceed without inventing a value |
| Not applicable | The field does not apply to this case | Preserve an explicit state |
| Service failure | The lookup did not establish presence or absence | Use a bounded recovery path |
Measure fields and records separately
An illustrative dataset has 100 records. Eighty have an industry, 90 have a region and 70 have both. Field completeness is 80% and 90%, while completeness for a workflow requiring both fields is 70%. Averaging the two field percentages does not tell the receiving team how many records it can actually use.
Break the result down by source and segment. A low overall phone coverage rate may be acceptable for an email-only workflow, while a small missing-account-ID rate can block an entire import. Use the required-field intersection as an operational measure and retain field-level coverage to diagnose the gaps.
Fill gaps according to value and evidence
Prioritize fields that change eligibility or unblock a handoff. A waterfall enrichment process can attempt unresolved fields under a budget, but its stopping rule should require an accepted value rather than any returned text. If reliable evidence is unavailable, leave the field unresolved and make that limitation visible.
Monitor whether additional completeness improves the outcome. Adding ten optional attributes may not help a salesperson if the current role remains unknown. Also inspect accuracy after filling gaps: an apparent move from 80% to 100% completeness achieved with guesses can make the dataset less useful. Completeness is one dimension of quality, not a substitute for the others.
What this looks like in practice
Of 100 eligible companies, 82 have a usable industry classification. Industry completeness is 82% for that sample; this says nothing about whether those 82 classifications are correct.
Examples explain the concept; they are not reported customer results.What to check
Report per-field coverage and the share of records meeting all required conditions. Check whether exclusions or placeholders artificially inflate the result.
Common mistake
Counting a field as complete because it contains any string, including a default, an error message or an unverified guess.
Data completeness vs. Data accuracy
Completeness measures presence. Accuracy measures correctness. A complete dataset may be wrong, while an accurate subset may still lack enough coverage for the task.
Read the Data accuracy definition →Questions answered
What is Data completeness?
Data completeness measures whether the fields or records required for a particular use are present, using an explicit definition of what counts as a meaningful value.
Is 100% completeness always the goal?
Only for fields genuinely required by the task. Collecting unnecessary information can increase cost, risk and maintenance without improving the outcome.
How should not-applicable values be counted?
Define them separately from missing values and state whether they belong in the denominator. The rule should reflect the intended use, not a desire for a higher score.
How should conditionally required fields be measured?
Define the population where the condition applies before calculating coverage. A business-unit identifier may be required only for accounts with several units. Report completeness within that eligible subset and preserve not-applicable states elsewhere. Treating every record as missing the field would misrepresent the operational gap.
Should missing values be replaced with defaults?
Use defaults only when they have a defined operational meaning and cannot be mistaken for observed facts. A default routing queue may be appropriate; an invented employee count is not. Preserve the distinction between a system fallback and a real-world value supplied by evidence.
References and further reading
Primary documentation and source material for this topic. Sources checked September 14, 2026; provider requirements can change.
Continue reading on the blog
Explore all articles and guides →Put the concept to work.
Explore the relevant AstroFabric workflow and see how the pieces connect.
Help keep this guide useful. Suggest a correction or browse the full glossary.