Chapters
- 01 · Start With the Question the Report Must Answer
- 02 · Define Clear Statuses
- 03 · Capture Milestone Dates
- 04 · Preserve Decisions and History
- 05 · Define the Reporting Population
- 06 · Name the Owner and Source of Each Metric
- 07 · Handle Unknown, Missing, and Failed States
- 08 · Capstone: Make a Workflow Reportable
14 min · Interactive exercise
Handle Unknown, Missing, and Failed States
Three different absences, represented three different ways, so none of them reads as zero.
This is the chapter the whole guide has been walking toward.
A record can fail to have a value for at least three genuinely different reasons, and almost every reporting system collapses all three into one, which is usually zero or blank.
Unknown. The process ran correctly and the answer is not determinable. This is a real answer. Missing. The value should exist and does not, because something was not captured. This is a defect. Failed. The process did not complete. This is an incident.
Three different things demanding three different responses, and stored identically they become one thing demanding none.
Zero is a claim
If a blank becomes a zero anywhere in your pipeline, you have made a factual assertion you have no evidence for. Zero means “we measured, and the answer was none.” Blank means “we do not know.” A system that turns the second into the first is fabricating, in exactly the sense Show the Reasoning used the word.
The consequences are not subtle. Averages shift toward zero in proportion to how much data is missing, which means the worse your capture, the better your worst segments look, because their missing values pull the mean of everything else down toward them. Segments get compared. Decisions follow.
Not scored is a legitimate third value
Some records are outside the window where a metric is meaningful. A renewal far in the future. A record too new to have had the chance. A population the metric was not designed for.
The right treatment is to leave them explicitly not scored, and to make that look different from both good and bad on every surface. A blank says “not applicable”. A zero says “dead”. Two of the better systems in this space do this deliberately, and both had to be changed to do it, because the first version scored everything.
The stored final value that means “not captured”
When a live calculation stops at the end of a record's life and a final value is stored, records where that field was never populated will read as zero. That zero means “never captured” and it will be read as “was bad”, forever, by every historical analysis anyone ever runs.
Either backfill it, or exclude those records from historical analysis by rule, or document it so loudly that nobody can miss it. Doing none of the three is the default.
GTM Lab
Saved locallyReporting-Ready Process Specification · 0 of 8 sections started
Saved locally to your browser.
Three absences, three meanings
In the situation above, the segment with the worst data capture looks the best, and somebody is about to be sent to fix the wrong team. Separate the three kinds of absence.
Fixture: blank-becomes-zero
The segment that looks best because it captured least
FIXTURE-BLANK-BECOMES-ZERO- Segment A
- Good capture, honest average
- Segment B
- Poor capture, many blanks
- Blanks treated as
- Zero
- Effect on the overall mean
- Pulled toward zero by B
- Who gets sent to fix things
- Segment A