Who this is for
This lesson is for Business Analysts and adjacent roles (product owners, data analysts, QA) who need clear, shared definitions for terms, entities, and metrics across a project or organization.
Prerequisites
- Basic understanding of the product or domain you work in
- Ability to read simple requirements/user stories
- Comfort collaborating with stakeholders (PM, Engineering, Data, Legal, Support)
Note: The quick test is available to everyone. Only logged-in users have their progress saved.
Why this matters
In real projects, the same word often means different things to different teams. A well-maintained glossary prevents costly misinterpretations, inconsistent reports, scope creep, and rework.
- Reporting: Analytics dashboards match product and finance terminology
- Requirements: Developers build exactly what was intended
- QA: Test cases validate the correct behavior and metrics
- Support: Clear help articles use the same words customers see in the product
Concept explained simply
A glossary is a single source of truth for what key words mean. Each entry should say what the term includes, excludes, how it’s calculated (if numeric), and who owns it.
Mental model
Think of your glossary like a dictionary plus a contract:
- Dictionary: Simple, precise, easy to search
- Contract: Agreed by stakeholders, versioned, and traceable to systems and reports
Format and style guide
- Use singular nouns for entities (Customer, Order)
- One clear sentence first; details after
- For metrics: include formula, window, data source, inclusions/exclusions
- List synonyms and do-not-use terms
- Add owner/approver and last updated date
- Version entries when meaning changes
Reusable entry template
Term: <Name>
Type: Entity | Event | Status | Metric | UI label
Definition (1–2 sentences): <What it is>
Includes: <What is included>
Excludes: <What is not included>
Formula (if metric): <Explicit formula, time window>
Source systems/tables: <Systems, tables, fields>
Owner: <Role or person> Approver: <Role or team>
Synonyms/Do-not-use: <List>
Examples: <Optional concrete examples>
Last updated: <YYYY-MM-DD> Version: <#>Worked examples
Example 1: Customer
Term: Customer
Type: Entity
Definition: A legal entity or individual with at least one completed paid Order in the system.
Includes: Individuals and companies with paid Orders
Excludes: Leads, trial users without payment, canceled-only accounts
Source systems/tables: billing.customers, salesforce.Account
Owner: Finance Ops Approver: Data Governance
Synonyms/Do-not-use: Buyer (legacy), Client (legal contracts only)
Last updated: 2025-01-01 Version: 3Example 2: Active User (30-day)
Term: Active User (30-day)
Type: Metric
Definition: A unique user who triggered at least one qualifying product event in the last 30 days.
Includes: Login, Purchase, Project_Create
Excludes: Email open, Marketing site visit
Formula: COUNT_DISTINCT(user_id) WHERE event_name IN (login, purchase, project_create) AND event_time >= today-30d
Source systems/tables: analytics.events
Owner: Product Analytics Approver: PM Lead
Synonyms/Do-not-use: MAU (use only if identical to this definition)
Last updated: 2025-01-01 Version: 2Example 3: Order
Term: Order
Type: Entity
Definition: A confirmed request to purchase one or more items that results in a payment authorization.
Includes: Partially fulfilled orders
Excludes: Carts, Quotes, Refunds
Source systems/tables: commerce.orders, payments.authorizations
Owner: Commerce PM Approver: Accounting
Synonyms/Do-not-use: Transaction (payments-only), Cart (pre-purchase)
Last updated: 2025-01-01 Version: 1Build your project glossary (step-by-step)
- Collect candidate terms
Scan requirements, stories, dashboards, and UI labels. List ambiguous or high-impact terms. - Draft definitions
Use the template. Keep the first sentence crisp; clarify includes/excludes next. - Align with stakeholders
Review with PM, Eng, Data, Finance/Legal if relevant. Resolve conflicts; document decisions. - Attach evidence
Add formulas, source tables, sample IDs, and screenshots if needed. - Publish and tag
Store in a shared location. Tag terms used in docs and dashboards. - Maintain
Set owners, review cadence (e.g., quarterly), and version entries when meaning changes.
Starter set of typical BA terms (pick what fits your product)
- User, Account, Customer, Role, Permission
- Order, Subscription, Invoice, Refund
- Lead, Opportunity, Trial, Activation
- Active User (30d), DAU, Churn Rate, MRR, Conversion
- Incident, Severity, SLA, Uptime
Common mistakes and how to self-check
- Vague definitions (e.g., "Active user = engaged user")
Fix: Name concrete qualifying events and time window. - Hidden exclusions
Fix: Add an explicit "Excludes" line. - Missing formula or source for metrics
Fix: Provide exact formula and table/field names. - Multiple competing terms for one concept
Fix: Choose one preferred term and list "Do-not-use" synonyms. - No owner or review cycle
Fix: Add Owner, Approver, Last updated, Version.
Self-check checklist
- Each entry has a one-sentence definition
- Includes/Excludes are explicit
- Metrics have formula, window, and source
- Owner/Approver and dates are filled
- Synonyms/Do-not-use are listed
- Examples provided for tricky terms
Exercises
These mirror the interactive tasks below (your work won’t be auto-graded here). Use the checklist to verify.
Exercise 1 — Clarify ambiguous terms (Ride-sharing)
Given: Requirements mention Driver, Rider, Trip, Active Driver, and Cancellation. Draft precise entries.
- Use the template
- Include/Exclude and data sources are required
- Limit to 5–7 lines per term
Expected output: Clear entries for each term with owner and last updated date.
Exercise 2 — Define a metrics mini-glossary (Subscriptions)
Define: Active User (7-day), Churn Rate (Monthly), MRR, Trial Conversion, ARPU.
- Provide exact formulas and time windows
- Note source tables/fields
- List common pitfalls or exclusions
Expected output: 5 entries, each with formula, window, inclusions/exclusions, owner.
Quality checklist for your exercises
- First sentence is plain and testable
- All metrics have formulas and time windows
- Inclusions/Exclusions are explicit
- Owner/Approver present
- Synonyms/Do-not-use documented
- Version and last updated included
Practical projects
- Project 1: Create a glossary for a small feature (e.g., checkout) with 12–20 entries. Review with PM and Eng.
- Project 2: Metrics harmonization — align 5 metrics across Product, Data, and Finance; publish one canonical definition each.
- Project 3: UI vocabulary audit — list top 30 UI labels; align them with glossary terms and flag inconsistencies.
Mini challenge
Rewrite this requirement to use glossary-backed terms and add two new entries if needed:
“Show active users their latest orders and let power users refund instantly.”
Possible approach
- Replace active users with a defined term (e.g., Active User (30-day))
- Clarify power users (role? permission?) — add entries for Role and Refund
- Define latest orders (time window? status?)
Learning path
- Now: Glossary & Definitions (this lesson)
- Next: Requirements structure (user stories, acceptance criteria)
- Then: Data contracts & event naming
- Later: Reporting alignment and metric validation with QA
Next steps
- Complete Exercises 1–2 below and apply to one live project area
- Run a 20-minute alignment review with PM, Eng, and Data
- Take the quick test to check retention and spot gaps