Interaction History is the Pega Decision Management data layer that stores all interactions with customers (responses to given propositions). Information that is collected during each interaction is written into the appropriate Interaction History database table. Each database table contains several default properties defined on the corresponding class.
Database administrators can use the database schema to learn about the relationship between the database tables. They need to understand the flow of data between the Pega 7 Platform and the database and know how particular data types are split between the tables. First of all, this kind of information makes it easier to perform maintenance (extend the database, modify the properties, or move the tables to another database) and backup operations. Secondly, it speeds up and makes the Interaction History troubleshooting procedures more efficient.
Interaction History database tables
To minimize duplication of data, Interaction History uses a star schema that consists of one fact table, eight dimension tables, and one identity matching table. Interaction results are represented in the form of fact records and dimension information. The data that is stored in each dimension table is not duplicated but reused in the fact table. The fact table uses a reference to the properties and values in the dimension tables. By default, Interaction History tables are part of the PegaDATA schema.
The following table describes each Interaction History (IH) table and the name of the class to which it belongs.
Principal fact table that contains foreign keys to the dimension tables, measurements, and fact properties. Measurements are numeric fact properties that can be used as key performance indicators (KPIs).
Action dimension table that stores information about what was offered or presented to the customer (proposition). Propositions are uniquely identified by a combination of their business issue, group, and name. Examples of propositions include: advertisements, products, and offer bundles.
Application dimension table that stores information about the decision path that issued the action (application name, interaction rule name, strategy rule name, component name).
Channel dimension table that stores information about the channel that was used in the interaction with the customer and the direction of this interaction. For example, the channel of the interaction can be web or call center; the direction can be inbound or outbound.
Context dimension table that stores information about the reason for the action.
Customer dimension table that stores information about the characteristics of the customer who was offered the proposition, for example, information about customer segment or subsegment.
The modelcontrolgroup column in the customer dimension table indicates if the propensity of a model was used, or if the customer was part of a control group. This field is used to measure the lift of models, defined as the increase in the success rate when the propensity is used. In the control group, a random propensity or another type of benchmark would be used.
Location dimension table that stores information about the location of the customer when the interaction took place.
Operator dimension table that stores information about who handled the interaction. For example, information about the organization or division to which the operator belongs.
Outcome dimension table that stores information about the result of the interaction, for example, information that the proposition was accepted or rejected.
Identity matching table that represents the associations between records for the same identity (the same customer) but with a different subject ID.
The primary key of each dimension table is a 64-bit hash code that consists of the property names and values of that dimension. The primary key of each dimension table is named pzID.
The foreign keys are also 64-bit long values. The foreign keys for each dimension table in the fact table manage the relation between fact and dimension tables. In the Pega 7 Platform, this relation is captured in association rules under the Data-Decision-IH-Fact class to facilitate building reports on Interaction History. For example, when building a report based on the fact class, you can add pxActionDimension.pyIssue to join the pyIssueproperty of the action dimension.
The following table presents the foreign keys for each dimension table with the corresponding association rule.
|Dimension||Foreign key||Association rule|
Interaction History properties
The Strategy Result (SR) class provides the basis for building the fact and dimension records. Interaction History properties are organized in logical groups according to the property type. When strategy results are written to Interaction History, properties are split into fact and dimension properties, and saved into the appropriate table. Properties that are used to build fact and dimension records are mapped to database columns that are defined in the SR class data and Interaction History. The name of an Interaction History property is used to identify the property in the SR class. Properties that are defined in the SR class but are not present in Interaction History are not considered when writing results to the fact and dimension tables. Similarly, properties that are defined in the Interaction History but are not present in the SR class are not considered when retrieving data from the Interaction History. The name of an Interaction History property must be the same as the column name; something that applies to any of the default properties, as well as any property that is the result of extending Interaction History.
For a list of Interaction History properties, see Pega Customer Decision Hub Interaction History data model.