User Data Processing and Storage

This page describes how Genesys Info Mart processes and stores attached user data.

Processing User Data

There are two types of KVP data (referred to as user data, when discussed collectively elsewhere in this document):

• Call-based attached data
• UserEvent-based KVP data, which allows the agent to associate KVP data with a voice interaction after the voice interaction has ended (that is, after the call is released)

Genesys Info Mart uses the same, unified mechanism to process these two data types.

By content, user data can also be divided as follows:

• High-cardinality user data
• Low-cardinality user data

How Genesys Info Mart Processes User Data

The following high-level algorithms help you understand how Genesys Info Mart processes user data.

1. Genesys Info Mart Server extracts user data along with other interaction data from one or more IDBs.
2. Global Interaction Database (GIDB), which is a set of tables within the Info Mart database schema, stores the extracted user data for future processing.

3. Genesys Info Mart processes the user data and creates records in relevant user-data tables (predefined or custom). Genesys Info Mart uses customer-configured mapping rules to identify in which user-data tables to store certain KVP values. Typically, low-cardinality data is expected to be stored in dimension tables, while high-cardinality data is expected to be stored in fact extension tables.

   The value that is stored — for example, whether it is the ending value or the first changed value of the KVP during the timespan of the interaction resource fact — depends on the propagation rule specified in the mapping. For more information, see Propagation Rules.

   If no value is received for a customer-mapped KVP that has been included in the schema, Genesys Info Mart uses the default value that you specify in the user-data script (see Step 4(d) in Planning for User Data Reporting).

4. In the case of user data that you have configured Genesys Info Mart to store as date/time, Genesys Info Mart converts the KVP value to a date/time using the Genesys Info Mart default format for date/time (yyyy-mm-ddThh24:mi:ss.ff), unless you have specified an alternative conversion expression. For more information about customizing the date conversion, see Preparing Custom User-Data Storage.
5. If the attempt to convert a KVP value or to store it in a user-data table column fails, the transformation job itself does not fail. Instead, Genesys Info Mart logs a message about the failure and, for each invalid KVP value, inserts a record into the STG_TRANSFORM_DISCARDS table and uses the default value that you specified in the user-data script. This exception-handling behavior applies both to user-data facts and to user-data dimensions.
6. During data transformation, Genesys Info Mart Server identifies whether the newly extracted user data should be associated with any INTERACTION_RESOURCE_FACT (IRF) records. Provided that the link-msf-userdata configuration option has been enabled on the applicable DN or Script objects or, starting with release 8.5.003, the equivalent media-specific options (link-msf-userdata-voice or link-msf-userdata-mm) have been enabled on the Genesys Info Mart application object, the Genesys Info Mart Server also identifies whether the newly extracted user data should be associated with any MEDIATION_SEGMENT_FACT (MSF) records.
   • If the interaction data is processed in the same cycle with the user data, Genesys Info Mart creates an association between a user data record and a newly created IRF or MSF record.
   • If the interaction data was processed in a previous cycle (for example, the user data arrived after call completion), Genesys Info Mart updates records in user-data tables that are associated with the IRF or MSF records.

Limitations for User Data in MSFs

When Genesys Info Mart is configured to store user data for interactions that are in mediation, user data is reported for mediation segment facts in exactly the same way as for interaction resource facts, except for the following limitations:

• If more than one change in user data is reported for a multimedia interaction that exited one queue and entered another queue in the same second, Genesys Info Mart cannot distinguish which change relates to which mediation segment fact. In all the MSF records for that interaction, Genesys Info Mart reports the value of the last change that occurred in that second. This value might not be correct for all the queues.
• The PARTY propagation rule is not suitable for certain situations, as described in the notes about the PARTY propagation rule.

Related Information

For additional discussion of topics related to user-data processing in Genesys Info Mart, see User Data Sources and KVPs, User Data Mapping, and Propagation Rules.

Storing User Data

User data can be stored as facts or dimensions. Genesys Info Mart provides you with the flexibility to store the same key as a fact and as a dimension. Genesys Info Mart also provides the flexibility to store KVP values in user-data fact tables as a character data type, a numeric data type, or a date/time data type.

High-Cardinality User Data

High-cardinality user data (data for which there can be a very large number of possible values) is stored as facts. Although there are no absolute limits on the quantity of high-cardinality user data that you can store, be mindful of database storage space and database performance. The following fact extension tables are used for storage of predefined high-cardinality user data:

• IRF_USER_DATA_GEN_1.
• Custom fact extension tables. (Use the sample script that is provided for the IRF_USER_DATA_CUST_1 table to add these tables.)

Each interaction has no more than one value for each user-data type. A Customer ID number is an example of high-cardinality user data.

Low-Cardinality User Data

Low-cardinality user data (data that has a limited range of possible values) is most efficiently stored as dimensions. The following dimension tables are used for storage of predefined low-cardinality user data:

• INTERACTION_DESCRIPTOR.
• Custom dimension tables. (Use the sample script that is provided for the USER_DATA_CUST_DIM_1 table to add these tables.)

There might be multiple values of a specific type for a single interaction. A “new customer” flag, which has only two values — Y and N — in a respective database column is an example of a low-cardinality user data. Service type is another example of data that has a limited number of possible values.

When you add custom tables to the Info Mart database, keep in mind the following limitation: The upper limit for low-cardinality user data is 800 custom dimension tables.

There is no simple rule about where the cutoff is between low-cardinality data and high-cardinality data, in terms of numbers of possible values for a KVP. For any given set of KVPs that will be stored in the same table, the number of combinations is a more important consideration than the number of possible values for each KVP. Genesys recommends that the number of rows in any dimension table not exceed 50,000.