gtmjosh
Make It Reportable
Chapters
  1. 01 · Start With the Question the Report Must Answer
  2. 02 · Define Clear Statuses
  3. 03 · Capture Milestone Dates
  4. 04 · Preserve Decisions and History
  5. 05 · Define the Reporting Population
  6. 06 · Name the Owner and Source of Each Metric
  7. 07 · Handle Unknown, Missing, and Failed States
  8. 08 · Capstone: Make a Workflow Reportable
Guide overview →

14 min · Interactive exercise

Chapter 7 of 80 complete

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 locally
Reporting-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
Resets every run.
A blank becomes a zero somewhere in the pipeline. What has just happened?
Three reasons a value can be absent. What are they, and do they differ?
Some records are outside the window where the metric means anything.
Chapter 7 of 80 complete