How to Build a Source-of-Truth Metrics Dictionary

A metrics dictionary is a centralized, versioned reference document that defines every KPI, calculation method, data source, and ownership rule used across marketing, product, and finance teams.

Why Metrics Arguments Destroy Operational Velocity

Marketing reports 15% AOV growth. Finance sees 8%. Product doesn't know which number to trust. Three Slack threads later, someone discovers they're measuring different cohorts, time windows, and currency conversions. This isn't a data problem - it's a governance problem.

When teams lack a shared definition of 'conversion', 'revenue', 'customer acquisition cost', or 'retention', every stakeholder meeting becomes a definitional negotiation. Operators lose 10-20 hours per quarter resolving metric conflicts instead of acting on insights. Worse, decisions get made on the wrong number.

A metrics dictionary eliminates this friction by establishing a single source of truth before the question is asked. It's not a dashboard. It's not a data warehouse schema. It's a living document that says: here's what we measure, how we measure it, who owns it, and when it changed.

Core Components of a Metrics Dictionary Entry

Each metric in the dictionary needs enough structure to prevent misinterpretation, but not so much that maintenance becomes a burden. Start with these fields for every entry:

• Metric name and alias (e.g., 'AOV' = 'Average Order Value') - use the term your team actually says in meetings
• Definition (one sentence, no jargon) - e.g., 'Total revenue divided by total orders in a calendar month'
• Calculation formula - show the numerator and denominator explicitly
• Data source (which system owns the truth) - Shopify, GA4, Klaviyo, custom warehouse, etc.
• Calculation frequency - real-time, daily, weekly, or monthly
• Owner (team and person) - who updates it, who answers questions
• Filters applied - excluded traffic, excluded order types, currency handling
• Historical changes - version log with dates and reasons (e.g., 'Added gift card exclusion on 2024-01-15')
• Related metrics - what else should you check alongside this one
• Last verified date - when someone last confirmed the calculation still works

Template: What a Real Entry Looks Like

Here's a filled example that prevents ambiguity:

• Metric: Customer Acquisition Cost (CAC)
• Definition: Total paid marketing spend divided by new customers acquired in a calendar month.
• Formula: (Google Ads spend + Meta spend + TikTok spend + email platform costs) / New customer count
• Data source: Finsi (aggregates spend), Shopify (customer creation date)
• Frequency: Daily (calculated at 2am UTC)
• Owner: Performance Marketing Manager (Sarah Chen)
• Filters: Excludes test orders, excludes internal team purchases, excludes orders with $0 revenue, US only
• Changes: 2024-01-10 - Added TikTok spend (previously excluded). 2023-11-22 - Changed from last-click to first-touch attribution.
• Related metrics: ROAS, LTV, payback period, blended CAC
• Last verified: 2024-02-14 by Sarah Chen

Governance: Who Owns What and When It Changes

A metrics dictionary without governance rules becomes outdated noise. Establish these three rules before launch:

First, assign a single owner per metric - not a committee. That person is accountable for accuracy and updates. They don't need to calculate it themselves, but they verify it quarterly and flag changes.

Second, require a change log entry every time a definition or calculation shifts. Don't allow silent updates. When CAC calculation changes from last-click to first-touch attribution, document the date, reason, and impact on historical comparisons. This prevents operators from accidentally comparing incompatible numbers.

Third, set a review cadence. Every metric gets reviewed by its owner at least quarterly. If a metric hasn't been verified in 6 months, flag it as 'unverified' in the dictionary until someone confirms it still works.

Where to Host It and How to Keep It Alive

The format matters less than accessibility and update friction. Google Sheets works for small teams (under 20 people). Notion or Confluence works for larger orgs. Avoid locked PDFs or email attachments - they become stale immediately.

Host it in a place your team already visits daily. Link it in Slack. Pin it in your #analytics or #finance channel. Add a 'last updated' timestamp at the top so people know if they're reading current information.

Assign one person (often the analytics lead or finance ops manager) as the dictionary steward. Their job isn't to calculate metrics - it's to field definition questions, update entries when owners report changes, and flag entries that haven't been verified in 6 months. Budget 2-3 hours per month for this role.

Create a simple intake form (Google Form, Slack workflow, or email template) for teams to request new metrics or flag definition conflicts. Route these to the steward, who works with the metric owner to add or update the entry. This prevents the dictionary from becoming a bottleneck.

Rollout: Getting Buy-In Without Meetings

Launching a metrics dictionary fails if it feels like a compliance project. Frame it as a time-saver instead.

Start by auditing existing metric definitions. Pull the last 10 Slack threads where teams debated what a metric meant. Identify the 15-20 most-argued metrics (AOV, CAC, ROAS, conversion rate, LTV, payback period, etc.). Build the dictionary with just those first. This gives immediate value and proves the concept.

Share a draft with the metric owners and ask for 30-minute feedback sessions, not big meetings. Let them see how their metric is defined and ask for corrections. This creates ownership and catches errors before launch.

When you launch, send a single Slack message with the link and one example: 'We built a metrics dictionary to end definition debates. Here's what AOV means in our org - check it out and bookmark it.' Don't oversell it. Let teams discover the value when they hit their next metric argument.

After launch, monitor Slack for metric questions. When someone asks 'what's our CAC this month?', reply with the dictionary link instead of the number. This trains the org to self-serve and reinforces that the dictionary is the source of truth.

Common Pitfalls and How to Avoid Them

Pitfall 1: Defining metrics that don't exist yet. Stick to metrics your team actually uses and argues about. Don't add 'potential future metrics' - they'll never get verified and the dictionary becomes noise.

Pitfall 2: Letting definitions get too technical. If the definition requires a PhD to understand, it's not a source of truth - it's a barrier. Use plain language. 'Revenue per visitor' beats 'normalized transaction value indexed to session duration'.

Pitfall 3: Forgetting about data source changes. When you migrate from GA3 to GA4, or switch attribution models, update the dictionary immediately. Teams will compare old numbers to new numbers and think something broke. The dictionary prevents this confusion.

Pitfall 4: Treating the dictionary as a one-time project. It's not. It's a living document that evolves as your business changes. Budget for quarterly reviews and updates. If you don't, it becomes a graveyard of outdated definitions within 6 months.

FAQ

Should we include every metric or just the big ones?

Start with 15-20 metrics that cause actual arguments or confusion. These are usually: AOV, CAC, ROAS, conversion rate, LTV, payback period, retention rate, churn, email open rate, and click-through rate. Once the dictionary is live and trusted, expand to secondary metrics. A bloated dictionary with 200 entries becomes harder to maintain and less likely to be used.

What happens when two teams disagree on a metric definition?

The steward facilitates a decision with the metric owner and the teams in conflict. Document the decision and the reasoning in the change log. If marketing wants CAC to include organic spend and finance doesn't, decide once and document it. Then both teams use the same number. The goal is alignment, not perfection.

How do we handle metrics that change seasonally or by campaign?

Document the base definition, then note exceptions in the filters section. Example: 'CAC excludes Black Friday spend (calculated separately as BFCAC)' or 'Conversion rate includes all traffic except paid search tests (see conversion-rate-paid-search for that variant).' This prevents confusion while acknowledging that context matters.

Who should own the dictionary itself?

Assign one person as steward - usually the analytics lead, finance ops manager, or a senior analyst. They don't own every metric, but they own the process. They field questions, update entries when owners report changes, and flag stale definitions. This role takes 2-3 hours per month and prevents the dictionary from becoming abandoned.

FAQ

Should we include every metric or just the big ones?

Start with 15-20 metrics that cause actual arguments or confusion. These are usually: AOV, CAC, ROAS, conversion rate, LTV, payback period, retention rate, churn, email open rate, and click-through rate. Once the dictionary is live and trusted, expand to secondary metrics. A bloated dictionary with 200 entries becomes harder to maintain and less likely to be used.

What happens when two teams disagree on a metric definition?

The steward facilitates a decision with the metric owner and the teams in conflict. Document the decision and the reasoning in the change log. If marketing wants CAC to include organic spend and finance doesn't, decide once and document it. Then both teams use the same number. The goal is alignment, not perfection.

How do we handle metrics that change seasonally or by campaign?

Document the base definition, then note exceptions in the filters section. Example: 'CAC excludes Black Friday spend (calculated separately as BFCAC)' or 'Conversion rate includes all traffic except paid search tests (see conversion-rate-paid-search for that variant).' This prevents confusion while acknowledging that context matters.

Who should own the dictionary itself?

Assign one person as steward - usually the analytics lead, finance ops manager, or a senior analyst. They don't own every metric, but they own the process. They field questions, update entries when owners report changes, and flag stale definitions. This role takes 2-3 hours per month and prevents the dictionary from becoming abandoned.