Skip to content This library is free, offered as dana. If it helps your work, donate here →
penguin tree ai
← back to libraryDonate here

This is one of 3,622 free prompts in the penguin tree ai library. Sign up once and the whole library opens, with new prompts by email.

open the library →

Data quality metrics dashboard requirements builder

Builds a structured data quality dashboard requirements document defining metrics (fill-rate, accuracy, freshness, cost-per-record, pipeline reliability), acceptance criteria per segment, calculation logic, data…

download .md

Purpose

Translate vague "we need better data quality visibility" requests into a precise, buildable requirements document — with defined metrics, calculation logic, per-segment acceptance criteria, and alert thresholds — so a BI or reporting partner can build the dashboard without a dozen clarifying calls.

When to Use

Invoke this skill when the user asks to:

  • Scope or spec a data quality dashboard for a BI/reporting team
  • Define data quality metrics (fill-rate, accuracy, freshness, cost-per-record, pipeline reliability)
  • Set acceptance criteria or SLAs for data quality by segment
  • Write requirements to hand off to an analytics engineer or BI partner
  • Establish thresholds and alerting for a data pipeline or CRM data health
  • Standardize how data quality is measured across records, accounts, or segments

Inputs Required

Before starting, collect:

  • Data domain: What data is being measured (e.g., CRM accounts, lead records, product usage events, enrichment data)
  • Primary systems/sources: Where the data lives (Salesforce, HubSpot, warehouse tables, enrichment vendor feeds)
  • Segments to track separately: How data should be sliced (e.g., by region, tier, source, record type, owner team)
  • Key fields that matter most: The 5–15 fields where quality has business impact (e.g., email, industry, employee count, MRR)
  • Consumers of the data: Who relies on it downstream (SDRs, forecasting, routing, marketing ops)
  • Existing SLAs or pain points: Known problems or targets already agreed upon
  • BI/reporting stack: The tool the dashboard will be built in (Tableau, Looker, Power BI, Sigma, etc.)

If segments or key fields are missing, propose a sensible default set and flag it as an assumption for the buyer to confirm.

Instructions

Step 1: Confirm Scope and Segmentation Grain

Establish the unit of analysis before defining any metric.

  • Grain: Is quality measured per record, per account, per event, or per field?
  • Segmentation dimensions: List the 2–4 dimensions each metric will be sliced by (region, tier, source, owner).
  • Reporting frequency: Real-time, daily snapshot, or weekly rollup — this drives freshness expectations.
  • State the grain explicitly at the top of the output; every metric below inherits it.

Step 2: Define the Five Core Metric Families

For each of the five families, produce a metric definition block with: Metric name, What it measures, Calculation formula (in plain SQL-like pseudocode), Data source(s), Segmentation applied, and Refresh cadence.

Family 1 — Fill-Rate (Completeness)

  • Percentage of records where a required field is populated with a non-null, non-placeholder value.
  • Formula pattern: COUNT(records WHERE field IS NOT NULL AND field NOT IN ('', 'N/A', 'unknown')) / COUNT(records) per segment
  • Define completeness per key field AND a weighted composite fill-rate across the field set.

Family 2 — Accuracy (Validity/Conformance)

  • Percentage of populated values that conform to expected format, range, or reference list.
  • Formula pattern: COUNT(records WHERE field MATCHES validation_rule) / COUNT(records WHERE field IS NOT NULL)
  • Specify the validation rule per field (email regex, employee-count range, industry in picklist, domain resolves).

Family 3 — Freshness (Timeliness)

  • Age of the most recent update relative to expected refresh cadence.
  • Formula pattern: NOW() - MAX(last_modified) per record/segment; report % of records updated within SLA window.
  • Distinguish source freshness (when the pipeline last ran) from record freshness (when a record last changed).

Family 4 — Cost-per-Record (Efficiency)

  • Total data acquisition/enrichment/maintenance cost divided by records processed or held.
  • Formula pattern: SUM(enrichment_spend + tooling_cost) / COUNT(records) per source/segment
  • Include a cost-per-usable-record variant (cost / records passing accuracy + fill thresholds).

Family 5 — Pipeline Reliability (Operational Health)

  • Success rate and stability of the jobs feeding the data.
  • Metrics: job success rate (successful_runs / total_runs), duplicate rate, row-count variance vs. prior run (%), and SLA-miss count.
  • Flag anomalies where row counts deviate more than a defined % from the trailing average.

Step 3: Set Acceptance Criteria Per Segment

Build a segment × metric matrix. For each metric family, define three thresholds per segment:

  • Target (green): the desired state
  • Acceptable (yellow): tolerable but monitored
  • Breach (red): triggers action
  • Higher-value segments (top tier, primary regions) warrant stricter thresholds than long-tail segments — make this explicit rather than applying one flat standard.

Step 4: Define Alerting and Ownership

For each red-threshold breach, specify:

  • Trigger condition (metric + threshold + segment)
  • Alert channel (Slack, email, dashboard flag)
  • Owner (which role investigates)
  • Escalation window (how long before it escalates)

Step 5: Specify Dashboard Layout for the BI Partner

Describe the intended views so the reporting team can build directly:

  • Executive summary tile: composite health score per segment, RAG-coded
  • Metric drill-downs: one view per metric family with segment filters
  • Trend view: each metric over time (rolling 90 days minimum)
  • Breach log: table of current and recent threshold violations
  • List required filters, default date range, and any calculated fields the BI tool must create.

Output Format

  • Structure: A requirements document organized in five parts — Scope & Grain, Metric Definitions, Acceptance Criteria Matrix, Alerting & Ownership, Dashboard Layout Spec
  • Length: 1,000–1,500 words
  • Format: Structured document with metric definition blocks, one acceptance-criteria table (segment × metric with three thresholds each), and a bulleted layout spec
  • Sections: Scope & Segmentation Grain → Core Metrics (5 families with full definition blocks) → Acceptance Criteria Matrix → Alerting & Ownership → Dashboard Layout Spec → Open Questions for the BI Partner
  • Tone: Data ops manager writing a handoff spec — precise, unambiguous, formula-first; no marketing language

Quality Checklist

Before delivering output, verify:

  • [ ] All five metric families are defined (fill-rate, accuracy, freshness, cost-per-record, pipeline reliability)
  • [ ] Every metric includes a calculation formula in SQL-like pseudocode — not just a description
  • [ ] The acceptance criteria matrix includes three thresholds (target/acceptable/breach) for every segment
  • [ ] Segmentation grain is stated once and applied consistently across all metrics
  • [ ] Every red-threshold breach has an assigned owner and alert channel
  • [ ] Dashboard layout spec names specific views, filters, and calculated fields the BI tool must create

Notes

  • Accuracy is the metric most often skipped because it requires validation rules — push the buyer to define at least a format or reference-list rule per key field, since fill-rate without accuracy overstates health.
  • Freshness commonly conflates pipeline-run time with record-change time; keep them as separate metrics or the dashboard will hide stale-but-recently-touched records.
  • One flat threshold across all segments is the most common spec mistake — tiered acceptance criteria are what make the dashboard actionable for a RevOps team.
  • If the BI tool can't compute a metric server-side (e.g., cost-per-record spanning finance and CRM data), note it as an "Open Question for the BI Partner" rather than assuming it's buildable.

How to use this skill

This file is a Claude Code skill in Anthropic's standard format — markdown with YAML frontmatter at the top.

Installing in Claude Code:

  • ~/.claude/skills/<folder-name>/SKILL.md — auto-loads in every session anywhere on your machine (recommended for skills you'll use across multiple projects)
  • <your-project>/.claude/skills/<folder-name>/SKILL.md — auto-loads only when working in that project (recommended for project-specific skills)

Restart Claude Code or open a new session to register.

Using in Claude.ai, ChatGPT, Gemini, or other AI tools:

  1. Drag this file into a new chat, or copy and paste its contents
  2. Send your task or request as your next message — the AI will apply the skill where it fits

For Claude Code skill details: https://docs.anthropic.com/en/docs/claude-code/skills