MicroStrategy ONE

Best practices for creating derived metrics

The list below presents guidelines you should follow when creating derived metrics:

  • You can define derived metrics with objects in the Report Objects pane. The Report Objects are the components included in the report definition, even if they are not added to the layout of the report.

  • A derived metric can be defined only with the metrics in the report definition. The Input Metric Formula dialog box where you create derived metrics allows you to choose only from objects included in the report definition, as shown below.

    Input Metric Formula dialog box

  • Attributes included in the report definition are also available to use in the definition of a derived metric. If you use an attribute as part of the metric definition, the metric calculation requires new report SQL to be executed against the data warehouse. This re-execution is not required for derived metrics that only use metrics in their definitions.

  • You can use one or more functions or operators in the formula of the metric. You can click the f(x) button to access available functions and operators.

  • You can change the level at which a derived metric is calculated. For example, the derived metric sum(M1){Attribute1} is calculated at the Attribute1 level. For information on metric levels, see the Advanced Reporting Help.

  • Any user can modify a derived metric after report execution, since its formula is visible to all users. If a derived metric should not be modified by end users, create the metric in the Metric Editor and add it to the report as a normal metric.

  • Transformation objects cannot be used with derived metrics as they require SQL to be re-executed against the data warehouse.

  • View filters can filter the results of a derived metric. A view filter is an additional filter applied in memory to the report results to restrict the amount of data displayed on the report. For more information on view filters, see About view filters.

  • Derived metrics cannot be used in a report limit. A report limit is a SQL engine function and therefore can only use a metric that exists in the project. A derived metric, which is created within the report, exists only in the report.

  • A derived metric is dependent on any report objects that are included in its definition. Because of this dependency, you cannot remove an object from the report that is used in a derived metric definition.

    If you try to remove a metric from the report, a message is displayed that indicates you cannot remove the metric because it is being used by the derived metric. You can, however, move a metric off the report grid so that it only appears in the Report Objects pane. This allows you to remove a metric from the report layout yet still support any derived metrics that are dependent on it.

You can create derived metrics with the following methods described below:

  • Creating derived metrics: You can create any type of derived metric by defining derived metric expressions using the Input Metric Formula dialog box.

  • Using rank and percent-to-total metric analysis: You can create derived metrics that display the percent in relation to a selected total of each item affected by the metric or display a ranking number to the metric values for a given attribute. These can be quickly created using shortcut metrics.

  • Create derived training metrics: You can also use derived metrics as part of Data Mining Services to create training metrics.