Siebel Analytics Server Administration Guide > Configuring Marketing Module Metadata > About Marketing Segmentation Metadata >

Terminology Used for Marketing Metadata

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

Target Levels

A target level is the entity that a marketer wants to count. Target levels are usually customer types such as individuals, businesses, or households. However, in special circumstances a target level might also represent other entities such as bank accounts, opportunities or assets.

To support counting, the metadata definition for a target level specifies a column in the database table that uniquely identifies the target such as Customer-ID, Account-ID or Household-ID. Target levels can be combined in a segment. For example, a segment might be created that counts the number of contacts who live in households that satisfy a certain criteria.

Segmentation Catalogs

A segmentation catalog is a Siebel Analytics 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 module user interface combines the counts across segmentation catalogs using the KEEP/ADD/EXCLUDE operators. A segmentation catalog should 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 targeting level. This makes the catalog visible in the Marketing module user interface.
• Identify the column in the segmentation catalog which 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. For additional information about conforming dimensions, see Terminology Used for Marketing Metadata.
• 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 should 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. The following guidelines should be followed in creating segmentation catalogs:
  • Each segmentation catalog should be created so that all columns come from only one physical star.
  • Because the Marketing module user interface has special features that allow users to specify their aggregations, level-based measures typically should not be exposed to segmentation users in a segmentation catalog.

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 allows you to 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 star accessed by the segment criteria, the final count will be a good approximation of the actual (100 percent) counts and will execute 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 Analytics Server will generate 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 will be 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.

It is recommended that the sampled table contain a true random sample of the customers. The choice of the randomization method should be determined by the business users and system administrators. The technique chosen here will dramatically impact the degree of accuracy of the sampled counts.

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

Conforming Dimensions

Conforming dimensions can be used when a star might include a dimension with the target-level ID. A conforming dimension links a fact that contains target-level IDs to a fact that does not contain target-level IDs by navigating along a dimension that shared by both fact tables.

For example, a bank might track service requests at the bank-account level only and the Service Request star does not include the customer dimension. To be able to count the number of contacts who have filed a certain number of service requests, a conforming dimension is required. In this case, the conforming dimension is the Bank Account dimension, because it is a dimension shared by both the Service Request star and another star containing the Bank Account dimension, such as the Customer Profile star. To evaluate this count, the Marketing Server determines the bank accounts that satisfy the service request criteria, and then finds all customers who join to those bank accounts using a subquery. For more information, see Setting Up Conforming Dimensions.

List Catalogs

List catalogs are used to create vendor files for campaign fulfillment or files for loading a campaign with appropriate targets. A Siebel Analytics Subject Area is a list catalog in the Presentation layer of the Siebel Analytics 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. Enabling a list catalog requires a few configuration steps because not all presentation catalogs are appropriate for use as a list catalog.

• 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 need to 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 more information about building a business model, see Setting up the Marketing List Catalogs. 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 per target level. For example, if the list format contains columns for Contact Name, Asset Number, and Order Revenue, then the Revenue information will be 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 which are expiring (Contracts star). A query from each of these stars will likely return a different set of target-level IDs. In a list generation query, there should be no ambiguity as to 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 need to 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 vendor 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. Within the Siebel Marketing application the task of loading segment members into the campaign history is performed by a workflow process leveraging the Siebel EAI interface. This process expects the list file of segment members to be formatted according to EAI specifications, which means that each column header must exactly match the name of the Integration Component and Integration Component field name where the data will be loaded. List catalogs used for the Campaign Load process are configured so that all 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 SOAP APIs, see Siebel Analytics Web Administration Guide.

Qualified List Item (QLI)

A qualified list item (QLI) is an entity that is evaluated against segment criteria so that the information related to that entity can be exported in a list file. A QLI can be of type Primary or Secondary. A primary qualified list item is the presentation column that maps to the dimension key that is being counted for a target level such as Contact-ID for the contact target level. A secondary qualified list item is that which is primarily created for list exports. Using a QLI allows you to restrict the list based on the logic used in the segmentation criteria.

For example, you might have a segment containing all customers who have a vehicle lease expiring in less than two months. You plan to create a list for this segment and Vehicle ID is one of the list columns. If you do not create a secondary QLI, the list will contain all vehicles that the customers in the segment own and it will not matter if the lease expires in less than two months. If you create a secondary QLI on the Vehicle-ID, the list will contain only vehicles with leases expiring in less than two months (qualified) from the segment.

For more information, see Setting Up Marketing Qualified List Items.

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 with the criteria mentioned above. Caching such a criteria block saves the list of target-level identifiers in a prespecified table. When you reuse this criteria across segments that you create, the cache is used and time-consuming database query operations are minimized, improving system 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.