Oracle^® Marketing Segmentation Guide > Installing and Administering Segmentation and List Generation > Configuring Marketing Segmentation >

Manage Metadata for Marketing

To support the segmentation process, the Oracle BI Administration Tool provides a special set of Marketing metadata. This section describes the following Marketing metadata entities:

• Defining Segmentation Catalogs
• Administering Sampling Factors
• Configuring List Catalogs

For more information about configuring marketing segmentation metadata, see Configuring Marketing Segmentation Metadata.

Defining Segmentation Catalogs

A segmentation catalog is an Oracle BI subject area (presentation catalog) that is enabled for segmentation. The segmentation catalog provides a set of dimensions and fact measures that can be used to create segment criteria. The Marketing Segmentation user interface combines the counts across segmentation catalogs using the KEEP/ADD/REMOVE operators. A segmentation catalog must contain mappings from only one physical star or snowflake schema.

To define a segmentation catalog, use the following guidelines

• Explicitly associate the presentation catalog with a target level. This makes the catalog visible in the Marketing Segmentation user interface.
• Identify the column in the segmentation catalog that needs to be counted for the target level. If the physical star schema of the segmentation catalog does not contain the dimension that needs to be counted for the Target Level, a conforming dimension needs to be identified.
• Specify an implicit fact for each presentation catalog that is enabled as a segmentation catalog. This is required because two different segmentation catalogs can contain the same two dimensions. This can result in an ambiguous query to the database. This implicit fact column must be an aggregate measure that is not filtered. This is typically the measure that counts the primary key column on the fact table.

For example, there might be many star schemas in the database that have the Campaign dimension and the Customer dimension, such as the following stars:

• Campaign History star. Stores customers targeted in campaign.
• Campaign Response star. Stores customer responses to a campaign.
• Order star. Stores customers who placed orders as a result of a campaign.

In this example, because Campaign and Customer information might appear in many segmentation catalogs, users selecting to count customers from the targeted campaigns catalog would be expecting to count customers that have been targeted in specific campaigns.

To make sure that the join relationship between Customers and Campaigns is through the campaign history fact table, a campaign history implicit fact needs to be specified in Campaign History segmentation catalog.

Consider the following guidelines when creating segmentation catalogs:

• Create each segmentation catalog so that all columns come from only one physical star.
• Because the Marketing Segmentation user interface has special features for users to specify their aggregations, level-based measures typically are not exposed to segmentation users in a segmentation catalog.

Administering Sampling Factors

Complex segmentation criteria evaluated against a large database can take significant time to execute. Initially, marketing users might be satisfied with an approximate count so that they can execute counts more quickly, and then adjust the criteria until they obtain more precise counts.

To facilitate quick counts, the Marketing Server can execute segmentation criteria against a sampled subset of the target-level data. Sampling works on the principle that if the segmentation criteria are applied to the sampled subset of customers, and then subsequently to each of the stars accessed by the segment criteria, the final count is a good approximation of the actual (100 percent) counts and executes more quickly.

Sampling is defined by creating a subset table for a target-level dimension table that contains the same set of columns, but only a percentage of the data. For every sampling factor a database table needs to be created. Each sampling definition includes a percentage value to indicate the sampling factor. Every target level can have many sampling factors (and corresponding sampled dimension tables) to provide multiple levels of sampling.

When you enable sampling, the Marketing Server continues to generate the same logical SQL. However, the BI Server generates physical SQL that queries against the configured sample tables using dynamic table names. For the dimension table (such as the Contact dimension table) that contains all target-level IDs, a dynamic table name is associated with the target-level table. If the value of the dynamic table name session variable is set to the sampled table, then all queries executed in that session that include the customer dimension table are executed against the sampled table. The session variable is automatically set to the appropriate sampling table, depending on the sampling factor chosen in the user interface for all counting tasks.

Make sure the sampled table contains a true random sample of the customers. The choice of the randomization method is determined by the business users and administrators. The technique chosen here dramatically affects the degree of accuracy of the sampled counts.

NOTE:  Taking the first, specified-percent of rows from a target-level table, does not usually yield a random sample.

Configuring List Catalogs

Use List catalogs to create supplier files for campaign fulfillment or files for loading a campaign with appropriate targets. An Oracle BI Subject Area is a list catalog in the Presentation layer of the Oracle BI Administration Tool that is enabled for list format design (list generation). The list catalog provides a set of columns that can be used to generate the content in a list file or used to filter the results of the list file. Because not all presentation catalogs are appropriate for use as a list catalog, enabling a list catalog requires the following configuration:

Configuration for changing the level of detail of the list generation query

Unlike a segmentation catalog, a list catalog can contain information from multiple facts and data sources. This is often required because the content of export files might include a set of columns that span across several facts.

When generating a list, marketers usually need all columns in the list to show information at the target level such as Individual, Account, and Household. However, measures in a report are typically reported by dimensions placed in the report. To make sure that these measures evaluate at the Target Level, the business model for these List catalogs needs modifications.

For a standard presentation catalog, a query returns all rows in the data that satisfy the filter criteria, whether or not there is a single row for each target level. For example, if the list format contains columns for Contact Name, Asset Number, and Order Revenue, then the Revenue information is returned for every Asset that the contact owns.

To compensate for this behavior, a list catalog needs to be configured so that a single row can be returned for each target level when required. This is accomplished by creating a metadata metric that ranks on the secondary attribute by the target level. For example, to pull the first asset for each contact, create a rank on the asset name by contact.

Configuration to eliminate query ambiguity

Often presentation catalogs are created that span the same dimension in multiple facts. For example, if Assets are queried, there is potential ambiguity because it is unclear whether you intended to retrieve assets that the target level (Contact) owns (Asset star), assets that have been serviced (Service Request star), or assets that are expiring (Contracts star). A query from each of these stars likely returns a different set of target-level IDs. In a list generation query, avoid ambiguity about the source of the asset dimension data and related target-level IDs.

To make sure that dimensional entities such as Assets and fact measures such as Revenue appear at the target level and that ambiguities between dimensions are eliminated, the business model mappings in the Administration Tool needs to be different than what is typically used for reporting. Therefore, an existing catalog used for reporting is usually not appropriate. You must create new business models and new catalogs in the Administration Tool to be specifically used for list output.

List catalogs fall into the following categories, each supporting different business requirements:

• List Output Catalogs. When a campaign is launched and a list of targets needs to be generated for channel-related fulfillment, list catalogs are used to extract the members of the campaign and their related contact information. In the Siebel Marketing application, this type of list catalog is used for supplier files (List Export formats) and Email Server formats.
• Campaign Load Catalogs. When you finish designing the segment criteria, the next step is to load the target members of the segment into a campaign for execution. For Siebel users of the Marketing application, the task of loading segment members into the campaign history is performed by a workflow process leveraging the enterprise application integration (EAI) interface.

  This process expects the list file of segment members to be formatted according to EAI specifications, in which each column header must exactly match the name of the Integration Component and Integration Component field name where the data loads. List catalogs used for the Campaign Load process are configured so that the presentation column names match the Integration Component field names expected by the EAI process.

Lists for campaign load and list output can be invoked from an external application using SOAP APIs and then the Siebel Marketing Server can be integrated into a third-party campaign management system. For more information about marketing specific SOAP APIs, see SOAP Calls for Marketing Segmentation.

Caching

Segmentation criteria blocks that count target-level identifiers can be used frequently. For example, an email marketer can always exclude contacts with no email address or those that have explicitly refused to receive emails. Instead of evaluating this set of contacts repeatedly in every segment, the marketer might create a single criteria block using this criterion. Caching such a criteria block saves the list of target-level identifiers in a table. When you reuse this criterion across segments that you create, the cache is used and time-consuming database query operations are minimized, improving throughput.

The set of tables that contain the cache information, the mappings of those tables in the Administration Tool, and assigning cache table schema to specific target levels, constitute the cache related metadata.

Saved Result Sets

The resulting set of target-level identifiers of complex segmentation criteria can be saved permanently (until explicitly deleted). The saved result set can be used in other segments but more importantly it can be used to keep track of which targets joined and left a segment. This kind of an analysis helps marketers understand the dynamic behavior of the customer base. The target-level identifiers are stored in a table. The set of tables that contain the saved result set information, the mappings of those tables in the Administration Tool and the assigning of saved result set schema to specific target levels, all constitute the related metadata.

NOTE:  When you have created the metadata, you must test the integrated environment.If you customize your data warehouse with a new column and you want Marketing to access the new column, make sure that the column is exposed in all three layers of the BI repository.

For more information, see Configuring Marketing Segmentation Metadata.