About cubes
A cube is the simultaneous segmentation of a list of IDs (most often a strategic segment) by the queries provided by a number of dimension hierarchies. After the cube is created, you can view segment cross-tab reports that drill into two dimensions of the cube at any given time.
Before you can create a cube, you must perform the following preliminary tasks:
*
Create a strategic segment
*
Create dimensions that are based on the strategic segment
*
The following guidelines apply to cubes:
*
Cube metrics can be defined as any Campaign expression with the following restrictions:
*
You can specify an unlimited number of additional NUMERIC metrics and Campaign will calculate min, max, sum, average for them. Selected metrics can be derived fields or persistent derived fields.
*
The aggregation function on cell count (min, max, avg, % of total no, and so on) is calculated automatically.
*
The aggregation function on an attribute value (for example, avg(age) ) automatically calculates min, max, sum, and average.
*
Expressions that contain multiple attribute values (for example, (attribute1 + attribute2) ) are supported in derived fields.
*
The Cube process supports derived fields and persistent derived fields.
*
Groupby expressions (for example, (groupby_where (ID, balance, avg, balance, (trxn_date > reference_date))) ) are supported in derived fields.
*
Expressions involving user variables (defined in same flowchart as cube process AND exposed to Distributed Marketing) are supported in derived and persistent derived fields. (For more information about Distributed Marketing, see the Distributed Marketing User's Guide.)
*
Expressions that use raw SQL are supported in a derived field that uses a raw SQL custom macro
*
Expressions that use a custom macro are supported in a derived field.
*
Although cubes are composed of up to three dimensions, metrics can be displayed for only two dimensions at a time. The undisplayed third dimension is still computed and stored on the server, but is not used in visual selection/reporting for that particular report.
*
Cubes can be built on cells as well as segments (which, for example, can be created at the transaction level). However, if a cube is built on a cell, the cube is available only in that flowchart. For that reason, you may want to base cubes on strategic segments.
*
Unless your tables are normalized, defining dimensions with a many-to-many relationship with the audience level could produce unexpected results. The cube algorithm relies on normalized tables. Before you select and build a cube, normalize data by rolling it up (to the customer level through a data prep session for example).
*
If you build a cube on non-normalized dimensions, the sum counts will be wrong in the crosstab reports, owing to the way that Campaign processes the dimension IDs. If you must use non-normalized dimensions, build cubes with only two dimensions and use transactions as the lowest level metric of the nonnormalized dimensions, rather than customer IDs, since the transaction sum will be correct.
*
When creating a cube dimension, you must give the dimension a name, audience level, and a table to correspond to the dimension. Later, when working in a session or a campaign flowchart, you map this dimension the same as if you were mapping a database table.
*
Cubes should be built when users are not accessing them, typically after business hours and on weekends.
Copyright IBM Corporation 2015. All Rights Reserved.