Skip to main content

Inputs for predictive metrics in Microstrategy

Inputs for predictive metrics

A predictive metric can be created using attributes and metrics as its inputs. How you define the attributes and metrics you use as inputs for your predictive metrics affects the resulting predictive metrics, as described in:
Attributes as inputs for predictive metrics
Level metrics as inputs for predictive metrics
Conditional metrics as inputs for predictive metrics

Attributes as inputs for predictive metrics

Attributes can be used as inputs for predictive metrics. Data mining often analyzes non-numeric, demographic, and psychographic information about customers, looking for attributes that are strong predictors.
For example, your MicroStrategy project contains a Customer attribute with related attributes for age, gender, and income. You can include an attribute, such as the Customer attribute, directly in a training metric, as described in Creating a predictive model using MicroStrategy.
By including an attribute directly in a training metric, a predictive metric is then created that includes the attribute as one of its inputs. When using attributes directly in training metrics to create predictive metrics, be aware of the following:
The ID attribute form for the attribute is used by the training metric to include the attribute information in a predictive metric. If attributes include additional attribute forms other than the ID form that are to be used as inputs for predictive metrics, you can create metrics based on these attribute forms. Once these metrics are created, they can then be used as inputs for predictive metrics. This scenario for creating attribute-based predictive metrics is described in Creating metrics to use additional attribute forms as inputs for predictive metrics below.
Attribute forms must use a text or numeric data type. If the attribute form uses a date data type, the data cannot be correctly represented when creating the predictive metric. If an attribute form uses date values, you must convert the date values into a numeric format to use the attribute form to create predictive metrics.

Creating metrics to use additional attribute forms as inputs for predictive metrics

If attributes include additional attribute forms other than their ID form that are to be used as inputs for predictive metrics, you can create metrics based on these attribute forms. The resulting metric can then be used as an input for a predictive metric, thus allowing the attribute information to be included in a predictive metric.
The steps below show you how to create a metric based on an attribute form. The resulting metric, which contains the attribute information, can then be used to create a predictive metric.
Prerequisite
This procedure assumes you are familiar with the process of creating a metric. For steps on how to create metrics, see Advanced Metrics.

To create metrics to use additional attribute forms as inputs for predictive metrics

1Using the Metric Editor, create a new metric expression. All metric expressions must have an aggregation function. To support including attribute information in the metric expression, in the Definition area, type Max() to use the Max aggregation function.
2Within the parentheses of the Max() aggregation function, specify the desired attribute form using the AttributeName@FormName format, where:
AttributeName: Is the name of the attribute. If there are spaces in the attribute name, you can enclose the attribute name in square brackets ([]).
FormName: Is the name of the attribute form. Be aware that this is different than the attribute form category. If there are spaces in the attribute form name, you can enclose the attribute form name in square brackets ([]).
For example, in the image shown below the Discount form of the Promotion attribute is included in the metric.
3Add the attribute as a metric level so that this metric always returns results at the level of the attribute.
4If the predictive metric is to be used to forecast values for elements that do not exist in your project, you must define the join type for the metric used as an input for the predictive metric to be an outer join. For example, the predictive metric is planned to forecast values for one year in the future. Since this future year is not represented in the project, you must define the join type for the metric used as an input for the predictive metric to be an outer join so that values are returned.
To enable outer joins to include all data:
aSelect Metric Join Type from the Tools menu. The Metric Join Type dialog box opens.
bClear the Use default inherited value check box.
cSelect Outer.
dClick OK to close the dialog box.
5If you plan to export predictive metric results to a third-party tool, you should define the column alias for the metric used as an input for the predictive metric. This ensures that the name of the metric used as an input for the predictive metric can be viewed when viewing the exported results in the third-party tool.
To create a metric column alias to ensure the column name matches the metric’s name:
aSelect Advanced Settings from the Tools menu, and then select Metric Column Options. The Metric Column Alias Options dialog box opens.
bIn the Column Name field, type the alias.
cClick OK to close the dialog box.
6Save the metric, using the alias from the previous step as the metric name. You can now include the metric in a training metric to create a predictive metric, as described in Creating a predictive model using MicroStrategy.

Level metrics as inputs for predictive metrics

The attribute used on the rows of the dataset report sets the level of the data by restricting the data to a particular level, or dimension, of the data model.
For example, if the Customer attribute is placed on the rows and the Revenue metric on the columns of a report, the data in the Revenue column is at the customer level. If the Revenue metric is used in the predictive model without any levels, then the data it produces changes based on the attribute of the report using the predictive metric. If Year is placed on the rows of the report described previously, the predictive metric calculates yearly revenue rather than customer revenue. Passing yearly revenue to a predictive model based on customer revenue yields the wrong results.
This problem can be easily resolved by creating a separate metric, which is then used as an input for the predictive metric. This separate metric can be created to match the metric definition for Revenue, but also define its level as Customer. This approach is better than adding a level directly to the Revenue metric itself because the Revenue metric may be used in other situations where the level should not be set to Customer. Such a metric would look like the following.
Prerequisite
This procedure assumes you are familiar with the process of creating a metric. For steps on how to create metrics, see Advanced Metrics.

To create level metrics to use as inputs for predictive metrics

1In the Metric Editor, open the metric that requires a level.
2Clear any Break-by parameters that may exist on the metric’s function:
aHighlight the function in the Definition pane to select it.
bRight-click the function and then select Function_Name parameters. The Parameters dialog box opens.
cOn the Break By tab, click Reset.
dClick OK to close the dialog box.
3Add the necessary attributes as metric levels:
aClick Level (Dimensionality) on the Metric component pane.
bIn the Object Browser, double-click each attribute to add as a level.
4If the predictive metric is to be used to forecast values for elements that do not exist in your project, you must define the join type for the metric used as an input for the predictive metric to be an outer join. For example, the predictive metric is planned to forecast values for one year in the future. Since this future year is not represented in the project, you must define the outer join type for the metric used as an input for the predictive metric so that values are returned.
To enable outer joins to include all data:
aSelect Metric Join Type from the Tools menu. The Metric Join Type dialog box opens.
bClear the Use default inherited value check box.
cSelect Outer.
dClick OK to close the dialog box.
5If you plan to export predictive metric results to a third-party tool, you should define the column alias for the metric used as an input for the predictive metric. This ensures that the name of the metric used as an input for the predictive metric can be viewed when viewing the exported results in the third-party tool.
To create a metric column alias to ensure the column name matches the metric’s name:
aSelect Advanced Settings from the Tools menu, and then select Metric Column Options. The Metric Column Alias Options dialog box opens.
bIn the Column Name field, type the alias.
cClick OK to close the dialog box.
6Save the metric with the alias name from the previous step. You can now include the metric in a training metric to create a predictive metric, as described in Creating a predictive model using MicroStrategy.

Conditional metrics as inputs for predictive metrics

To group a metric’s results by an attribute, create a conditional metric for each category. For example, you want to use customer revenue grouped by payment method in your data mining analysis. If you place the Customer attribute on the rows of the report, the Revenue metric on the columns, and the Payment Method attribute on the columns, you get the following report as a result:
However, this report presents problems if it is used as a dataset report because multiple headings are generated for all the columns, specifically, Revenue and each Payment Method. Additionally, each column is revenue for a particular payment method and unless there is a metric that matches this definition, it is difficult to successfully deploy any model that uses one of these columns.
To solve this problem, create a separate metric, which is then used as an input for a predictive metric, that filters Revenue for each Payment Method. This has the same definition as the original Revenue metric, but its conditionality is set to filter Revenue by a particular Payment Type.
Prerequisite
This procedure assumes you are familiar with the process of creating metrics and filters. For steps on how to create metrics, see Advanced Metrics. For steps on how to create filters, see Advanced Filters: Filtering Data on Reports.

To create a conditional predictive metric

1Create a separate filter for each of the necessary attribute elements. For the example above, they are Payment Method = Visa, Payment Method = Amex, Payment Method = Check, and so on.
2For each metric, create a separate metric to be used as an input for a predictive metric, as explained in the section above.
3Add the filters you created as conditions of the metric-based predictive input metric. Save the metric. You can now include the metric in a training metric to create a predictive metric, as described in Creating a predictive model using MicroStrategy.
The following report uses conditional metrics to generate the same results as the first report but in a dataset report format.

Comments

Post a Comment

Popular posts from this blog

Microstrategy Custom number formatting symbols

Custom number formatting symbols If none of the built-in number formats meet your needs, you can create your own custom format in the Number tab of the Format Cells dialog box. Select  Custom  as the Category and create the format using the number format symbols listed in the table below. Each custom format can have up to four optional sections, one each for: Positive numbers Negative numbers Zeros Text Each section is optional. Separate the sections by semicolons, as shown in the example below: #,###;(#,###);0;"Error: Entry must be numeric" For more examples, see  Custom number formatting examples . To jump to a section of the formatting symbol table, click one of the following: Numeric symbols Character/text symbols Date and time symbols Text color symbols Currency symbols Conditional symbols Numeric symbols For details on how numeric symbols apply to the Big Decimal data type, refer to the  Project Design Guide . ...

Error. Engine Attribute Role Limit Exceeded! To get rid off this error: (1) Turn off Engine Attribute Role setting in VLDB dialog

Error. Engine Attribute Role Limit Exceeded! Some times Microstrategy will give the below error when updating the schema after an attribute is created. MicroStrategy Developer --------------------------- Error(s) occurred while loading schema: [DFCSCHEMA] Population Exception: The object shown in the following hierarchy no longer exists in schema: -Table LKUP_TEST_FEE_SHIPMENTS error. Engine Attribute Role Limit Exceeded! To get rid off this error: (1) Turn off Engine Attribute Role setting in VLDB dialog; OR (2) Use Table Alias featureDSSSQLEngine: Schema loading error: Message from GetErrorInfo : Report cache is not found.. Error(s) occurred while loading schema: 63. CAUSE: This error message means that the table shown in the error text needs to be split into a very large number tables. MicroStrategy has a limitation that only allows one table to be split into no more than 100 tables. The error above is shown when this limitation is surpassed....

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:

Personalizing file locations, email and file subscriptions using macros in Microstrategy

Personalizing file locations MSTr allows to dynamically specify the  File Location  and  Backup File Location  in a file device using macros.  For example, if you specify the  File Location  as  C:\Reports\{&RecipientName}\ ,  all subscriptions using that file device are delivered to subfolders of  C:\Reports\ . Subscribed reports or documents for each recipient are delivered to a subfolder with that recipient’s name, such as  C:\Reports\Jane Smith\  or  C:\Reports\Hiro Protagonist\ . The table below lists the macros that can be used in the  File Location  and  Backup File Location  fields in a file device: Description Macro Date on which the subscription is sent {&Date} Time at which the subscription is sent {&Time} Name of the recipient {&RecipientName} User ID (32-character GUID) of the recipient {&RecipientID} Distribution Services add...

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...

Microstrategy Dossiers explained

Microstrategy  Dossiers With the release of MicroStrategy 10.9, we’ve taken a leap forward in our dashboarding capabilities by simplifying the user experience, adding storytelling, and collaboration.MSTR has  evolved dashboards to the point that they are more than dashboards - they are  interactive, collaborative analytic stories . Ultimately, it was time to go beyond dashboards, both in concept and in name, and so  the've  renamed VI dashboards to  ‘ dossiers ’.  Dossiers can be created by using the new Desktop product or Workstation or simply from the Web interface which replaces Visual Insights. All the existing visual Insights dashboards will be converted to Dossiers   With MicroStrategy 10.9, there was an active focus on making it easier to build dashboards for the widest audience of end users. To achieve this, some key new capabilities were added that make it easier to author, read, interact and collaborate on dashboards ...

"Table structure cannot read or update" in the warehouse catalog error while updating a table structure in Microstrategy

"Table structure cannot read or update"  in the warehouse catalog error while updating a table structure while using Warehouse Catalog in MicroStrategy Developer  This issue could be due to the incorrect prefix.  To fix the issue. 1. Open the Warehouse Catalog. 2. Select the table and assign the correct Prefix update the structure. 3. Save and close the warehouse catalog.

Derived metric based on attribute values

Derived metric based on attribute values Here is how could create and display data correctly on using below simple steps.  Create a report with Category, Subcategory and Revenue. Create New Metric in a report or VI.  Case((Category@ID = 1), Revenue, 0) Booksand Name it as Revenue for  where 2 is Category ID for "Books"  Report will display result as below.  Result for new metric is blank. Now to fix this create a new Derived metric on Category attribute first with formula as  Max(Category) {~ }  and calling Books Now Edit the "Revenue for Books metric and Replace Category@ID with this new Books metric formula would looks like this  Case((Books = 1), Revenue, 0).  Report result would now display as expected as shown below

Types of result caches in Microstrategy

Types of result caches Microstrategy The following types of  result caches are created by Intelligence Server: • Matching caches • History caches • Matching-History caches • XML caches All document caches are Matching caches; documents do not generate History caches or XML caches. Intelligent Cube reports do not create Matching caches. Matching caches Matching caches  are the  results of reports and documents that are retained for later use by the same requests later on. In general, Matching caches are the type of result caches that are used most often by Intelligence Server. When result caching is enabled, Intelligence Server determines for each request whether it can be served by an already existing Matching cache. If there is no match, it then runs the report or document on the database and creates a new Matching cache that can be reused if the same request is submitted again. This caching process is managed by the system administrator and ...

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...