Skip to main content

Level metrics in Microstartegy/MSTR

Level Metrics

Level metrics allows the users to choose the right combination of level target, filtering, and grouping (referred to as elements) to achieve your desired results. 

The elements of a metric level are described below:
Target: The target is the attribute level at which the metric calculation groups. For a more detailed description, see Target: The context of a calculation.
Grouping: Grouping determines how the metric aggregates. For a more detailed description, see Grouping: How aggregation is performed.
Filtering: Filtering governs how the report filter interacts with the metric calculation. For a more detailed description, see Filtering: Interaction with report filters.

The level is indicated between the curly braces ({ }) in the metric definition shown below:

Sum(Revenue) {~, Product}

The tilde (~) represents the report level with standard filtering, denoted by the plus sign (+). If you add item as a level, the metric definition changes to reflect the addition:

Below metric indicates that it is at report level:

Sum(Revenue) {~+}

When you remove the report level and the metric is at Item level only:

Sum(Revenue) {Item}

The base metric and report


All the metrics in this section are based on a revenue metric that is the sum of the Revenue fact. The base report displayed below contains this Revenue metric, and the Category and Subcategory attributes. Each category is subtotaled, and a grand total is calculated. It has a report filter on the following subcategories:
Art & Architecture
Literature
Drama
Alternative
The base report is shown below:

Level metrics summary table

The Revenue metric calculates the revenue for each subcategory displayed on the report.
To Calculate
Set Filtering To
Set Grouping To
Revenue at the category level, including only the subcategories displayed on the report
Standard
Standard
Revenue at the category level, for all subcategories in the categories displayed on the report
Absolute
Standard
Total revenue for the subcategories displayed on the report
Standard
None
Total revenue for all subcategories in the categories displayed on the report
Absolute
None
Total revenue for all subcategories in the project
Ignore
None
All the level metrics described in this section have a target of Category.

Category revenue examples

The following report shows the base report with the addition of two new metrics, both measuring category revenue in different ways.
Notice that the Category Revenue for Displayed Subcategories metric returns the same number as the category subtotal. The Art & Architecture and Literature columns are the same as the Books Total. Why?
Standard filtering allows the report filter to interact as usual in the metric calculation. Therefore, only the subcategories in the report filter are included in the metric calculation. This is affirmed by the grand total of this metric—it matches the total for the Revenue metric. This indicates that only the attributes displayed on the report are included in this Category Revenue metric.
The numbers returned by the Category Revenue for All Subcategories in Displayed Categories metric are higher than the numbers for the other metrics on the report. Why?
Absolute filtering changes the filter on children of the target, by raising it to the level of the target, if possible. In this example, the report filter is Subcategory, which is a child of Category, the level target. Since the report filter is on a lower level than the target, the filter is raised to the level of the target. All subcategories in the categories on the report are included in the metric calculation.
Why do the Category Revenue metrics calculate the same number for each row in a particular category?
Both metrics have standard grouping, which means that the metric groups by the attribute level of the target. In this case, the target is category. The metric calculation is rolled up to Category, so the same number is repeated for each row in a particular category.

Total revenue examples

The following report shows the base report with the addition of three new metrics, all measuring total revenue.
The most obvious difference between this report and the Category Revenue example above is that each column contains only one number; each metric is returning only one result, regardless of row. Why?
All the metrics on this report, except for Revenue, have grouping set to none. No grouping means that the metric does not group on the target of category or the target’s child attributes, such as subcategory. Therefore, separate results are not calculated for the different attributes on the report; only one result is calculated.
The Total Revenue for Displayed Subcategories metric returns the same number as the total for the Revenue metric. Why?
Standard filtering allows the report filter to affect the metric. Therefore, only the subcategories in the report filter are included in the metric calculation. This is confirmed by the number matching the total for the Revenue metric. This indicates that only the attributes displayed on the report are included in this Total Revenue metric.
Refer to the report in Category revenue examples. Notice that the total for the Category Revenue for All Subcategories in Displayed Categories metric is the same amount calculated for the Total Revenue for All Subcategories in Displayed Categories metric on the total revenue report. Why?
Both metrics have filtering set to absolute. Absolute filtering raises the report filter to the level of the target, so all subcategories in the categories included on the report are added together.
The result for the Total Revenue for All Subcategories metric is huge. Why?
It includes the total revenue for all subcategories in the entire project. Ignore filtering disregards filtering criteria based on the attribute in the target and its related attributes (both parents and children). In this case, subcategory in the report filter is ignored, so the report filter does not apply to this metric.

Comments

Popular posts from this blog

Fact tables levels tables in Microstrategy explained

Fact tables levels in Microstrategy: Fact tables are used to store fact data. Fact tables should contain attribute Id's and fact values which are measurable. All the descriptive information about the fact tables should stored in Dimension tables either in Star Schema fashion or Snow Flake Schema fashion which is best suited to your reporting solution. Since attributes provide context for fact values, both fact columns and attribute ID columns are included in fact tables. Facts help to link indirectly related attributes using these attribute ID columns. The attribute ID columns included in a fact table represent the level at which the facts in that table are stored. So the level of a fact table in the Fact_Item_Day_Customer can be the attribute Id's which is at Day, Item & Customer Id level. For example, fact tables containing sales and inventory data look like the tables shown in the following diagram: Base fact columns ver...

Case functions Microstrategy

Ca se functions Microstrategy Case functions return specified data in a SQL query based on the evaluation of user-defined conditions. In general, a user specifies a list of conditions and corresponding return values. Case This function evaluates multiple expressions until a condition is determined to be true, then returns a corresponding value. If all conditions are false, a default value is returned.  Case  can be used for categorizing data based on multiple conditions. This is a single-value function. Syntax Case ( Condition1 ,  ReturnValue1 ,  Condition2 , ReturnValue2 ,...,  DefaultValue ) Example Case(([Total Revenue] < 300000), 0, ([Total Revenue] < 600000), 1, 2) sum(Case (Day@DESC in (“Sat”,”Sun”), Sales, 0) {~+} Sum(Case(Category@DESC In("Books","Electronics"),Revenue,0)){~+} CaseV (case vector) CaseV  evaluates a single metric and returns different values according to the results. It can be used to perfo...

Optimizing queries in Microstrategy using VLDB properties

Optimizing queries in  Microstrategy using VLDB properties #vldb #vldbproperties The table b elow summarizes the Query Optimizations VLDB properties. Additional details about each property, including examples where necessary, are provided in the sections following the table. Property Description Possible Values Default Value Additional Final Pass Option Determines whether the Engine calculates...

Microstrategy "Error type: Odbc error. Odbc operation attempted

 "Error type: Odbc error. Odbc operation attempted: SQLExecDirect. [HYT00:0: on SQLHANDLE] [MicroStrategy][ODBC Oracle Wire Protocol driver]Timeout expired" is shown when executing reports from Web When users are trying to execute some reports in MicroStrategy web in particular, they may receive the Error “SQL Generation Complete Index out of range” and “Timeout expired” error as shown below: Possible Causes: One possible cause is that the MicroStrategy Intelligence Server using a cached database connection that was already dropped by the RDBMS. To resolve this: Admin should delete the database connection caches and create a new DSNs in case they are sharing DSNs to connect to different databases. In addition, change the settings for the ‘Connection lifetime’ and the ‘Connection idle time out’.  Follow the steps below to perform the mentioned changes and verify the report after each step and some of the settings require i-server r...

Control the display of null and zero metric values

Show   Control the display of null and zero metric values in a grid report You can determine how to display or hide rows and columns in a grid report that consist only of null or zero metric values. You can have MicroStrategy hide the rows and columns in the following ways: Hide rows and columns that consist only of null metric values Hide rows and columns that consist only of zero metric values Hide rows and columns that consist only of null or zero metric values (default) Once you have defined how MicroStrategy hides null and zero metric values in the grid, you can quickly show or hide the grid using the Hide Nulls/Zeros option in the Data menu, as described below, or by clicking the  Hide Nulls/Zeros  icon  in the Data toolbar. To determine how null and zero metric values are displayed or hidden in a grid report Open the report in Edit mode. From the  Tools  menu, select  Report Options . The Report Options...

Settings for Outer Join between metrics in MicroStrategy

Settings for Outer Join between metrics in MicroStrategy MicroStrategy adopts multi-pass logic to determine the execution plan for a report. This means that every metric is evaluated in separate SQL passes. Outer Joins come into play when MicroStrategy Engine merges the results from all SQL passes into one report. For a multi-pass report, different Outer Join behaviors can give the user completely different results. In addition, report metrics can be of different types which can, in some cases, influence the result of the outer join. In MicroStrategy, there are two settings that users can access to control Outer Join behavior : Formula Join Type and Metric Join Type . Metric Join Type: VLDB Setting at Database Instance Level Report and Template Levels Report Editor > Data > Report Data Options Metric Level   Metric editor > Tools > Metric Join Type Control Join between Metrics Formula Join Type: Only at Compound/Split...

System Manager workflow to execute on a schedule

Creating a System Manager workflow to execute on a schedule System Manager workflow can execute on a schedule or after an event has been triggered. This can be accomplished by creating a simple batch file, and scheduling that batch file to execute with a third-party tool like Microsoft Task Scheduler.   Note : To avoid user permission conflicts, the following steps must be performed with highest privileges.   In the below example, the workflow makes the i-server restarts every day.   1. The user must first have a valid workflow. This particular workflow is a template that is delivered out-of-the-box with System Manager.   2. Save the workflow in  .smw  format.   3. In a text editor (such as Notepad), enter the command line statement that the task scheduler should execute.     MASysMgr.exe -w C:\filename.smw” “UserName=User1 “Password=1234”   4. Save the file in  .bat  ...

Multi-Table Data Import(MTDI) from one or more supported data sources

Multi-Table Data Import(MTDI) from one or more supported data sources In MicroStrategy Analytics Enterprise Web 10 onewards, users can now simultaneously import two or more tables from one or more supported data sources, this feature is called Multi-Table Data Import (MTDI) which has been renamed as Super Cubes in MSTR 2019 (Does it sound like multisourcing for all the users without admin help?) Currently, all connectors in MicroStrategy Web 10 except " OLAP " and " Search Engine Indices " support Multi-Table Data Import. Users are able to add multiple tables/files when doing data import from single connector, as shown below: Users are also able to combine multiple tables/files from different sources and store them into one single Intelligent Cube, as shown below:
MicroStrategy Developer Preferences options are expanded so big that some options are being cutoff. Show the hidden objects in the  Microstrategy  developer MicroStrategy Developer Preferences options are expanded so big that some options are being cut off. The steps below given in the MSTR article may not work. This can be simple handled by using the steps below:  In the Microstrategy Developer go to Tools -> Preferences (Not my prefernces :) ) Under Developer category -> select Browsing on the browsing tab you see all the options like below: 3. Now using the mouse place the cursor on text box of 10000 which is next to 'Maximum number of monitoring objects displayed per page. 4. Then Hit Tab on Keyboard and hit another Tab on keyboard 5. Then press the space or down arrow on keyboard and click on OK or Enter. That will show the hidden objects in the Microstrategy developer   Normal Version ...

Fiscal Week, Fiscal Month, Fiscal Quarter and Fiscal Year calculations in Microstrategy

Fiscal Week, Fiscal Month, Fiscal Quarter and Fiscal Year calculations in Microstrategy FiscalWeek Returns the numeric position of a week within a fiscal year, for a given  input date. This function is useful in financial reporting when the start of the fiscal year is different than the start of the calendar year. Syntax FiscalWeek< firstWeekDay ,  firstMonth >( Date / Time ) Where: • Date / Time  is the input date or timestamp. • firstWeekDay  (default value is 1) is a parameter that determines which day of the week is considered as the first day of the week. You can type an integer value from 1 to 7, with 1 representing Sunday, 2 representing Monday, and so on until 7 representing Saturday. • firstMonth  (default value is 1) is a parameter that determines which month is considered as the start of the fiscal year. You can type an integer value from 1 to 12, with 1 representing January, 2 representing February, and so on until ...