Siebel Marketing Installation and Administration Guide > Configuring Marketing Module Metadata > Setting Up Marketing Segmentation Metadata >
Setting Up the Marketing List Catalogs
Setting 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 Siebel Answers) that issues queries against the Siebel Analytics Server.
Customers who purchase the Siebel Data Warehouse version 7.7.1 that contains Siebel Analytics 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:
- Marketing Account List. Based on Marketing Account List Business model this catalog is used for List output generation at the Account target level.
- Marketing Contact List. Based on Marketing Contact List Business model this catalog is used for List output generation at the Contact target level.
- Campaign Load - Accounts. Based on Marketing Account List Business model this catalog is used for generation of data used by the Siebel EAI Campaign load process for the Account Target Level.
- Campaign Load - Contacts. Based on Marketing Contact List Business model this catalog is used for generation of data used by the Siebel EAI Campaign load process for the Contact Target Level.
- Campaign Load - Prospects. Based on Marketing Contact List Business model this catalog is used for generation of data used by the Siebel EAI Campaign load process for the Prospect Data only.
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 Dimensions
Gather 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 Fact
The 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 7.
Figure 7. Example Logical Dimensions Joined to a Logical Fact Table
Including Fact Information in List Reports
If 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 8, 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 Siebel Analytics 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.
Figure 8. Example of Service Request Fact Reported at the Contact Level
Business Models Extended for List Generation
Customers who have purchased the Siebel Marketing product line 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 Siebel 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 Siebel transactional database campaign promotions table.
In the Siebel data model, this table is the S_CAMP_CON table (OLTP Campaign Promotion). Figure 9 illustrates the following:
- The OLTP Campaign Promotion (S_CAMP_CON) table is snowflaked between the OLTP Contacts (S_CONTACT) table and the Contact (W_PERSON_D) table.
- The OLTP Campaign Promotion (S_CAMP_CON) table is also snowflaked between the OLTP Prospects (S_PRSP_CONTACT) table and the Contact (W_PERSON_D) table.
Setting Up Cross-Database Joins
If list information needs to be generated from the Data Warehouse for the contacts in the Siebel transactional database Campaign history table (S_CAMP_CON), a cross-database join needs to be created. Siebel Analytics supports this type of cross-database join.
To set up a cross-database join
- In the Administration Tool, in the Physical Layer, select the Siebel transactional database Campaign History Table and the target level dimension table in the Data Warehouse.
- Right-click and choose Physical Diagram, and then Selected objects only.
- Create a Physical Join using the following syntax:
<target level dimension>.<unique Id> = <Siebel transactional database Campaign History Table S_CAMP_CON>.<Key 01/02.../07>
For more information about which Key column to pick, see Designing Marketing List Formats.
Multiple Addresses for Individuals or Accounts
When 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 Siebel 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 10 is an example of a logical table source for the S_Contact table.
Figure 10. Example of Logical Table Source for S_Contact Table