Bookshelf Home | Contents | Index | PDF |
Oracle® Marketing Segmentation Guide > Configuring Marketing Module Metadata > Setting Up Marketing Segmentation Metadata > Setting Up the Marketing List CatalogsSetting up list catalogs is very similar to setting up any presentation catalog. A List catalog is used to generate a list of data at the target level. Lists are generated from a user interface (similar to Oracle BI Answers) that issues queries against the Oracle BI Server. Customers who purchase the Siebel Data Warehouse version 7.7.1 that contains Oracle BI metadata might find that for each of the target levels (Accounts and Contacts) one business model has been created. The following subject areas for list generation are preconfigured for your use:
These topics contain guidelines that you must apply when creating a Business Model in the Administration Tool for a list catalog. Marketers have similar requirements when it comes to list generation. Therefore, this topic contains the following topics for you to use as guidelines when setting up your list catalogs:
Gather a List of Facts and DimensionsGather the list of facts and dimensions that need to be used for the generation of the List. For every dimension, identify the fact that relates this dimension to the target level Dimension. When this dimension is mapped as a logical dimension in the Administration Tool, this fact is included in the logical table source as a join. Not doing so may result in ambiguous queries and incorrect list results. Define the Logical FactThe logical fact of this business model is usually non-restrictive but needs to be defined. In most business models, including the ones that are used for segmentation catalogs, the <target level> logical tables are mapped as dimensions. Therefore, these business models might not be used for generating lists. You must create new business models. This topic explains how to create these business models. Logical dimensions are joined to a logical fact table, as shown in Figure 2. Including Fact Information in List ReportsIf fact information needs to be included in the list reports, then each dimension needs to be mapped as dimension hierarchy. This is done because facts usually must be reported at the target level and not any other level. For example, if a list report contains the target level ID column such as Contact ID, Asset Name Column and a fact such as Total Value of Assets, then usually marketers require that the Total Value of Assets be reported at the Contact Level and not for every asset. In Figure 3, the Service Request fact is included in the business model but needs to be reported at only the Contact level and not the Account dimension. Therefore, a Service Request related facts have been set at the All level of the Account Dimension. The Oracle BI Server reads this information and interprets that there is no detail service request information in the database for Accounts and as a result, issues a physical SQL query for service requests that does not include Accounts. Business Models Extended for List GenerationCustomers who have purchased the Siebel Marketing product line from Oracle and who own the Siebel-provided List business models, have business models that have been extended to make sure that list generation occurs from contact information that resides in the transactional database. This is needed when marketers have added or deleted contacts manually after a campaign is loaded in the campaign contact table. When this happens, the list of target level IDs (contacts) as provided by the segment or segment tree, do not match what is in the campaign load. As a result, the output list needs to be generated from the transactional database campaign promotions table. In the data model, this table is the S_CAMP_CON table (OLTP Campaign Promotion). Figure 4 illustrates the following:
Setting Up Cross-Database JoinsIf list information needs to be generated from the data warehouse for the contacts in the transactional database Campaign history table (S_CAMP_CON), a cross-database join needs to be created. Oracle BI supports this type of cross-database join. To set up a cross-database join
Multiple Addresses for Individuals or AccountsWhen Individuals or Accounts have many addresses, the addresses are stored in a separate table. However, depending on the channel you use for targeting, email address might be more relevant than postal address. When a list is generated, an inner join with the address table might result in fewer contacts because some do not have address information. To prevent this from happening, by default the S_Contact table in the transactional database has a left outer join to the address table. A left outer join is used so that contacts with no addresses can be listed. Figure 5 is an example of a logical table source for the S_Contact table. |
Oracle® Marketing Segmentation Guide | Copyright © 2010, Oracle and/or its affiliates. All rights reserved. Legal Notices. | |