Business Glossary

A business glossary is a curated list of business terms, their definitions, and the relationships between them. It answers the question every growing organization eventually faces: "When we say 'active customer,' what exactly do we mean?"

The glossary provides a shared vocabulary. Without one, the same term carries different meanings across departments – marketing's definition of "lead" differs from sales' definition, and both differ from what the CRM actually tracks. Those discrepancies compound silently until someone notices that two dashboards show different numbers for the same metric.

What a business glossary contains

A well-structured glossary entry includes:

• Term: the business-meaningful name (e.g., "Monthly Recurring Revenue").
• Definition: a plain-language explanation of what the term means, with enough specificity to resolve ambiguity.
• Owner: the person or team responsible for maintaining the definition. Ownership prevents drift – someone is accountable when the meaning changes.
• Synonyms and related terms: "MRR" is a synonym. "Annual Recurring Revenue" is a related term. These cross-references help users navigate from what they know to what they're looking for.
• Scope and exceptions: "MRR includes recurring subscription fees. It excludes one-time setup fees, professional services revenue, and usage-based overage charges." The boundaries matter as much as the definition itself.
• Status: whether the term is approved, draft, or deprecated. Organizations evolve their vocabulary, and the glossary should reflect that lifecycle.

How it differs from a data catalog

The distinction is clean: a business glossary defines meaning, a data catalog describes inventory.

A data catalog tells you that a table called fact_subscriptions exists in the warehouse, contains 12 columns, was last updated two hours ago, and is owned by the data engineering team. A business glossary tells you that "Monthly Recurring Revenue" is the sum of all active subscription fees billed monthly, excluding trials and one-time charges.

The catalog answers "what data do we have?" The glossary answers "what do our terms mean?" Both are necessary. Neither replaces the other. The most effective setups link them – the glossary term "Monthly Recurring Revenue" points to the catalog entry for the table and column where it's computed.

Why it matters for self-service

Self-service analytics depends on a shared language. When a product manager builds a dashboard, they need to know whether "churn" means "cancelled subscription" or "no login in 90 days." When a marketing analyst segments users by "engagement," they need to know which events count.

Without a glossary, every self-service user makes their own interpretation. Some ask a data analyst. Some read documentation that may be outdated. Some guess. The result is a fleet of dashboards using the same words to mean different things – a direct manifestation of the semantic gap.

A glossary gives self-service users a canonical reference. It reduces the number of Slack messages that start with "Hey, quick question – what does this metric actually measure?"

The glossary should live inside the semantic layer

Many organizations maintain their glossary as a standalone document – a wiki page, a Confluence space, a Google Sheet. This creates a maintenance problem: the glossary says "MRR" means one thing, but the BI tool's metric definition implements something slightly different. The two drift apart, and users don't know which to trust.

The stronger approach embeds glossary-quality descriptions directly in the semantic layer's metric definitions. When the semantic layer defines a metric, the description field carries the glossary's definition, scope, and exceptions. The term, its meaning, and its computation live in the same governed object. There's no gap between what the glossary says and what the query returns.

Governance considerations

A glossary requires active maintenance. Definitions go stale as the business changes. New terms emerge and need formal definitions before they splinter into competing interpretations. Deprecated terms need clear sunset paths.

Assign ownership at the term level rather than the glossary level. The finance team owns revenue definitions. The product team owns engagement definitions. A central data team reviews for consistency but doesn't bottleneck every change. This distributed model scales better than a single glossary curator.