Power BI Measure Naming Standards

Objective

To establish a clear, concise, and standardized naming convention for Power BI measures, ensuring consistency, avoiding redundancy, and preventing misinterpretation by analysts.

1. General Naming Principles

1. Avoid Redundant Words

   
   

   • Do not use "Total" unless necessary (e.g., use "Revenue" instead of "Total Revenue").

   • Do not use prefixes like "M_" or "Measure_" (measures should be readable by end users who don’t care about internal structuring).

     
     
   
   

2. Ensure Meaningful & Concise Names

   
   

   • Measures should clearly define what they represent without unnecessary words.

     
     
     
     

3. Specify the Basis of Calculation

   
   

   • Always indicate what the measure is calculated per to avoid ambiguity.

     
     
     
     

4. Use Table-Specific Suffixes When Needed

   
   

   • When the same measure needs to be created for multiple tables, add a suffix with the first letters of each table name to differentiate them (e.g., Revenue_S for Sales, Revenue_F for Finance).

     
     
     
     

5. Rename Measures in Visuals for End Users

   
   

   • Since measures like Revenue may exist in multiple tables (e.g., Sales, Finance, Orders), we use table-specific suffixes such as Revenue_S to differentiate them in the model.

   • However, end viewers don’t care about this differentiation; they just need to see Revenue in their reports.

   • Solution: In Power BI visuals (charts, tables, cards), rename Revenue_S back to Revenue, ensuring clarity for end users while maintaining backend structure.

     
     
     
     

6. Handling Multiple Similar Measures within the Same Table

   
   

   • When multiple variations of the same measure exist within the same table, use numerical suffixes to differentiate them (e.g., Revenue 1, Revenue 2, Revenue 3).

   • For testing purposes, use explicit names such as Revenue Test 1, Revenue Test 2, ensuring they are clearly marked as temporary or experimental.

     
     
   
   
   
   

2. Example Naming Conventions

Using Avg Sales Price as a Base Case

Measure Name	What It Represents
Avg Sales Price per Unit	Average price per individual unit sold
Avg Sales Price per Order	Average price per completed order
Avg Sales Price per Customer	Average price per unique customer (across multiple purchases)
Avg Sales Price per Transaction	Average price per individual transaction
Avg Sales Price per SKU	Average price for each unique SKU sold
Avg Sales Price per Region	Average price calculated at the region level

Handling Measures for Multiple Tables

Measure Name	Table Name	Final Name with Suffix
Revenue	Sales Table	Revenue_S
Revenue	Finance Table	Revenue_F
Revenue	Orders Table	Revenue_O
Revenue per Customer	CRM Table	Revenue per Customer_C
Avg Sales Price per Unit	Product Table	Avg Sales Price per Unit_P
Profit Margin	Accounting Table	Profit Margin_A

Handling Multiple Measures within the Same Table

Measure Name	Use Case	Final Naming Convention
Revenue 1	Alternative Revenue Calculation	Revenue 1
Revenue 2	Another Revenue Variation	Revenue 2
Revenue Test 1	Temporary Testing	Revenue Test 1
Revenue Test 2	Experimental Calculation	Revenue Test 2

Additional Common Examples

Measure Name	What It Represents
Revenue per Order	Revenue generated per order
Revenue per Customer	Revenue per unique customer
Profit per Transaction	Profit per completed transaction
Cost per SKU	Cost associated with each SKU
Margin per Unit	Profit margin calculated per unit sold

3. Why This Matters

1. Prevents Analysts from Making Assumptions

   • Analysts should always specify the calculation basis explicitly.

     
     

2. Avoids Misinterpretation of Data

   • Avg Sales Price per Customer vs. Avg Sales Price per Unit can have drastically different values, leading to incorrect insights if misused.

     
     

3. Ensures Scalability and Consistency

   • Having a structured naming approach helps maintain clarity as datasets grow.

     
     

4. Implementation

• This naming convention must be followed for all new measures.

• Any existing measures not adhering to this standard should be updated.

• Analysts should document new measures with clear definitions for reference.

• Measures used in visuals should be renamed back to their original form for end-user clarity (e.g., Revenue_S should be displayed as Revenue in charts).

5. Next Steps

• Review & Approve: Align all existing measures with this standard.

• Training: Ensure team members understand and adopt this approach.

• Ongoing Validation: Regularly audit measure names to maintain consistency.