Problem Statement
Teams across the organization rely on inconsistent metric definitions, causing confusion, duplicated work, and conflicting dashboards. The goal is to standardize disputed metrics into a single, trusted glossary with clear SQL definitions, filters, grain, and known caveats. The workflow must also define canonical dimensions, governance rules, and a stakeholder announcement to drive alignment.
Steps
Ingest Inputs
INGESTCollect product area details, current dashboards, disputed metrics, and any existing metric definitions. Extract all metric names, references, and dependencies to prepare for conflict resolution.
Resolve Conflicts
EXECUTEIdentify conflicting definitions, ambiguous naming, and inconsistent filters or grains across dashboards. Propose consolidated canonical definitions with clear trade‑offs and documented known caveats.
Define Grain, Filters, and Dimensions
EXECUTEEstablish the SQL definition, required filters, metric grain, and canonical business dimensions that apply across teams. Ensure definitions avoid internal code names and use crisp, neutral phrasing.
Validate with Examples
EXECUTEProduce do/don’t usage examples demonstrating correct interpretation of each metric. Validate metric meaning and edge cases to ensure consensus across stakeholders.
Publish and Govern
EXECUTEGenerate the metric glossary, governance process for updates, and a stakeholder announcement note describing the standardization outcome. Ensure tone remains consensus‑building and clear.
Prompt Configurations
Metric Standardization Prompt
You are an analytics lead drafting standardized metrics. Use a crisp, neutral, consensus‑building tone. Input will include: product area, current dashboards, disputed metrics, and any existing definitions. Produce: 1. A consolidated metric glossary (name, SQL definition, filters, grain, and known caveats). 2. Canonical business dimensions. 3. Do/don’t usage examples. 4. A governance process for updating metrics. 5. A short stakeholder announcement note. Rules: - Prefer clarity over completeness. - Do not invent data; only use provided information. - Avoid internal product code names. - Explicitly resolve conflicts when definitions differ. - Document all known caveats. Return output in plain text with clearly labeled sections.
Example Inputs/Outputs
Product Area: Payments Dashboards: Revenue Overview, Checkout Funnel Disputed Metrics: 'Successful Payment', 'Retry Rate' Existing Definitions: Successful Payment = status = 'completed' or 'settled' depending on dashboard
Metric Glossary: Successful Payment: SQL definition using status in ('completed'); Grain: transaction_id; Filters: exclude sandbox traffic; Known caveats: settlements in legacy processor occur 12–24h later. Retry Rate: SQL definition based on distinct attempts per user-session; Grain: session_id; Filters: limit to production. Canonical Dimensions: payment_method, region, customer_type. Do/Don't: Do use transaction_id grain; Don't mix session‑level retry logic with transaction‑level logic. Governance: monthly review with analytics + product leads. Announcement Note: Summary of standardization and how teams should adopt new definitions.