Simple Metric: A basic metric with a simple function or formula applied. Example: Sum(revenue).
Compound Metric: A metric defined with a non-aggregate function over and other metric OR an arithmetic operator used to combine two metric. Note that level, condition or transformation can not be applied on a compound metric. Example 1: Runningavg(cost) where “cost” is a metric. Example 2: Metric1 + Metric2.
Conditional Metric: A filter applied to a metric.
Level Metric: Level metric defined the level at which the metric aggregates. By default it is the report level. This is a bit huge concept and more information could be found in the manuals.
Transformation Metric: Transformation applied to a metric. Transformation is a schema object which is used in a metric for time based analysis (Example: Year-over-Year, Month-to-Date, Year-to-Date, etc.). There are two types of transformation – table based and expression based.
Pass through Metrics: Metric created using pass through functions (example: ApplySimple). Pass through functions are executed at the database level.
Adaptive Metric: A metric defined on a fact which is mapped to two columns in two tables (detail and aggregate) with different functions applied on both the columns. This is achieved with pass through functions (ApplySimple and ApplyAgg).
Non-aggregate metric: By default metrics aggregate to a higher level based on the attributes on a report, the default aggregate function is “sum”. This aggregation can be set to none, so that the metric does not aggregate to any level.
Smart Metric: When a compound metric is defined with other metric objects using arithmetic operatic (like sum(M1/M2)) the sub total of the metric can be calculated in multiple ways. Case where they are calculated row by row are smart metric. Example: In the above example, if the total are calculated using the mentioned expression, it is defined as smart metric – “Sum (M1) / Sum (M2)”
Derived Metric: A metric created within a report (local to that report) using the report objects of the same report. Derived metric are OLAP services and are calculated on the I-Server and do not reflect in the SQL. Example: If a report has two metrics, M1 and M2. A derived metric can be defined as M1+M2 or M1/M2 and so on.
Embedded Metric: Embedded metrics are objects whose definitions and object IDs are unique to and exist only in the context of the MicroStrategy Report in which they reside. An embedded metric will have a different object ID than that from which it originated. As its name implies, an embedded metric does not exist outside the report object. In other words, that particular object’s definition and ID do not exist independently in the metadata object info and object definition tables and, therefore, cannot be used in other reports. Instead, the report definition contains an “embedded objects” folder as part of its definition (not a freestanding folder), and the embedded metric exist only in this folder. This is not an Derived metric. Embedded metrics are created when there exists a prompted filter in a conditional metric and where the report is saved after answering those prompts. The metric will have same definition as that of original metric but its ID will be different than that of the original metric. Hence any changes made to the original metric will not be reflected to the report. You need to remove the embedded metric and add again the original metric.