Creating Metrics Columns in PowerBI using DAXThis module demonstrates the different feel and performance of creating columns of metrics with the DAX formula language in PowerBI (similarly within PowerPivot which is inside Excel). While any intelligent adult can learn the basics of PowerBI charts in a week, many fewer adults can understand data models, and creating metrics (calculated columns) which serve as

the fields to put into the charts.

Managers and analysts that can create the calculated metrics that they need to assess business performance are very valuable employees. Other than observation and discussion, what is needed to generate insight into the drivers of business performance? Metrics! Analytics! Compiled data! Metrics are calculated columns that are visualized in charts and maps! This theme of the importance of creating calculated columns or metrics (generating analytics) was also focused on in the review of SQL SELECT statements where we created new columns with DATEPART(), DATENAME(), PIVOT(), GROUPBY(), CASE(), NTILE(), and just using columns to multiply/divide other columns (creating ratios and calculated fields such as % discount).

DAX is the acronym for Data Analysis Expressions, which is a programming language for writing formulas. DAX and PowerBI in general was created for Finance/Accounting types that use Excel everyday at work. Consumers have long complained that it is too hard to write advanced formulas inside Excel (you often have to write nested calculations rather than other coding languages that are more sequential). After conducting many focus groups of corporate Excel power-users the DAX programming language was envisioned and born. You can read more about DAX here.

This document shows some of the excellent formulas that can be used to create columns of metrics (calculated values derived from different tables) inside PowerBI. These same formulas can be built inside the PowerPivot module inside Excel. The hope is that course participants learn enough about data management to never adopt the old paradigm manual processes of downloading data from ERP/CRM etc systems and databases into Excel and creating the formulas, crosstabs, tables and charts in Excel pages. Rather download the data into a powerBI or PowerPivot data model, put the formulas into the data model, then when you refresh the data to add the new transactions, the charts, tables and maps all update automatically with no data manipulation (automation!) The problem with Excel based data management, analysis and visualization process is that it is manual and therefore time consuming and error-prone. By adopting an understanding of data modeling and the DAX formula language (examples demonstrated here), some processes can be automated.

The charts shown in this document are provided in a PowerBI file.

Well let’s get started!

1

Start up a new Power BI file, connect to Featherman_Analytics, and import three tables FactResellerSales, FactInternerSales and AW_Products_Flattened. In part 1 of this document we will add calculated columns to the AW_Products_Flattened dimension table (hereafter called Products). After loading the data tables look at the data modeling tab of PowerBI to ensure the tables are linked as shown below.

As you can see the dimension table is in the middle this time (normally one fact table is in the middle surrounded by the dimension tables). The products are sold in both the Web and reseller channels.

This document has two parts. The first part demonstrates adding metrics pulled and compiled from the fact tables into the dimension table. The RELATEDTABLE function is used. This is useful because it likely that while you can import a dimension table into your notebook computer, it may be impossible to import the big data fact tables. So you may need to connect to fact tables rather than import them into your local development machine. The RELATEDTABLE function allows you to reach into the fact tables and perform summary calculations, here we use COUNTROWS, and SUMX to perform calculations on the columns of related fact tables and place the result of those calculations inside the dimension table for easy reporting. The downfall of this approach is that the values calculated are summary over the entire fact table or a portion of it. For example only one date filter can be used. If the reporting requirement is to look at the metric over time such as monthly, then you would need to place similar formulas in the fact table.

Another key learning component of part one of this document is learning that you can create calculated columns that can then be used to create other calculated columns. For example you can create a profit per unit column that can later be used in the denominator of some other formula. The result is that you can easily build a set of columns that can get very advanced and the DAX syntax remains brief. Similar functionality is not available in SQL.

2

1.

Add toAW_ Products_Flattened

(hereafter Products table)

Reseller Profit per Unit = AW_Products_Flattened[Dealer Price] - AW_Products_Flattened[Cost]

We can use this calculation to show how the average profitability for each product, model, sub-category or category.

The .pbix tabs 1-3 use this calculation.

2Add to Products table

Web Profit per Unit =

AW_Products_Flattened[Web Price] - AW_Products_Flattened[Cost]

Slide #1. Using the formulas

3

Turn on data labels, add slicer on product category. This is average profitability per product by sub-category. The profitability is based on each part number.

This is slide #2. Average profit per unit by product grouped by model, sub-category, and category.

Add a model hierarchy using 4 levels, Category, Sub-Category, Model, Product#. Make this is a drill-down Report. Turn on data labels.

Here we are averaging the profit each product makes within groups of data (model, sub-category, category).

As you can see the road bikes are being sold at a loss on the reseller network, but at a sizable profit when sold online. Notice the title of the report is customized.

This is slide #3. Used to bring attention to the wrong pricing in the bikes category. Use a page level filter on bikes. Use a slicer on sub-category.

Add a new hierarchy with just model and Part#. Make this a drill down report. Turn on data labels.

4

It’s interesting how the perspective of the data changes when you add the Internet channel where the profit margin is positive. As a brand manager you would feel infinitely more foolish for losing money in the reseller network. The Internet channel shows that the resellers are probably enjoying large profits, such that raising the reseller price by 15 % to cover costs would not harm the reseller very much.

You could use a page level filter to more easily see only the products that the reseller profit per unit is negative (defined as < 0) meaning that every sale loses money for the company. It is often a good idea to use page level filtering.

Show Part# in the X-axis and filters on category and sub-category.

These two formulas are useful to understand the pricing structure of the product lines. Next you might look at where the losses are occurring. If the touring bikes are losing money, where are they being sold? You could turn to maps next.

2. Add toProducts table

Contribution Margin = (AW_Products_Flattened[Dealer Price] - AW_Products_Flattened[Cost])/AW_Products_Flattened[Dealer Price]

5

Slide #5 – Contribution margin. The value reads the term sum, but is not summing the percentages, as the part # is being graphed not an aggregation of these such as model or sub-category.

This report shows the profitability of each part by category and allows the brand manager to adjust prices correctly or at least strategically.

Be careful NOT to average different percentages. It is tempting to look for the contribution margin grouped by model-or sub-category, but that would require different mathematics. Hmm seems like a small contribution margin for road bike frames!

6

3Add to Products table

Frequency Analysis

ResellerNumberInvoicesProductSoldOn = COUNTROWS(RelatedTable(FactResellerSales)

Since products are part of a hierarchy (model, sub-category, category) you can use this formula at different levels of analysis

Because this formula is in the dimension table it provides totals over the entire fact table, and cannot be sliced by time period. Later we will could create a similar formula to see for any time period (and changes over time) of how often the product is sold (count number of invoices)

Notice the use of RELATEDTABLE which aggregates the values from the fact table for each of 400 products. This is similar to a GROUP BY COUNT(invoice#) SQL statement. Slide #6 is below.

7

In the RFM model of analysis (analyzing Recency of activity, Frequency of activity, Monetary impact of activity), this formula counts how many line items in the fact table the product was sold on for the entire dataset. Because this formula is used in a dimension table this is similar to Excel’s =COUNTIF formula.

So this is a running total of how often the product was sold. The brand or store manager would need to decide whether to keep placing the product on the shelf, if it is rarely purchased.

It is interesting to see which products are often being purchased. If you were making decisions on product line extensions this would be very useful information! Next check if the products are profitable.

4Add to Products table

Frequency Analysis

ResellerNumberUnitsSold = SUMX(RelatedTable(FactResellerSales), FactResellerSales[OrderQuantity])

WebNumberUnitsSold = SUMX(RelatedTable(FactInternetSales), FactInternetSales[OrderQuantity])

This is another column in the dimension table that can total up transactions (here units sold) over the entire dataset. The thing to learn is that the SUMX function is an interator that will go thru every row of the specified column or columns and perform a calculation. These are essentially GROUP BY queries as a column from a fact table is grouped and titalled for each product#.

Slide #7 is below. Looks like customers mostly prefer to buy clothing in the stores.

8

So this is a running total of how many units of the product was sold on either channel. This could be useful to compare how customers are purchasing your product whether in stores or online. If you were to look at this data over time you could see how much web sales cannibalize in-store sales. Looking at this by region would be insightful!

5. Add to Products table

How much profit is being generated : The .pbix tab #7 uses this calculation. You can use either profitperunit calculation from #3 above.

Version 1: ListPriceResellerProfitForProduct = AW_Products_Flattened[Reseller Profit per Unit] * AW_Products_Flattened[ResellerNumberUnitsSold]

Version 2: ProfitforProduct = SUMX(RelatedTable(FactResellerSales), FactResellerSales[OrderQuantity] * FactResellerSales[ProfitPerUnit2])

We can now multiply the profit per unit (from either the products dimension table) based on the list price (version 2 of this formula) or the actual product unit price and standard cost at the time of the order (version 1 of this formula)

SUMX() is similar to the GROUP BY query. When putting the formula in the dimension table then the formula is run for each and every product in the dimension tables.

For each and every product in the dimension table the SUMX formula will locate all the related rows in the fact table that are sales of that product. Then the order quantity is multiplied by the profit per unit to arrive at the profit for the line item. So two columns are being multiplied for every sales transaction for the product. If the product is sold on 100 different orders then each of these are calculated and added together.

All the line items are added together to give a total profit generated for each product.

Formula #2 is the profit that should be made using the reseller list price from the products table.

8 Add to Products table

Average # Units per order =

AW_Products_Flattened[ResellerNumberUnitsSold]/AW_Products_Flattened[ResellerNumberInvoicesProductSoldOn]

9

9 Add to Products table

ResellerSalesRevenue =

SUMX(Relatedtable(FactResellerSales), FactResellerSales[SalesAmount])

Later we will use SUMX to iterate through the entire table and multiply some columns together.

10 Add to Products table

ResellerProfitForProduct =

AW_Products_Flattened[Reseller Profit per Unit] * AW_Products_Flattened[ResellerNumberUnitsSold]

You can use a calculated field in another calculated field.

11 Add to Products table

Average profit per order = (AW_Products_Flattened[Reseller Profit per Unit] * AW_Products_Flattened[Average # Units per order])

12 Add to Products table

Web Differential = AW_Products_Flattened[Web Profit per Unit] - AW_Products_Flattened[Reseller Profit per Unit]

Web Differential2 = (AW_Products_Flattened[Web Profit per Unit] - AW_Products_Flattened[Reseller Profit per Unit])/ AW_Products_Flattened[Reseller Profit per Unit]

Web Differential3 = (AW_Products_Flattened[Web Price] - AW_Products_Flattened[Dealer Price])/ AW_Products_Flattened[Dealer Price]

The .pbix tabs 9 use this calculation.

How much more are products marked up when sold online (rather than having the reseller mark up the products)

How much more are products making online than in reseller network

How much is the markup from the reseller price to the web price?

Any more ideas?

10

Metrics to add to the Fact table

3. Add to FactReseller_Sales table.

Profitability in the reseller network

ProfitPerUnit = FactResellerSales[UnitPrice] - RELATED(AW_Products_Flattened[Cost])

ProfitPerUnit2 = FactResellerSales[UnitPrice] - FactResellerSales[ProductStandardCost]

The .pbix tabs 6-8 use this calculation.

Add a Year Qtr column to the fact table first using this formula

YearQtr = FactResellerSales[OrderDate].[Year] & " " & FactResellerSales[OrderDate].[Quarter]

Here we see the profitability of an item (or model, sub-category, category) in the reseller channel over time. We get the unit price the product sold at from the transaction table and look back into the products table for the cost.

In this dataset the fact table also has a column that has the standard cost for each product so we create the field two different ways. The standard cost might not be the same in both tables so it is important to check this.

11

12

This is slide #8. The profit per unit can be aggregated over time period to determine seasonality of category/sub-category/Model. You can show this data for one category as shown here or by all categories to see an overall picture as shown in the next report.

13

Add these calculated columns to the Factreseller Sales Column

1 ‘put this version of the formula into the fact tableV3: ActualProfitforProductFRS = FactResellerSales[OrderQuantity] * FactResellerSales[ProfitPerUnit2]

2 SalesAmount = (FactResellerSales[UnitPrice] * FactResellerSales[OrderQuantity]) - FactResellerSales[DiscountAmount]

The sales amount field was already in the source data. This is one way that you would calculate that though.

3 LineItemCostPerUnit = RELATED(AW_Products_Flattened[Cost])

The unit cost for each product is master data and is retrieved from the Products table. Here we use the RELATED function -- which is similar to VLOOKUP()

4 LineItemTotalCost = FactResellerSales[LineItemCostPerUnit] * FactResellerSales[OrderQuantity]

Or

LineItemTotalCost = RELATED(AW_Products_Flattened[Cost]) * FactResellerSales[OrderQuantity]

We want to figure out the profitability of each unit of the product, and the total profitability of each line item which can then be aggregated to the (which changes in part due to promotions).

5 LineItemTotalProfit = FactResellerSales[SalesAmount] - FactResellerSales[LineItemTotalCost]

-----------another way---------------------

LineItemProfit = FactResellerSales[LineItemProfitPerUnit] * FactResellerSales[OrderQuantity]

The thing to remember is that values are calculated for every row of the column being created, so it can be slow if you have millions fo rows of data.

6 LineItemProfitPerUnit = FactResellerSales[UnitPrice] - FactResellerSales[LineItemCostPerUnit]

14

Or

ProfitPerUnit2 = FactResellerSales[UnitPrice] - FactResellerSales[ProductStandardCost]

Or

ProfitPerUnit = FactResellerSales[UnitPrice] - RELATED(AW_Products_Flattened[Cost])

7 GrossMargin = FactResellerSales[LineItemProfitPerUnit]/FactResellerSales[UnitPrice]

8 Discount% = FactResellerSales[DiscountAmount]/FactResellerSales[SalesAmount]

15