max-thread-duration-after-inactive-in-days
Section: gim-etl
Default Value: 31
Valid Values: Any positive integer greater than days-to-keep-active-facts
Changes Take Effect: On the next ETL cycle
Dependencies: populate-thread-facts=true
Introduced: 8.1.1
Specifies the maximum duration, in days, of an interaction thread after all of the interactions that belong to the thread have terminated. After the timeout expires, Genesys Info Mart considers the thread to be closed.
populate-thread-facts
Section: gim-etl-populate
Default Value: false
Valid Values: true, false
Changes Take Effect: At the next run of Job_TransformGIM
Dependencies: None
Introduced: 8.5.001
Enables or disables the population of thread-related metrics in the ANCHOR_FLAGS dimension in multimedia deployments.
max-thread-duration-after-inactive-in-days
Section: gim-etl
Default Value: 31
Valid Values: Any positive integer greater than days-to-keep-active-facts
Changes Take Effect: On the next ETL cycle
Dependencies: populate-thread-facts=true
Introduced: 8.1.1
Specifies the maximum duration, in days, of an interaction thread after all of the interactions that belong to the thread have terminated. After the timeout expires, Genesys Info Mart considers the thread to be closed.
Populating Interaction Data
Genesys Info Mart stores both voice and non-voice interaction facts (IFs) in the INTERACTION_FACT table. This page describes how IFs are populated.
What do IFs represent?
Genesys Info Mart creates IFs to link together all facts related to a given interaction. IFs represent interactions from the perspective of the customer experience. For example, Genesys Info Mart represents every new inbound or outbound interaction as a new IF row; however, for multimedia interactions, an inbound interaction and an associated outbound reply are represented in the same IF.
Each interaction fact represents:
- The time span of the overall interaction
- Information that identifies the interaction parties
- Service indicators
Interaction facts can also be linked to the user data extension tables through keys.
For detailed information about the columns in the INTERACTION_FACT table, see the Genesys Info Mart Physical Data Model for your RDBMS.
How are IFs populated?
The grain of the fact is an accumulating snapshot that summarizes facts that are related to a given interaction.
- The TENANT dimension is inherited from the underlying IRF that has the lowest ordinal. This is the first resource fact that was created for the interaction, and it generally has the earliest start time. In a network routing solution, all underlying network and premise facts are considered. If premise facts exist, the TENANT dimension is the tenant of the first premise fact; otherwise, the TENANT dimension is the tenant of the first network fact.
- The INTERACTION_TYPE and MEDIA_TYPE dimensions are inherited from the underlying IRF that has the lowest ordinal. This is the first resource fact that was created for the interaction, and it generally has the earliest start time. In a network routing solution, all underlying network and premise facts are considered.
ImportantAny multimedia interaction subtype that you have configured in your environment but that is new to Genesys Info Mart is automatically added to the INTERACTION_TYPE table. Once it has been added, you can choose to have Genesys Info Mart disregard that subtype for all future transformation jobs by setting the appropriate value for the IGNORE field. By default, Genesys Info Mart transforms all interactions that have the newly added subtype.
New media types are also automatically added as Genesys Info Mart encounters them. By default, interactions that are associated with new media types are transformed as offline interactions. To set them as online interactions, enter the appropriate value in the IS_ONLINE field in the MEDIA_TYPE table.
For details, see the Multimedia Interactions page in the Genesys Info Mart Deployment Guide. - The MEDIA_SERVER_ROOT_IXN_ID acts as a thread ID for interactions that are a continuation of a thread. For more information, see Interaction Threads.
- As noted above, for multimedia interactions, an inbound interaction and an associated outbound reply are usually represented in the same IF. Starting with release 8.5.003, when a multimedia interaction that represents a reply is created after the parent interaction has already been terminated, the transformation job creates a new IF record with a new INTERACTION_ID value. In earlier releases, the transformation job might discard the child interactions during processing, resulting in the loss of metrics related to a late reply.
Interaction Threads
Each customer interaction is represented in Genesys Info Mart with a new IF, but it is possible that different customer interactions are associated with one another. For example, a new inbound interaction from a customer might be a reply to a previous agent reply to another inbound interaction from that customer. A collection of related interactions is referred to as a thread. Genesys Info Mart indicates this thread relationship by showing the root interaction in the IF record for a descendant interaction.
- The MEDIA_SERVER_ROOT_IXN_ID identifies the IF that is considered to be the root (original) interaction in the thread. Population of this field depends on Genesys Info Mart’s tracking of the thread, which is affected by the configured thread inactivity timeout (the max-thread-duration-after-inactive-in-days option). For an example, see the table below.
- MEDIA_SERVER_ROOT_IXN_GUID identifies the root interaction GUID, as reported by ICON as the ROOTIRID.
In addition, the IRF is populated with an ANCHOR_FLAGS_KEY that provides metrics about unique agent participation in an interaction or thread.
Tracking thread activity can negatively impact Genesys Info Mart performance and, starting with release 8.5.001, is optional. When populate-thread-facts=false, interactions that belong to the same thread continue to indicate the same root interaction (by having a common value for MEDIA_SERVER_ROOT_IXN_GUID in the IF table), but there is no additional processing to populate the IRF.ANCHOR_FLAGS_KEY with additional details about the agent's involvement in the thread, or to consistently populate IF.MEDIA_SERVER_ROOT_IXN_ID with the interaction ID of the root interaction (indicated by MEDIA_SERVER_ROOT_IXN_GUID).
The table below provides a sample e-mail scenario to indicate how, if populate-thread-facts=true, Genesys Info Mart tracks the thread relationships for three related IFs, which have the same root interaction GUID: Two of the related IFs are considered to belong to the same thread, but the third one, which occurs after the thread inactivity interval has expired, is considered to start a new thread.
Date | E-mail Interaction | Interaction and Thread IDs in IF |
---|---|---|
June 1 | InboundNew:
|
INTERACTION_ID: 161 MEDIA_SERVER_ROOT_IXN_ID: Null MEDIA_SERVER_ROOT_IXN_GUID: Null MEDIA_SERVER_IXN_GUID: ROOTIRID-1 |
June 2 | OutboundReply 1a from Agent1:a
| |
June 2 | OutboundReply 1b from Agent1:
| |
June 2 | InboundCustomerReply (to OutboundReply 1a):
|
INTERACTION_ID: 174 MEDIA_SERVER_ROOT_IXN_ID: 161 MEDIA_SERVER_ROOT_IXN_GUID: ROOTIRID-1 |
June 15 | OutboundReply 2a from Agent2:a
| |
Assuming no further activity on this thread and max-thread-duration-after-inactive-in-days=30, Genesys Info Mart closes the thread on July 16. | ||
July 20 | InboundCustomerReply (to OutboundReply 1b):
|
INTERACTION_ID: 249 MEDIA_SERVER_ROOT_IXN_ID: Null MEDIA_SERVER_ROOT_IXN_GUID: Null
|
July 21 | OutboundReply 3a from Agent1:a
| |
July 22 | OutboundReply 3b from Agent1:
| |
July 22 | InboundCustomerReply (to OutboundReply 2a):
|
INTERACTION_ID: 265 MEDIA_SERVER_ROOT_IXN_ID: 249 MEDIA_SERVER_ROOT_IXN_GUID: ROOTIRID-1 |
July 22 | OutboundReply 3c from Agent1:a
|
|
a. If this reply is the agent’s first participation in the interaction, in the reply, in the interaction thread, or in a reply in the interaction thread, the IRF for the agent includes an ANCHOR_KEYS value that indicates the applicable unique-participation metrics. |