Completeness

The hardest data failure to notice is not a wrong value but a missing one. Wrong values announce themselves — negative revenue, a signup born in 1900, and somebody says something within the hour. But when 1,100 rows that should have landed yesterday never arrive, the screen looks fine. The line on the chart simply sits lower, and a lower line does not read as absent data. It reads as a metric getting worse.

So meetings used to take a full lap before finding their way back. Signup conversion looks down in the Monday review, two days go into finding out why, and the answer turns out to be one ad channel that stopped sending events. For those two days the team investigated a problem that did not exist, while the real one — the broken pipe — sat untouched and kept dropping data.

Completeness is the number teams started tracking to catch that before a human does. Data quality covers everything involved in keeping data trustworthy, and within it completeness watches exactly one direction. It asks whether anything is missing, and nothing else.

Divide the slots that are actually filled by the slots that should be filled, and read it as a percentage. There are two kinds of slot, so in practice teams track two separate numbers.

1. Column completeness — the share of rows in one column that are not empty. If 9,400 of 10,000 payments carry a country value, that column is at 94 percent. This matters because every breakdown that uses the column goes wrong together: a revenue-by-country view leaves those 600 payments out of every bucket, so each total comes in low.
2. Row completeness — how many rows arrived against how many were expected. The expected figure usually comes from the average of the same weekday over the last four weeks. Four Tuesdays at 3,050, 2,980, 3,100 and 2,970 rows put the expectation at 3,025, so yesterday's 1,900 rows read as 63 percent.

The two stay separate because they point at different breakages. A drop in column completeness means whoever sends the data left that field out. A drop in row completeness means the sending stopped altogether. The first sends you to the tracking code or the integration settings; the second sends you down the whole collection path, from the client that emits the event to the job that loads it.

One trap is that missing values do not always look missing. Plenty of systems write 0 or "unknown" or a dash where there is no value, which pushes completeness to 100 percent while quietly dragging averages down as those zeros get counted. Decide how a table spells "no value" before measuring it.

Set the threshold per column. A single target applied across a whole table almost never works. A column like payment amount, where an empty cell breaks the arithmetic, has to be at 100 percent. A column like signup source, which users can skip, can sit at 70 percent and be perfectly healthy. Demand 100 percent of the second one and the alert fires daily, and a daily alert gets switched off within a month.

Direction matters more than level. A country column steady at 94 percent for three months is a property of how collection was designed, and analysis can account for it. The same column sliding from 94 to 81 percent in three days is a change, and the cause is usually in whatever shipped just before. That is why alerts watch the drop against a baseline rather than the absolute value.

Thresholds vary by table, but two tiers make a reasonable starting point. Below 90 percent of expectation, notify the owner. Below 70 percent, put a warning on any dashboard built from that table so nobody uses the day's numbers in a decision. Marking a number as untrustworthy beats hiding it — when a number is on the screen, people use it. Write the warning with specifics, as in "yesterday's data arrived at 63 percent." A warning that only says the data is unreliable leaves the reader with no idea how much to discount, so they end up ignoring it.

"Event completeness was 63 percent yesterday, so don't read today's dashboard at face value."

The metric didn't drop; the data did. Hold off on interpreting it.

"Country completeness went from 94 to 81. It starts right after last week's release."

Pinning the cause to a specific change and asking someone to confirm.

"That field is optional, so 70 percent is normal here. Please lower the alert threshold."

The gap is design rather than breakage, so the baseline is what needs fixing.

At Pagedeck, this is the first screen Mia opens on Monday morning. Last Tuesday row completeness came in at 71 percent, and she kept that week's active-user chart out of the meeting. Theo traced it to an app release that had renamed one event; once the new name was added on the collection side, volume was back in the 3,000s the following day. The missing day could not be recovered, so that week's chart still has a gap where it was.

The most common mistake is reading high completeness as accurate data. A table with every cell filled looks healthy, so the assumption comes easily. But this number only asks whether a slot was filled, never what filled it. If every row has "KR" in the country column, completeness is 100 percent — and if that value is a default being written automatically, every country breakdown built on it is wrong. Lean on the number alone and the table passes its checks for months while returning wrong answers.

Chasing 100 percent is the other one. No missing data sounds like the ideal state, but filling columns users deliberately skipped means making those inputs required. Drop-off on the signup screen goes up, and the people who stay pick whatever option gets them past the field. Fewer blanks, more wrong values, and analysis ends up harder than it was. A column at 70 percent with honest answers tells you more than one at 100 percent where a third of the rows say whatever cleared the form fastest.