Field Naming Conventions

Why this matters Consistent field names make models discoverable, dashboards reliable, and handoffs smooth. As a BI Developer, you will: Design datasets that analysts can understand at a glance. Reduce logic bugs caused by ambiguous or misleading names. Speed up reviews, documentation, and onboarding. Enable automated quality checks and lineage tools to work better. Real tasks where naming matters Publishing a "Sales Orders" dataset to power dashboards across teams. Creating semantic models where fields appear in a business-friendly way. Migrating legacy tables and standardizing names to match your warehouse conventions. Defining KPI fields that remain stable as logic evolves. Who this is for BI Developers, Analytics Engineers, Data Analysts who publish shared datasets or build semantic layers. Prerequisites Basic SQL familiarity (SELECT, JOIN, simple aggregates). Understanding of data types: integer, numeric/decimal, boolean, date, timestamp. Awareness of your team’s modeling layers (staging, core, marts, semantic/report). Concept explained simply Field naming conventions are the "grammar" of your data. They answer: What is this? What format is it in? How should it be used? Good names reduce guesswork and errors. Mental model Imagine a warehouse full of labeled boxes. If every label follows the same pattern (type, units, time), anyone can find the right box and trust what’s inside. Your fields are those labels. Core rules you can adopt today Case and separators (storage layer): use snake_case with ASCII only. Example: order_id , customer_email . Display names (BI layer): use Title Case with spaces . Example: Order ID , Customer Email . Booleans: use is_ or has_ prefixes. Examples: is_active , has_subscription . Identifiers: suffix with _id . Examples: order_id , customer_id . Dates and times: Calendar dates: _date (YYYY-MM-DD). Example: order_date . Timestamps (timezone-aware): _timestamp . Example: created_timestamp . Time-of-day only: _time . Example: pickup_time . Common audit fields: created_at , updated_at (if your team prefers _at style for timestamps). Amounts and units: Money: _amount plus ISO currency: revenue_amount_usd . Pair with currency_code if variable. Counts: _cnt . Example: orders_cnt . Percentages: _pct for decimals between 0 and 1 (document scale). Example: conversion_pct . Aggregations and windows: Totals/aggregates: lead with metric, optionally suffix grain/window. Example: orders_cnt_7d , total_revenue_amount_usd . As-of fields: as_of_date to mark snapshot reference. Clarity over brevity: avoid unclear abbreviations. Allowed short forms: id , sku , url , utc . No business meaning in IDs: order_id should be opaque, not encoded with dates/business logic. Consistency beats perfection: pick a standard and apply it everywhere. Optional extras if your team agrees PII indicators via tags/metadata, not field name. If you must, align on a single prefix like pii_ . Source system indicators via schemas, not field name. If unavoidable, use a suffix like _src or a source_system field. Worked examples Example 1: Customer dimension Before (messy): CustomerID , CustName , signupDt , activeFlag , emailAddress After (clean): customer_id customer_name signup_date is_active customer_email Why Snake case for storage. Clear words over abbreviations ( customer_name vs CustName ). _date for calendar date. is_ for boolean. Example 2: Orders fact Before: OrderId , custId , OrderDateTime , Revenue , Currency After: order_id customer_id order_timestamp revenue_amount_usd (if fixed USD) or revenue_amount + currency_code Why Identifiers use _id with full word. Timestamp is timezone-aware. Money fields include units via _amount and optional currency code. Example 3: Aggregated weekly KPI view Before: newUsers , orders7Days , CR After: new_users_cnt_7d orders_cnt_7d conversion_pct Why Counts use _cnt . Window suffix uses _7d . Percentage uses _pct and should be documented as 0–1 scale. Exercises Note: The quick test is available to everyone; only logged-in users get saved progress. Exercise 1 — Rename a mini schema Given fields: OrderID , CustID , OrderDate , ShippedAtUTC , Amount , Currency , ActiveFlag Rename them following the rules above. Keep storage-layer style. See hints Use snake_case. Identifiers end with _id . Calendar date vs timestamp: choose _date or _timestamp . Booleans use is_ . Money uses _amount and currency handling. When ready, compare with the solution in the exercise card below on this page. Exercise 2 — Standardize KPI names Given: TotalRevenue , avg_order_val , OrdersLast30Days , HasCoupon , CR% Rename using consistent metric/units/window naming. See hints Prefer total_ , avg_ , _cnt . Use _amount for money, consider currency. Window suffix like _30d . Percentages use _pct . Boolean use has_ for possession. Checklist for self-review All names are snake_case (storage) and Title Case (BI display). Booleans start with is_/has_. IDs end with _id; counts end with _cnt. Dates/times use _date, _time, _timestamp correctly. Money uses _amount and currency is explicit. Windows appended as _7d, _30d where relevant. No ambiguous abbreviations remain. Common mistakes and how to self-check Mixing cases: fix orderDate to order_date . Boolean without intent: rename active to is_active . Hidden units: rename revenue to revenue_amount_usd or pair with currency_code . Ambiguous date: rename date to order_date or as_of_date . Window missing: rename orders_cnt to orders_cnt_7d if it’s a trailing 7-day metric. Self-check mini-task Scan one table: if you cannot tell type, unit, and timing from the field name alone, rewrite the name or add metadata to make it obvious. Practical projects Create a 1-page "Naming Charter" for your team; apply it to one dimension and one fact table. Refactor a small mart: standardize field names and publish a "before vs after" diff with reasons. Prepare BI display names for a top dashboard dataset and align them with your storage names. Learning path Adopt 8–10 core rules (from this page) and write them into your project README. Audit 2–3 critical datasets; list violations and quick wins. Align with stakeholders on BI display names vs storage names. Refactor iteratively: new models follow the standard; legacy models are updated when touched. Mini challenge Pick any dashboard you own. Trace every field back to the model. Rename fields in the model so a newcomer could understand each field without opening documentation. Publish the changes with a short rationale. Quick Test Take the test below to check your understanding. Available to everyone; log in to save your progress. Next steps Apply the checklist to one live table today. Share your "Naming Charter" draft with your team for feedback. Prepare a small refactor PR focusing on names only—no logic changes.

Field Naming Conventions

Table of Contents

Why this matters

Quick Test

Next steps

Practice Exercises

Rename a mini schema

Instructions

Expected Output

Standardize KPI names

Field Naming Conventions — Quick Test

Have questions about Field Naming Conventions?

AI Assistant