Good enough vs perfect data

It is 4:55 p.m. Leadership wants a churn answer by morning. Your pipeline has a two-day lag, three product teams disagree on who counts as a “customer,” and free trials are still mixed into the paid table. Someone will say the words that freeze every analyst: “We should wait until the data is perfect.”

Perfect never shows up. Good enough does. This part of Analytics foundations is about knowing the difference, saying it in plain language, and still making a decision you can defend on Monday.

What you’ll learn

• What “good enough data” means for a workplace decision (not for a PhD thesis)
• A simple continuum from pure guesswork to overkill polish
• Confidence language that non-stats people can use without faking precision
• When waiting is smart, and when it is just fear wearing a lab coat
• A short quality checklist and SQL sketch you can reuse

Perfect is not a data plan

In school, wrong answers get red marks. At work, late answers can cost more than slightly wrong ones. That does not mean “ship garbage.” It means the standard is: is this accurate enough for the decision in front of us, with the cost of waiting included?

In What problem are we actually solving? we started with the decision, not the warehouse. Here we ask a follow-up: how solid does the evidence need to be for this decision? Repricing a whole product line needs more certainty than choosing which onboarding email to A/B test next week.

Data quality experts talk about dimensions like accuracy, completeness, consistency, and timeliness. Those words are useful. They are also incomplete without a decision. Completeness of 99% sounds great until the 1% missing is your highest-value customers. Completeness of 80% can be fine if the missing rows are random noise and the question only needs a direction of travel.

A continuum, not a cliff

People talk as if data is either “ready” or “not ready.” Reality is a spectrum. Think of five zones. You do not need a statistics degree to place yourself on it. You need honesty about the decision and the holes in the data.

1. Guess

No measurement, or the measurement is so broken you are basically storytelling. Fine for brainstorming. Dangerous if you present it as analysis.

2. Directional

You can say “up or down,” “Region A looks worse than Region B,” or “this channel is not the hero.” Definitions may be messy. Good for prioritization and for deciding where to dig next.

3. Good enough

Core definition is documented. Known biases are named. The answer would not flip if you fixed the small holes tomorrow. This is where most operational decisions should live.

4. High trust

Audited definitions, monitored pipelines, clear owners. You need this for regulated reporting, executive OKRs that drive bonuses, and anything that will be compared month after month in public.

5. Overkill

You are polishing a metric while the decision window closed last week. Overkill is not “being thorough.” It is spending certainty budget you do not need.

The three questions that unlock “good enough”

Before you open another dashboard, answer these out loud (ideally with the person who asked for the number).

1. What decision will change? If nothing changes either way, you are decorating a slide, not analyzing.
2. What would flip the decision? If the number needs to move from 3% to 30% to matter, a fuzzy 3-ish is fine. If 3.1% vs 2.9% rewrites the plan, you need sharper work.
3. Is the decision reversible? Cheap tests can run on directional data. Irreversible spend, layoffs, or legal commitments need higher trust.

These three map cleanly to the analytics loop: question, evidence, decision, then measure again. Good enough is loop-friendly. Perfect is loop-hostile because the loop never starts.

Worked example: the “almost churn” report

Scenario: a product lead wants monthly paid churn for a board update. You know free trials leak into the paid table for about 4% of rows, and refunds lag by a week. Board meeting is tomorrow.

Notice the good enough path is not sloppy. It is specific. It names the bias, gives a usable number, and sets a cleanup date. That is professional. Pretending the number is laser-perfect is not.

Confidence language for non-stats people

You do not need to say “95% confidence interval” in a sales standup (unless that room already speaks stats). You do need to stop sounding either more certain or more hopeless than the data allows.

A few phrases that work in real meetings:

• “Directionally…” when you trust the sign, not the third decimal.
• “Best estimate, known bias: …” when the hole is known and bounded.
• “Not decision-ready for X, decision-ready for Y.” Example: not ready to reprice, ready to pick which region to investigate.
• “If the missing 5% were all worst case, the decision still holds.” Sensitivity in plain English.
• “I would bet a lunch on this, not the budget.” Informal, memorable, honest.

If you do use a formal interval, keep the interpretation humble. A 95% confidence interval is a way to express uncertainty around an estimate from a sample. It is not a promise that “the truth is inside these two numbers with 95% probability” in the casual sense people wish it meant. For most business rooms, a clear range plus a named bias beats a misused interval every time. For careful scientific wording of intervals, see resources like the Cochrane Handbook discussion of imprecision and intervals.

A practical quality checklist (before you hit send)

This checklist is small on purpose. Ten-page data quality frameworks die in drawers. Six questions that fit on a sticky note get used.

A lightweight SQL quality sketch

You do not need a full observability platform to refuse false precision. A few checks on the extract you are about to trust go a long way. Here is a simple pattern: count rows, flag known junk, and measure how big the junk is relative to the total.

-- Sketch: how big is the known mess before we quote churn?
WITH base AS (
  SELECT
    customer_id,
    plan_type,
    canceled_at,
    is_trial,
    refunded_at
  FROM analytics.customers
  WHERE as_of_date = DATE '2026-07-01'
),
flags AS (
  SELECT
    COUNT(*) AS n_customers,
    COUNT(*) FILTER (WHERE is_trial) AS n_trials_mixed,
    COUNT(*) FILTER (WHERE refunded_at IS NOT NULL) AS n_refunds,
    COUNT(*) FILTER (WHERE canceled_at IS NOT NULL) AS n_canceled
  FROM base
  WHERE plan_type <> 'internal'
)
SELECT
  n_customers,
  n_canceled,
  ROUND(100.0 * n_canceled / NULLIF(n_customers, 0), 1) AS churn_pct_raw,
  ROUND(100.0 * n_trials_mixed / NULLIF(n_customers, 0), 1) AS trial_mix_pct,
  ROUND(100.0 * n_refunds / NULLIF(n_customers, 0), 1) AS refund_pct
FROM flags;

If trial_mix_pct is 0.2%, you can usually quote a single number and mention the residual. If it is 12%, you either clean first or report a cleaned vs raw pair. The SQL is not magic. The decision rule is: size the bias before you narrate the metric.

When waiting is the adult move

“Good enough” is not a free pass to be lazy. Wait (or dig harder) when:

• The decision is hard to reverse and expensive.
• You discovered the metric definition is contested among stakeholders (you do not have one problem; you have three).
• Ethics, privacy, or legal reporting is involved.
• A known bug could flip the sign of the result, not just the second decimal.
• You are about to automate the number into a dashboard that people will treat as ground truth for months.

In those cases, your job is still not “become perfect.” Your job is to name the blocker, estimate the fix, and offer a temporary directional view if one is safe.

Common mistakes

• False precision: reporting 12.473% because the spreadsheet showed it.
• Silent caveats: you know the trial mix problem; the slide does not.
• Perfection as avoidance: endless cleaning to avoid a hard recommendation.
• One number for every audience: finance, product, and support may need different grains. Say so.
• Confusing data vs information vs insight: a clean table is still not a decision. See Data vs information vs insight.

How to practice this week

1. Pick one metric you already report. Write its definition in one sentence.
2. List the two biggest known data holes. Size them if you can (even roughly).
3. Rewrite your last update in confidence language: direction, caveat, decision implication.
4. Ask the stakeholder: “What would flip this decision?” Write the answer down.

Quick recap

Good enough data is not mediocre data. It is evidence that matches the stakes of the decision, with biases named and next fixes owned. Perfect data is a myth that delays learning. Use a continuum, run the flip test, speak with honest confidence, and keep the analytics loop moving.

Next in the series: Reading a number like an adult (rates vs counts, denominators, “compared to what?”, seasonality in one page). Related already live: All About KPIs and What is Data Literacy.

Sources

• Cochrane Handbook, Chapter 15 (interpreting results, confidence intervals, imprecision): https://www.cochrane.org/authors/handbooks-and-manuals/handbook/current/chapter-15
• DAMA International, data quality dimensions (accuracy, completeness, consistency, timeliness, and related concepts) in the DAMA-DMBOK body of knowledge: https://www.dama.org/cpages/body-of-knowledge
• Statsig, plain-language overview of confidence intervals in product and experimentation contexts: https://www.statsig.com/perspectives/confidence-intervals-how-they-help
• Analytics Made Simple, series links used above: problem framing, data vs information vs insight, analytics loop, KPIs, data literacy.

More definitions in Key Terms →

Merch on Etsy

Open store →

Python Coder Shirt View on Etsy → Sigmoid Function Shirt View on Etsy → ETL Data Science Shirt View on Etsy → Apache Flink Shirt View on Etsy →