A country data coverage checklist looks like a simple artefact until the first argument about a number. Two people count the same dataset, get two different totals, and neither is wrong. The disagreement is almost never about arithmetic; it is about what was being counted and who decided that a blank cell was a problem.
This article treats the checklist as a measurement instrument. It covers the three states a field can be in, the choice of denominator that makes a percentage meaningful, and the shape of a list that someone else can audit without asking you what you meant.
What should a coverage checklist actually count?
The honest answer is that it counts agreements, not values. For each combination of a country and a field, the checklist should record whether the data model’s expectation and the country’s reality line up.
That framing changes what a gap looks like. A blank cell is not automatically a defect, and a filled cell is not automatically coverage. The unit being measured is a decision: for this country, is this field supposed to hold something, and does it? Everything else in the checklist follows from answering that question per country rather than per table.
A checklist that reports a single headline figure is nearly useless for this reason. It summarises thousands of decisions into one number and discards the information a reader needs in order to act.
The three states: applicable, not applicable, missing
Three states have to be tracked separately, and collapsing any two of them is what makes coverage figures flatter than reality.
| State | Meaning | What it demands |
|---|---|---|
| Applicable and present | The country has this kind of data and a value is stored | Nothing, beyond keeping it current |
| Not applicable | This country’s system has no such field at all | An explicit mark, so nobody hunts for a value that cannot exist |
| Missing | The country should have a value and does not | A fix, an owner, and a date |
The middle state is the one that gets lost. When it is recorded as an empty cell, it later reads as a gap, and someone spends a week trying to fill something that has no source. When it is recorded as a value — a placeholder such as a zero or an empty string — reports downstream inherit a fake fact and treat it as real.
Recording the three states distinctly is also what keeps the denominator honest. Coverage measured over applicable fields answers one question; coverage measured over all fields answers another, and only the first one ever improves.
Should coverage be measured per country or per field?
Both, and the choice must be written down, because the two figures can disagree sharply.
Per country, the question is how completely a given country is represented. Per field across countries, the question is whether a field is broadly usable or exists for a handful of entries. A field that is present everywhere except one region looks excellent per field and looks like a hole per country.
Two conventions prevent most confusion. State the denominator in the heading of the table rather than in a footnote. And keep weighted and unweighted figures apart: weighting by traffic, by revenue or by record count answers a business question, while counting countries answers a data question. A checklist that mixes them produces a number nobody can defend.
The minimum field set and everything above it
Start with the fields that essentially every country has a form of — a code, a name, a currency, a time zone — and call that the minimum set. Measure it first and publish it separately.
The reason is signal to noise. Optional fields differ so much between countries that a single blended total tells you almost nothing about either group. Keeping the minimum set in one block means a failure there is a real warning, while a thin optional field can be discussed on its own terms.
Above the minimum set, list each optional field with the countries where it applies, the countries where it does not, and the countries where the answer is still unknown. That third column is the part most checklists omit, and it is usually the most useful, because it is a work queue rather than a verdict.
How do you record a country with more than one official language?
A country with several official languages breaks the assumption that each row holds one value per column. Whether the language column is single-valued or multi-valued is a modelling decision, and it should be made before the first row is entered rather than after the first report comes back wrong.
If the column holds one value, something else — a separate table or an explicit rule — has to carry the rest, and the checklist must say which. If it holds several, every count in the sheet has to be clear about whether a country with several values contributes one row or several, because that choice changes every total below it.
The same question applies to currency and to division names, which are equally capable of being plural within one country. The checklist does not have to resolve the modelling debate, but it does have to record which answer was chosen, so that a later reader can tell a decision from an oversight.
For developers: make the checklist queryable
A checklist that lives in a document is read once and abandoned. A checklist that can be queried is checked in a pipeline and stays true.
Represent it as data: one record per country and field, with the state, the source, the date the state was established, and the owner. Then the questions that matter become ordinary queries. Which countries are missing a field that the minimum set requires? Which fields changed state since the last release? Which countries have had an unknown state for longer than one release cycle?
Keep the unknowns visible rather than filtering them out. An unknown that is hidden behind a default is the most expensive kind, because it silently counts as whatever the default implies. And when you hand a reader towards the underlying country notes, the country and region directory is the neutral place to point them, while a page such as the Germany entry shows the level of detail a single country is expected to carry. For the underlying coding questions, the guide to ISO country and subdivision codes covers the code side that this checklist deliberately leaves alone.
Everything shown here is illustrative. The field names, states and example values in this checklist are synthetic material written for a testing discussion, not a measurement of any real system, organisation or dataset, and they should not be quoted as a finding.
Next steps
Build the first version of the checklist for one field you already trust and one field you suspect, and put them side by side. The contrast usually shows within an hour whether the sheet is measuring anything. When the checklist is stable, the guide to scaling test data across countries picks up where measurement stops, and the guide to choosing countries for test data explains how the country list underneath it should be chosen in the first place.