Metric Naming Conventions Guide

Sections:

1. Start with Business Language, Not Technical Logic
2. Be Precise Without Over-Specifying
3. Match How Your Organisation Actually Works
4. The Time-Neutral Rule
5. When to Include (and Exclude) Aggregation Language
6. Mandatory Financial and State Qualifiers
7. Handling Acronyms and Synonyms
8. Managing Complexity as You Scale
Your Metric Naming Checklist

1. Start with Business Language, Not Technical Logic

The golden rule of metric naming is simple: name metrics the way people naturally talk about them in your organisation.

Your metric names should reflect business concepts—not database tables, field names, or data sources. When someone asks, "What's our churn rate?" they're not thinking about SQL queries or pipeline logic. They're thinking about a business concept they need to measure.

The Hallway Test

Before finalising a metric name, ask yourself: "If I mentioned this metric to a colleague in the hallway, would they immediately understand what I'm referring to?"

Good examples:

• Marketing Qualified Leads
• Customer Acquisition Cost
• Net Revenue

Poor examples:

• GAds_Leads_Total (too technical, includes source)
• rev_sum_monthly (database naming, includes aggregation)
• MQL_v2_final (versioning belongs in metadata, not the name)

Use natural wording with proper spacing and title case. Avoid underscores, abbreviations, and technical jargon in the primary name—these belong in tags and metadata instead.

2. Be Precise Without Over-Specifying

Finding the right level of precision is crucial. Your metric name should be specific enough to avoid ambiguity, but not so granular that it fragments usage or makes metrics hard to discover.

The Problem with Vague Names

A metric simply called "Conversion Rate" immediately raises questions:

• Conversion of what?
• Website visits to signups?
• Leads to opportunities?
• Opportunities to closed deals?
• Trial users to paid customers?

The name forces users to inspect definitions or ask questions—both of which slow adoption and erode trust.

The Problem with Over-Specification

On the other hand, a metric called "Marketing Qualified Leads from Email Campaigns in Q3 2024" is far too specific. Time periods, channels, and campaigns are dimensions and filters, not part of the metric's core identity.

The right approach: Name the metric Marketing Qualified Leads. Users can then segment and filter by source, time period, or campaign as needed.

Practical Tests for Precision

The New Hire Test
If you were explaining this metric to a new employee, what would you naturally call it? That's likely your metric name.

The AI Test
If you asked an AI assistant to retrieve this metric, would the name clearly signal its intent? Ambiguous names lead to ambiguous results—especially as AI-powered analytics become more prevalent.

3. Match How Your Organisation Actually Works

Metric scope should reflect how people in your organisation actually discuss the business—not an idealised universal view.

When "Revenue" Isn't Specific Enough

In larger or multi-national organisations, a single top-level metric can be too broad to be useful. A metric simply called "Revenue" often triggers follow-up questions:

• Which country?
• Which business line?
• Which product?
• Gross or net?

The Conversational Litmus Test

Ask yourself: "If I asked a colleague, 'What is our revenue?', would they naturally know which revenue I meant?"

If the answer is no, or there is always a qualification question, the metric is likely too broad for daily use.

A Better Approach for Complex Organisations

Define commonly referenced, context-specific metrics that match how teams naturally segment the business:

Base metrics:

• Canadian Revenue
• US Revenue
• EMEA Revenue
• B2C Sales
• Partner Channel Sales

Calculated roll-ups:

• Global Revenue (calculated from regional metrics)
• Total Sales (calculated from channel metrics)

This approach:

• Matches natural conversation patterns
• Reduces constant filtering
• Makes assumptions explicit
• Improves trust and adoption

4. The Time-Neutral Rule

Time is a dimension, not a metric. This is one of the most important principles for building a scalable set of metrics.

Remove Timeframes from Metric Names

Including timeframes in metric names creates "metric bloat" and confuses both users and AI systems. These terms should never appear in a metric name:

• Year over Year (YoY)
• Month over Month (MoM)
• Last 30 Days
• Year to Date (YTD)
• Running Total
• Monthly Average

Why? In PowerMetrics, time is handled through date dimensions and filters. The metric remains constant—users select the time period in their analysis.

Poor examples:

• Monthly Recurring Revenue YoY Growth
• Last 90 Days Active Users
• YTD Revenue

Better examples:

• Recurring Revenue (users select time period and comparison)
• Active Users (users select date range)
• Revenue (users select YTD filter)

The Exception: When Time Defines the Metric

If the time period is part of the business definition itself—not just an analysis window—it stays in the name.

Valid examples:

• Monthly Active Users (the "monthly" defines what "active" means)
• Daily Average Sessions (the metric specifically measures a daily average)
• Annual Contract Value (the contract term is part of the definition)

The test: If removing the time word would fundamentally change what the metric measures, keep it. If it just describes when you're looking at the metric, remove it.

5. When to Include (and Exclude) Aggregation Language

One of the most common naming mistakes is including unnecessary aggregation terms. Understanding when aggregation belongs in a name—and when it doesn't—is essential.

Level up data-driven decision making

Make metric analysis easy for everyone.

Get Started Now

The General Rule: Avoid Aggregation Words

For additive metrics (values that can be summed), aggregation language should not appear in the name. The metric describes the business concept; how it's aggregated depends on the analysis context.

Don't use:

• Total Revenue → Revenue
• Sum of Orders → Orders
• Total Marketing Spend → Marketing Spend
• Count of Emails Sent → Emails Sent

Why? Summing is expected for these metrics, but it's not always required. Someone might want to see Revenue by month, by region, or by product—the aggregation is contextual, not definitional.

The test: "If I changed the time grain or grouped by a different dimension, would the metric still mean the same thing?"

If yes, don't include aggregation language.

When Aggregation Must Be Included

Some metrics are defined by their aggregation. Removing it would change the meaning entirely. These are typically non-additive metrics.

Always include aggregation for:

• Averages: Average Order Value, Average Deal Size
• Rates: Conversion Rate, Churn Rate, Growth Rate
• Percentages: Gross Margin Percentage, Win Rate Percentage
• Per-unit metrics: Revenue Per Customer, Cost Per Acquisition

The test: "If someone tried to sum this metric across rows, would that make sense?"

If no, the aggregation belongs in the name. You can't meaningfully sum averages, rates, or percentages—the aggregation method is core to what the metric represents.

6. Mandatory Financial and State Qualifiers

While you should avoid redundant aggregation words, certain business qualifiers are mandatory because they fundamentally change the metric's definition.

Net vs. Gross

For financial metrics, clarifying whether values are net or gross is essential:

• Net Revenue (after refunds, discounts, returns)
• Gross Revenue (before adjustments)
• Net Profit Margin
• Gross Margin Percentage

If your organisation primarily works with one version (e.g., always net), you can use the simpler name (e.g., "Revenue") and document this in the description. But if both versions exist, distinguish them clearly.

Cumulative Metrics

Use "Cumulative" only when the metric is definitionally a running total:

• Cumulative Signups (running total from launch)
• Cumulative Revenue (running sum over time)

Don't use "Cumulative" for metrics that just happen to be viewed over a time range—that's a filter, not part of the metric identity.

State-Based Qualifiers

Include qualifiers that describe a specific business state:

• Committed Annual Recurring Revenue (contracts signed)
• Recognised Revenue (accounting treatment)
• Paid Subscriptions (vs. trial or free)

7. Handling Acronyms and Synonyms

Business teams love acronyms (CAC, LTV, MRR, ROAS), but they can create problems for clarity and AI-powered search.

The Primary Name Rule

Always spell out the full name. Use the acronym in the description, not as the primary identifier.

Good:

• Primary name: Customer Acquisition Cost
• Include in metric description: CAC, Cost Per Acquisition, CPA

Poor:

• Primary name: CAC

Why?

• New team members don't know every acronym
• AI systems search better with full terms, but will also reference the description for added context
• Acronyms can mean different things in different contexts (ARR = Annual Recurring Revenue or Annual Run Rate?)

Leverage PowerMetrics Metadata

PowerMetrics lets you add rich descriptions to metrics. Use this to capture alternative terms without cluttering the primary name:

Description field: Full explanation of what the metric measures, how it's used, and anything else a user or AI might find useful.

Tags: Metric state (e.g., "Testing"), department, intended use, campaign etc...

This approach keeps names clean while ensuring metrics remain discoverable through search.

8. Managing Complexity as You Scale

As your PowerMetrics account grows, you'll need strategies to keep your metric library organised and trustworthy.

Use Sharing Controls to Control Clutter

Not every metric needs to be visible to everyone. PowerMetrics lets you control metric visibility—use this strategically.

Shared metrics: KPIs and commonly referenced metrics visible to all users

Unshared base metrics: Helper metrics used only in calculations or by specific teams

Example: You might have granular metrics like "Direct Sales Revenue" and "Partner Sales Revenue" used to calculate "Revenue." If most users only care about the big picture, share "Revenue" and keep the components unshared or restricted to the specific teams.

Tag Certified Metrics

When multiple versions of similar metrics exist, use a "Certified" badge to designate this one as the single source of truth.

Example: If there are two "Net Revenue" metrics—one from the sales team and one from finance—tag the finance version as "Certified" so users (and AI agents) know which to trust for official reporting (and figure out why sales has their own "Net Revenue" metric!)

Avoid Source Names in Metrics

Never put data source names in metric names. What happens when you switch tools or consolidate data sources?

Poor:

• Salesforce Opportunities
• Google Ads Impressions
• Shopify Orders

Better:

• Sales Opportunities (Tag: "Source: Salesforce")
• Ad Impressions (Tag: "Source: Google Ads")
• Orders (Tag: "Source: Shopify")

In most cases, PowerMetrics already understands the lineage to the data source (ie: Google Ads, Stripe, or Hubspot), but you can also use tags to track relationships without making source systems part of the metric identity.

Update Management

When metrics need significant changes, handle details through tags or descriptions—not the name itself.

Don't create:

• Revenue v2
• Churn Rate (New)
• MQLs - Updated

Instead:

• Update the existing metric
• Document changes in the description
• Deprecate old versions rather than creating parallel metrics

Your Metric Naming Checklist

Before you publish a metric in PowerMetrics, run through this checklist:

Identity

[ ] Uses natural business language (the Hallway Test)
[ ] Uses title case with spaces (not underscores or camelCase)
[ ] Spells out acronyms fully (put acronyms in synonyms)

Precision

[ ] Specific enough to avoid ambiguity
[ ] Not so granular it includes filters or dimensions
[ ] Matches how your organisation naturally segments the business

Time-Neutral

[ ] Contains no timeframe references (YoY, Last 30 Days, YTD)
[ ] Exception: Time period is part of the metric definition (Monthly Active Users)

Aggregation Logic

[ ] Excludes aggregation for additive metrics (no "Total" or "Sum")
[ ] Includes aggregation for non-additive metrics (Average, Rate, Percentage)

State Qualifiers

[ ] Includes "Net" or "Gross" where relevant
[ ] Uses "Cumulative" only for running totals
[ ] Includes business state qualifiers (Committed, Recognised, Paid)

Metadata

[ ] Description clearly explains what the metric measures
[ ] Tags capture state, department, metric type
[ ] "Certified" tag applied to canonical versions

Scalability

[ ] Visibility set appropriately (shared vs. unshared)
[ ] No data source names in the metric name itself
[ ] No version numbers in the name

Final Thoughts

Well-named metrics reduce cognitive load, prevent misuse, and make your PowerMetrics metric catalog genuinely self-serve. They enable both humans and AI systems to navigate your data confidently.

The goal isn't perfection—it's consistency and clarity. When in doubt, return to the Hallway Test: name your metrics the way you'd naturally describe them to a colleague. Your team (and your future self) will thank you.