Jump to: navigation, search

user-event-data-timeout

Section: gim-etl
Default Value: 3600
Valid Values: 0 or any positive integer
Changes Take Effect: On the next ETL cycle
Dependencies: None
Modified: 8.1.1 (behavior changed)

Specifies the maximum time, in seconds, after the end of a call, during which an agent who handled that call can send UserEvent-based key-value pair (KVP) data. If the call has ended and the UserEvent-based KVP data is sent after this timeout, the transformation job does not process the UserEvent-based KVP data.

populate-irf-asm-engage-duration

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.004

Enables or disables reporting on Active Switching Matrix (ASM) engage duration (for voice interactions only). Applies only to deployments with Outbound Contact in a VoIP environment where campaigns are running in an ASM dialing mode.

  • false—Genesys Info Mart does not differentiate between ASM engage duration and regular talk time.
  • true—Genesys Info Mart populates the ASM_COUNT and ASM_ENGAGE_DURATION columns in the INTERACTION_RESOURCE_FACT (IRF) table as follows:
    • ASM_COUNT is set to 1 to indicate that an attempt was made to engage an agent. If no attempt was made, then the column shows a value of 0.
    • ASM_ENGAGE_DURATION indicates the amount of time that a successfully-engaged agent waited to be connected to a customer. This duration will be excluded from regular talk time.

Active Switching Matrix

Also known as ASM. An active component of switching hubs that rapidly switch packets from port to port by allocating memory.



Glossary

A B C D E F G H I J K L M N O P Q R S T U V W X Y Z

Outbound Contact Server

Also known as OCS. The core component of the Outbound Contact Solution that provides automated dialing and call progress detection, so that an agent is required only when a customer is connected. OCS also intelligently uses customer data to ensure that campaigns are contacting the right customers, not just a large number of customers.



Glossary

A B C D E F G H I J K L M N O P Q R S T U V W X Y Z

Interaction Database

Also known as IDB. The database that stores data about contact-center interactions and resources at a granular level of detail.
See also Interaction Concentrator.



Glossary

A B C D E F G H I J K L M N O P Q R S T U V W X Y Z

Routing Point

Also known as an RP. Any point at which interactions wait for routing by Universal Routing Server (URS). These points have different names on different Private Branch Exchange (PBX) switches (for example, CCT, CDN, and VDN). Switches often have a script that is associated with them and that directs calls to a destination.



Glossary

A B C D E F G H I J K L M N O P Q R S T U V W X Y Z

Routing Point

Also known as an RP. Any point at which interactions wait for routing by Universal Routing Server (URS). These points have different names on different Private Branch Exchange (PBX) switches (for example, CCT, CDN, and VDN). Switches often have a script that is associated with them and that directs calls to a destination.



Glossary

A B C D E F G H I J K L M N O P Q R S T U V W X Y Z

Interaction Routing Designer

Also known as IRD. A Graphical User Interface (GUI) of Genesys Universal Routing that is used to design routing strategies. Routing strategies can route based on various criteria, such as business rules, information from a database lookup, a required skill set, interaction priority, the desired service level, interaction attributes, and statistical values.



Glossary

A B C D E F G H I J K L M N O P Q R S T U V W X Y Z

Universal Routing Server

Also known as URS. The server that is used by Universal Routing that automatically executes routing-strategy instructions and distributes incoming customer interactions among contact-center agents. Previously known as Interaction Router.



Glossary

A B C D E F G H I J K L M N O P Q R S T U V W X Y Z

default-ivr-to-self-service

Section: gim-transformation
Default Value: false
Valid Values: true, false
Changes Take Effect: At the next run of Job_TransformGIM
Dependencies: None

Specifies how Genesys Info Mart will treat IVRs when the IPurpose attached data KVP is not defined, or when it has an incorrect value.

  • false—The IVR is treated as a nonself-service IVR (in other words, as a mediation device).
  • true—The IVR is treated as a self-service IVR (in other words, as a handling resource).

user-event-data-timeout

Section: gim-etl
Default Value: 3600
Valid Values: 0 or any positive integer
Changes Take Effect: On the next ETL cycle
Dependencies: None
Modified: 8.1.1 (behavior changed)

Specifies the maximum time, in seconds, after the end of a call, during which an agent who handled that call can send UserEvent-based key-value pair (KVP) data. If the call has ended and the UserEvent-based KVP data is sent after this timeout, the transformation job does not process the UserEvent-based KVP data.

Interactive Voice Response

Also known as IVR. A hardware and software system that uses responses from a touch-tone telephone to gather and store data. It uses a recorded human voice to reply to user input. It is sometimes referred to as the Voice Response Unit (VRU).

IVR can also refer to systems that provide information in the form of recorded messages over telephone lines, in response to user-supplied input in the form of spoken words or, more commonly, Dual-Tone Multi Frequency (DTMF) signaling. Examples include banks that enable you to check your balance from any telephone, and automated stock-quote systems. For example, For checking account information, press 1 or If you want a stock quote, press 2.

A computer technology that enables users to connect to a computer system and obtain information through voice input, instead of by using a keypad, keyboard, or touch-tone telephone device. An IVR system responds to a human voice, looks up information, presents alternatives, and interacts with the caller.



Glossary

A B C D E F G H I J K L M N O P Q R S T U V W X Y Z

Interaction Database

Also known as IDB. The database that stores data about contact-center interactions and resources at a granular level of detail.
See also Interaction Concentrator.



Glossary

A B C D E F G H I J K L M N O P Q R S T U V W X Y Z

Key-Value Pair

Also known as a KVP. A data structure that is used to communicate or store a piece of information. A KVP consists of a key, whose value is a string, and a value, which may be any of a variety of data types, including a key-value set (thus, making the structure recursive). The key identifies the meaning of the data that is contained in the value.



Glossary

A B C D E F G H I J K L M N O P Q R S T U V W X Y Z

Key-Value Pair

Also known as a KVP. A data structure that is used to communicate or store a piece of information. A KVP consists of a key, whose value is a string, and a value, which may be any of a variety of data types, including a key-value set (thus, making the structure recursive). The key identifies the meaning of the data that is contained in the value.



Glossary

A B C D E F G H I J K L M N O P Q R S T U V W X Y Z

User Data Sources and KVPs

As described in Processing User Data, Genesys Info Mart obtains user-data KVPs from T-Server TEvents, Interaction Server events, or UserEvents. This page provides information you need to consider when you configure your deployment to send and store user data.

Source Attributes in Events

For call-based attached data, KVPs can be reported in the UserData, Reasons, or Extensions attributes of TEvents and Interaction Server events. The source that is specified in the ICON attached-data specification file controls which event attribute ICON will store (for example, source=”userdata”). The filterUserData startup parameter enables you to control whether Genesys Info Mart will extract KVPs from only the UserData attribute of TEvents and Interaction Server events (filterUserData=true, the default behavior) or whether it will also consider KVPs from the Reasons and Extensions attributes of TEvents (filterUserData=false).

Turning off filtering of user data has performance implications, because it increases the amount of user data that Genesys Info Mart will have to process.

For information about setting the filterUserData startup parameter, see Modifying JVM Startup Parameters.

Using UserEvent-Based KVP Data

Some agent desktop applications issue UserEvents to set KVP data after the agent’s participation in the voice interaction has completed (that is, after the call is released). Other components or applications, such as Genesys Mobile Services (GMS), also send data in UserEvents to enable integration with Genesys Info Mart for historical reporting on application usage or performance. You can configure an ICON application that captures Voice details to store UserEvent-based KVP data in its IDB. When you configure the ICON application, you use ICON application configuration options — instead of the attached-data specification XML file — to specify which KVPs ICON should store. Then you can configure Genesys Info Mart to extract this data from the IDB G_CUSTOM_DATA_S table.

Note the following about Genesys Info Mart processing of UserEvent-based KVP data:

  • This functionality is supported for user data in the Voice details data domain only. All UserEvent data that ICON receives from T-Server or SIP Server is supported, even if the user data relates to non-voice interactions — for example, callbacks originating from the web or mobile channel.
  • This functionality is supported for logged-in agents and IVR applications that emulate logged-in agents.
  • Data from only the G_CUSTOM_DATA_S table in IDB is extracted. UserEvent-based KVP data is not extracted from G_CUSTOM_DATA_P, nor are custom agent states extracted from the G_CUSTOM_STATES table in IDB.
  • Applications that issue UserEvents must be sure to set the fields inside the UserEvent properly. Unlike with call-based attached data, T-Server does not validate the contents of the UserEvents, nor does it propagate their KVP data values among related calls, such as consultations, transfers, or conferences.
  • Callback KVP data is available for reporting purposes if Genesys Callback is configured using the GMS component in your environment. For more information, see Genesys Mobile Services (GMS) — for Callback, below.

For directly call-related data, such as the after-call work (ACW) UserEvents sent by agent desktop applications, Genesys Info Mart stores the extracted UserEvent data in the same fact and dimension tables as the data that is sourced from call-based attached data. During deployment planning, you decide which Info Mart fact or dimension column should receive data from each UserEvent-based KVP that is of interest for reporting. During deployment configuration, you must configure ICON application options to specify which KVPs should be stored in G_CUSTOM_DATA_S. Also, you must configure Genesys Info Mart mapping between those KVPs and the Info Mart facts and dimensions (see User Data Mapping Tables).

Important
If you report on Outbound Contact details, you must configure ICON to store UserEvent-based KVP data for the GSW_CALL_ATTEMPT_GUID KVP.

For more information about how Genesys Info Mart populates its facts and dimensions from UserEvent-based KVP data and call-based attached data, see the section about populating Genesys Info Mart data in the Genesys Info Mart User’s Guide.

Application-Specific Considerations

The remainder of this page provides some guidelines about the KVPs that contact centers typically use for reporting purposes. KVPs are discussed by the Genesys application that attaches them:

IVR Applications

You must configure your IVR applications to send the IApplication KVP — and you must configure ICON to store it — even if you do not want to store the IApplication KVP in Info Mart user-data tables for your reporting purposes. Genesys Info Mart uses the IApplication KVP value internally during transformation.

Other KVPs that your IVR applications attach depend on the following factors:

  • The technologies that your IVR application supports
  • Whether the applications are self-service-oriented
  • Whether the applications work in conjunction with Enterprise Routing Solution

Based on these factors, you might choose to modify your IVR applications so that they attach additional KVPs:

[+] Show additional IVR KVPs

You might also decide to attach user-defined KVPs.

Important
If the IVR DNs act as agents by logging into a queue, IVR applications can associate KVP data with a voice interaction by sending UserEvents after the voice interaction has ended (that is, after the call is released). The UserEvent has to be sent within the timeout that is specified in the Genesys Info Mart application configuration (see user-event-data-timeout). IPurpose cannot be sent in UserEvents.

IPurpose KVP

Genesys Info Mart uses the IPurpose KVP to determine whether an IVR application represents a self-service application or only a part of the mediation process:

  • For a self-service IVR, Genesys Info Mart creates a separate row in the INTERACTION_RESOURCE_FACT (IRF) table, representing the IVR activity as interaction handling (not as mediation). In other words, the IRF table is populated with facts for this self-service IVR in the same manner as for an agent.
  • For a nonself-service IVR, no separate IRF row is created; the IVR activity is represented as mediation (not as interaction handling) as part of another row in the IRF table.

The presence of the IPurpose key with the value of 1 (Self Service) forces Genesys Info Mart to treat an IVR as a handling resource. Otherwise, Genesys Info Mart treats the IVR as a mediation resource.

Important
  • In an environment in which IVR applications rely on Universal Routing to select a target, you can modify your Universal Routing Server (URS) routing strategies to attach the IPurpose KVP on behalf of the self-service IVR application. For more information, see Routing and Attached Data for Self-Service IVRs.
  • If you do not modify your self-service IVR applications or routing strategies to attach the IPurpose KVP, you will see a high number of customer-abandoned interactions. To mitigate this, configure Genesys Info Mart to treat all IVR applications as self-service.

    Do this by setting the default-ivr-to-self-service configuration option to true in the [gim-transformation] section; in this way, you can configure Genesys Info Mart to treat all IVR resources as self-service IVRs.
  • If a self-service IVR uses a Two-Step or Mute transfer to transfer calls to an agent, configure the IVR application to set the value of the IPurpose key to 1 for consultation calls as well. Alternatively, set the T-Server option consult-user-data to inherited or joint, so that T-Server will propagate all user data, including the IPurpose KVP, from the original call to the consultation call.

In the following deployments, an IVR application can attach the IPurpose key with the value of 1 (Self Service) to indicate to the reporting system that the corresponding IVR is a self-service resource:

  • IVR In Front of the Switch — An IVR and IVR ports exist as configuration objects in the Configuration Database, and IVR ports are associated with DN objects that are configured under the IVR Server’s virtual switch.
  • IVR Behind the Switch — An IVR and IVR ports exist as configuration objects in the Configuration Database, and IVR ports are associated with DN objects that are configured under the premise switch.

When it arrives at your IVR port, the call is associated with a corresponding DN object in the Genesys environment. This association clearly indicates to Genesys Info Mart that the call is at an IVR.

The IVR application can set the IPurpose key to the Self Service value and attach this data to the original call while the call is at the IVR port. As a result, Genesys Info Mart creates a record in the IRF table to represent the self-service IVR application that is handling the customer interaction.

Universal Routing

The KVPs that Universal Routing attaches depend on:

  • The type of routing strategies that you deploy
  • Whether routing strategies work in conjunction with IVR applications

You can configure Universal Routing Server (URS) to attach the following strategy name and routing target KVPs automatically, by setting the URS report_targets configuration option to true:

  • RTenant
  • RStrategyName
  • RTargetTypeSelected
  • RTargetObjectSelected
  • RTargetAgentSelected
  • RTargetPlaceSelected
Important
By default, ICON stores values for these keys in the IDB G_ROUTE_RESULT table.

Your routing strategies can use the MultiAttach object and FindServiceObjective function in IRD to attach the following KVPs that represent requested skills, business attributes, and service objectives:

You might also decide to attach the following KVPs or user-defined KVPs:

  • CustomerID
  • CaseID
  • Revenue
  • Satisfaction
  • ServiceSubType

Notes about Skill Combinations

If you do not use the IRD MultiAttach object to define the requested skill combination, ensure that you represent the skill combination as a list of comma-separated skill names, each with an optional minimum proficiency. Wordspacing between the list items is not significant.

[+] Show examples

A skill combination is not the same as a skill expression. Logical operators and comparitors (such as <, >, |, and &) are not valid.

Routing and Attached Data for Self-Service IVRs

When used in conjunction with self-service IVR applications, your routing strategies might also attach the IPurpose KVP on behalf of the IVR application. (The IPurpose KVP that is attached by the IVR application takes priority.) The Self Service value (1) for the IPurpose key indicates to the reporting system that the corresponding IVR is a self-service resource in the following deployments:

  • IVR In Front of the Switch (as defined here) — In this deployment, a call also involves a routing point, which is configured as a DN of the Routing Point type under the IVR Server’s virtual switch.

    Either the IVR application or the routing strategy that is associated with the routing point (or both) can set the IPurpose key to the Self Service value. As a result, Genesys Info Mart creates a record in the IRF table to represent the self-service IVR.

  • IVR Behind the Switch (as defined here) — In this deployment, a call might involve a routing point, which is configured as a DN object of the Routing Point type under the premise switch. The IPurpose key with the Self Service value is set as follows, in any combination:
    • The routing strategy that is associated with the routing point at the premise switch attaches the KVP before the strategy routes the call to the IVR DN.
    • The IVR application attaches the KVP while the call is at the IVR port.
    As a result, Genesys Info Mart creates a record in the IRF table to represent the self-service IVR.

eServices/Multimedia-Specific Attached Data

Events from the eServices/Multimedia solution include a number of attributes that are specific to multimedia interactions.

If they are attached to an interaction, ICON stores these attributes in the GM_F_USERDATA and GM_L_USERDATA tables in IDB. By default, ICON stores the KVPs and event attributes that Genesys Info Mart requires, even if you do not explicitly specify them in the ICON attached-data specification file. Genesys Info Mart does not process custom KVPs that you configure ICON to store in the GM_F_USERDATA or GM_L_USERDATA tables.

The following table describes important multimedia-specific KVPs that Genesys Info Mart processes and that ICON stores by default.

Multimedia-Specific Interaction Attributes
Attribute Description
Subject The subject of the multimedia interaction.
FromAddress The “from” address of the multimedia interaction.
InteractionSubType The interaction subtype of the multimedia interaction.

This subtype is a component of the value for the INTERACTION_TYPE_KEY. The INTERACTION_TYPE dimension includes both interaction type and subtype.

StopReason eServices/Multimedia allows a reason name to be provided for each action. ICON records this reason name for the action that stops the interaction, identifying the reason the interaction was stopped. Genesys Info Mart uses this stop reason for internal purposes — for example, when setting the TECHNICAL_DESCRIPTOR_KEY in the IRF record.

For user data originating from EventCustomReporting events — for example, for Focus Time reporting — you must configure ICON to store the required attributes in the G_CUSTOM_DATA_S table in IDB, as described in Configuring UserEvent Data Storage. For full details about configuring ICON to support Focus Time reporting, see Processing Data from EventCustomReporting.

For information about detailed chat session reporting, see Chat Server, below.

Outbound Contact Solution

Outbound Contact Server (OCS) automatically attaches the GSW_CALL_ATTEMPT_GUID call attempt ID for progressive and predictive dialing modes. For preview dialing mode, OCS provides the GSW_CALL_ATTEMPT_GUID KVP in the UserEvent with record information.

You must ensure that your desktop application attaches the GSW_CALL_ATTEMPT_GUID KVP. Genesys Info Mart uses it for internal processing. Downstream reporting applications can also use it to integrate contact attempt details with call details.

In Outbound-VoIP environments, when Outbound Contact campaigns are running in an ASM (that is, Active Switching Matrix) dialing mode, OCS automatically attaches the GSW_CALL_TYPE=”ENGAGING” KVP to identify an engaging call. An ASM dialing mode engages an agent, establishes a connection with the customer, and then transfers the agent to the customer. That is, the agent waits to be connected to the customer. The time that the agent spends waiting to be connected to the customer is the engaged duration.

Starting with release 8.5.004, Genesys Info Mart processes the call as an engaging call when this KVP is present, and records the amount of time that the agent was engaged and waiting for the call to connect to a customer. The time that the agent was engaged and waiting is excluded from regular talk time.

To capture the engaged duration associated with an ASM dialing mode, you must set the populate-irf-asm-engage-duration configuration option to true.

Agent Desktop Applications

Agent desktop applications might attach various KVPs, depending on your configuration of business attributes in the Configuration Layer.

[+] Show sample KVPs

Tip
Agent desktop applications can associate KVP data with a voice interaction by sending UserEvents after the voice interaction has ended (that is, after the call is released). The UserEvent has to be sent within the timeout that is specified in the Genesys Info Mart application configuration (see user-event-data-timeout).

If you want to track the reasons for agents being in NotReady states, ensure that relevant KVPs are available to your agents through their desktop applications.

OCS automatically attaches the GSW_CALL_ATTEMPT_GUID call attempt ID for progressive and predictive dialing modes. For preview dialing mode, you must ensure that your desktop application attaches the GSW_CALL_ATTEMPT_GUID KVP to the actual interaction. The GSW_CALL_ATTEMPT_GUID KVP is provided by OCS in the UserEvent with record information. For voice interactions, the KVP must be attached before the voice call is released.

For eServices/Multimedia, ICON automatically stores information about the reason that processing of an interaction stopped. If you want to track the reasons for agents stopping multimedia interactions, ensure that the Stop Reason key with relevant values is available to your agents through their desktop applications. ICON also stores information about the party that issued the request to stop processing an interaction, when the party is known.

Genesys Mobile Services (GMS) — for Callback

Starting with release 8.5.005, Genesys Info Mart supports reporting on Genesys Callback activity, provided that GMS has been configured to send the required user data and that ICON (release 8.1.506.07 or higher) has been configured to store it. For full information about configuring Genesys Callback services, see the Callback Solution Guide.

Genesys Info Mart stores callback-related data in CALLBACK_* tables in the Info Mart database. The user-data mapping is predefined and cannot be customized. No additional configuration or mapping is required. For information about Genesys Info Mart callback-related tables, see the Genesys Info Mart Physical Data Model for your RDBMS. For information about how callbacks are represented in Info Mart interaction data, see Special handling for Genesys Callback in the User's Guide, on the page about populating interaction resource data.

At a minimum, Genesys Info Mart requires GMS to send the following KVPs in every callback-related event. Genesys Info Mart will not insert a row for a callback event in the CALLBACK_FACT table if any of the following KVPs are missing.

  • _CB_SERVICE_ID
  • _CB_T_SERVICE_START
  • _CB_D_CALLBACK_OFFER
  • _CB_N_CALLBACK_OFFERED
  • _CB_T_CALLBACK_OFFERED

For meaningful callback reporting, Genesys Info Mart requires GMS to send a number of additional KVPs, as applicable for the event. The following table, which is reproduced for your convenience from the Set up Historical Reporting page in the Callback Solution Guide, describes the KVPs that Genesys Info Mart requires GMS to send in UserEvents, to enable meaningful Callback reporting. An asterisk indicates that the KVP must be sent twice -- as call-based attached data in a TEvent and as UserEvent-based user data. Release numbers mentioned in the table (for example, indicating when a particular KVP was introduced) refer to the GMS release.

Important

To ensure that ICON stores the KVP data required for Genesys Info Mart to report on Callback, set the store-event-data option to all on the ICON application object (default is none).

Four of the KVPs — _CB_SERVICE_ID, _CB_T_SERVICE_START, _CB_T_CALLBACK_ACCEPTED and _CB_T_CUSTOMER_CONNECTED — must also be sent as call-based attached data. The sample attached-data specification file in the Genesys Info Mart IP includes these four KVPs by default.


KVP Description Info Mart Database Target
KVP Description Info Mart Database Target
VQ_CFG_TYPE
 The configuration type of the virtual queue used to find the target agent. Genesys Info Mart uses this value in combination to identify the RESOURCE_KEY to use. CALLBACK_FACT.RESOURCE_KEY
VQ_CFG_TYPE_ID
 The configuration type ID of the virtual queue used to find the target agent. Genesys Info Mart uses this value in combination to identify the RESOURCE_KEY to use. CALLBACK_FACT.RESOURCE_KEY
_CB_CUSTOMER_ANI

Introduced: 8.5.111.04		 ANI of the customer for in-queue scenarios. This value can match _CB_CUSTOMER_PHONE_NUMBER if the same number is confirmed or entered. Could also be empty if the ANI is not detected. CALLBACK_FACT.CUSTOMER_ANI
_CB_DIAL_1_RESULT

Introduced: 8.5.200.07		 The result of the first callback dialing attempt. One of the following values:
  • CREATE_CALL_ERROR
  • BUSY
  • NO_ANSWER
  • ANSWERING_MACHINE
  • ERROR_TONE
  • FAX
  • PERSON
  • CONNECTED
  • FAILED_TO_ESTABLISH_CUSTOMER_ORIGINATED_MEDIA
  • PUSH_DELIVERY_CONFIRMED
  • PUSH_SEND_ERROR
  • PUSH_DELIVERY_NOT_CONFIRMED
  • USERORIGINATED_CONNECTED

Notes: FAILED_TO_ESTABLISH_CUSTOMER_ORIGINATED_MEDIA is a result that must be reported by the user application; otherwise, there is no CTI data that will enable Genesys Callback to identify this result.

CALLBACK_DIAL_RESULTS.DIAL_1_RESULT (referenced through CALLBACK_FACT.CALLBACK_DIAL_RESULTS_KEY)
_CB_DIAL_2_RESULT

Introduced: 8.5.200.07		 The result of the second callback dialing attempt. See _CB_DIAL_1_RESULT for possible values. CALLBACK_DIAL_RESULTS.DIAL_2_RESULT (referenced through CALLBACK_FACT.CALLBACK_DIAL_RESULTS_KEY)
_CB_DIAL_3_RESULT

Introduced: 8.5.200.07		 The result of the third callback dialing attempt. See _CB_DIAL_1_RESULT for possible values. CALLBACK_DIAL_RESULTS.DIAL_3_RESULT (referenced through CALLBACK_FACT.CALLBACK_DIAL_RESULTS_KEY)
_CB_DIAL_4_RESULT

Introduced: 8.5.200.07		 The result of the fourth callback dialing attempt. See _CB_DIAL_1_RESULT for possible values. CALLBACK_DIAL_RESULTS.DIAL_4_RESULT (referenced through CALLBACK_FACT.CALLBACK_DIAL_RESULTS_KEY)
_CB_DIAL_5_RESULT

Introduced: 8.5.200.07		 The result of the fifth callback dialing attempt. See _CB_DIAL_1_RESULT for possible values. CALLBACK_DIAL_RESULTS.DIAL_5_RESULT (referenced through CALLBACK_FACT.CALLBACK_DIAL_RESULTS_KEY)
_CB_DIM_CALLBACK_OFFER_TYPE
 The type of callback offer that was presented to the customer. For example, after business hours, SCHEDULED is the only available option; during business hours, business rules might allow only the WAIT_FOR_AGENT option or a combination of SCHEDULED and WAIT_FOR_AGENT. One of the following values:
  • SCHEDULED
  • WAIT_FOR_AGENT
  • COMBINED_SCHEDULED_AND_WAIT_FOR_AGENT
  • IMMEDIATE
 CALLBACK_DIM_1.CALLBACK_OFFER_TYPE (referenced through CALLBACK_FACT.CALLBACK_DIM_1_KEY)
_CB_DIM_CALL_DIRECTION
 The direction of the final callback interaction. One of the following values:
  • CUSTOMER_TERMINATED - Outbound Callback scenarios in which the contact center is dialing out to the customer's number.
  • CUSTOMER_ORIGINATED - Inbound Callback scenarios in which the contact center notifies the customer-facing application that it is time for the callback interaction, after which the application creates the interaction (such as a call or chat), obtaining the phone number if necessary. In this scenario, a customer call comes into the contact center as a regular inbound call, but it is recognized as the callback interaction.
 CALLBACK_DIM_2.CALL_DIRECTION (referenced through CALLBACK_FACT.CALLBACK_DIM_2_KEY)
_CB_DIM_CHANNEL
 The interaction channel from which the callback originated. One of the following values:
  • IVR
  • WEB
  • MOBILE
 CALLBACK_DIM_1.CHANNEL (referenced through CALLBACK_FACT.CALLBACK_DIM_1_KEY)
_CB_DIM_CONNECT_ORDER
 The order in which the final callback interaction was connected. One of the following values:
  • CUSTOMER_FIRST
  • AGENT_FIRST_PREVIEW
  • AGENT_FIRST_NO_PREVIEW
 CALLBACK_DIM_1.CONNECT_ORDER (referenced through CALLBACK_FACT.CALLBACK_DIM_1_KEY)
_CB_DIM_DIAL_DIALOG_RESULT
 The result of the final dialog for the callback. One of the following values:
  • RIGHT_PERSON
  • RESCHEDULED
  • CANCELLED
  • TRANSFERRED_TO_RP
  • PERSON
  • CANCEL
  • ERROR_TONE

Important: If an error occurs during the callback outbound call, the value of _CB_DIM_FINAL_DIAL_RESULT might overlap with _CB_DIM_DIAL_DIALOG_RESULT.

CALLBACK_DIM_2.DIAL_DIALOG_RESULT (referenced through CALLBACK_FACT.CALLBACK_DIM_2_KEY)
_CB_DIM_FINAL_DIAL_RESULT
 The result of the final callback dialing attempt. One of the following values:
  • CREATE_CALL_ERROR
  • BUSY
  • NO_ANSWER
  • ANSWERING_MACHINE
  • ERROR_TONE
  • FAX
  • PERSON
  • CANCEL
  • CONNECTED
  • FAILED_TO_ESTABLISH_CUSTOMER_ORIGINATED_MEDIA
  • PUSH_DELIVERY_CONFIRMED
  • PUSH_SEND_ERROR
  • PUSH_DELIVERY_NOT_CONFIRMED
  • USERORIGINATED_CONNECTED
  • REDIAL_LIMIT_REACHED
  • ABANDONED_IN_QUEUE
  • FAIL
  • UNKNOWN
  • RESCHEDULED
  • FAIL_FAX_REACHED

Notes:
1. FAILED_TO_ESTABLISH_CUSTOMER_ORIGINATED_MEDIA is a result that must be reported by the user application; otherwise, there is no CTI data that will enable Genesys Callback to identify this result.

2. CANCEL is set when the on_dial plugin returned action=CANCEL.

CALLBACK_DIM_2.FINAL_DIAL_RESULT (referenced through CALLBACK_FACT.CALLBACK_DIM_2_KEY)
_CB_DIM_FINAL_TARGET
 The routing target that was used to find the agent. CALLBACK_DIM_3.FINAL_TARGET (referenced through CALLBACK_FACT.CALLBACK_DIM_3_KEY)
_CB_DIM_OFFER_TIMING
 Specifies whether the callback offer was made during operational (business) or non-operational hours. One of the following values:
  • ON-HOURS
  • OFF-HOURS
 CALLBACK_DIM_2.OFFER_TIMING (referenced through CALLBACK_FACT.CALLBACK_DIM_2_KEY)
_CB_DIM_TYPE
 The type of callback the customer requested. One of the following values:
  • IMMEDIATE - The interaction is created right away while the customer is waiting for the agent (in an online chat session or waiting for a voice call).
  • WAIT_FOR_AGENT - The interaction is delayed until the agent is about to become available or actually becomes available (as in an agent first scenario).
  • SCHEDULED - The time for the callback interaction is negotiated with the customer.
 CALLBACK_DIM_1.CALLBACK_TYPE (referenced through CALLBACK_FACT.CALLBACK_DIM_1_KEY)
_CB_DIM_VQ
 The virtual queue used to find the target agent. Genesys Info Mart uses this value in combination to identify the RESOURCE_KEY to use. CALLBACK_FACT.RESOURCE_KEY
_CB_DIM_VQ_DBID
 The DBID of the virtual queue used to find the target agent. Genesys Info Mart uses this value in combination to identify the RESOURCE_KEY to use. CALLBACK_FACT.RESOURCE_KEY
_CB_DISPOSITION
 Callback state using the format <state>.<sub state> where:
  • <state> can be set to: SCHEDULED, QUEUED, ROUTING, PROCESSING, COMPLETED.
  • <sub state> can be set: REDIAL_LIMIT_REACHED, CANCELLED, AGENT, ABANDONED_IN_QUEUE, REJECTED, PUSH_SEND, PUSH_DELIVERY_CONFIRMED, PUSH_SEND_ERROR, FAILED, CONNECTED, TRANSFERRED_TO_RP.
 CALLBACK_DIM_3.DISPOSITION (referenced through CALLBACK_FACT.CALLBACK_DIM_3_KEY)
_CB_D_CALLBACK_OFFER
 The duration of the callback offer, in seconds.

Note: This KVP is mandatory for Genesys Info Mart reporting.		 CALLBACK_FACT.CALLBACK_OFFER_TIME
_CB_D_CUSTOMER_CONNECTED_WAITING_FOR_AGENT
 The amount of time, in seconds, the customer was waiting to be connected to the agent after the callback interaction was established. CALLBACK_FACT.CONN_WAITING_AGENT_TIME
_CB_D_CUSTOMER_WAITED_BEFORE_OFFER

Introduced: 8.5.106.14		 The amount of time, in seconds, the customer waited in the queue before a callback was offered. CALLBACK_FACT.WAITED_BEFORE_OFFER_TIME
_CB_D_ESTABLISH_MEDIA_IXN
 The amount of time, in seconds, it took to establish the callback interaction, such as an outbound call. CALLBACK_FACT.ESTABLISH_MEDIA_IXN_TIME
_CB_D_WAITING_FOR_AGENT_OFFLINE
 The amount of time, in seconds, the customer was waiting offline for an agent to become available. CALLBACK_FACT.WAIT_AGENT_OFFLINE_TIME
_CB_EWT_THRESHOLD_WHEN_OFFERED

Introduced: 8.5.200.07		 Value of the EWT threshold used to decide whether the callback offer should be made or not. Pass this value as an argument of the application that is responsible for making the callback offer. CALLBACK_FACT.EWT_THRESHOLD_WHEN_OFFERED
_CB_EWT_WHEN_CALLBACK_WAS_OFFERED
 The value of EWT, in seconds, at the time the callback was offered. CALLBACK_FACT.EWT_WHEN_OFFERED
_CB_EWT_WHEN_READY_TO_START_LAST_MEDIA_IXN

Introduced: 8.5.200.07		 Estimated Wait Time in seconds when the last dial attempt was made or the last push notification sent. CALLBACK_FACT.EWT_WHEN_LAST_DIAL
_CB_EWT_WHEN_READY_TO_START_MEDIA_IXN
 The value of Expected Wait Time (EWT), in seconds, for the service request when the contact center was ready to start the first callback interaction, such as an outbound dialing attempt. CALLBACK_FACT.EWT_READY_TO_START_IXN
_CB_FINAL_RECORD
 Indicates whether this is a final record about this callback service: 0 = No, 1 = Yes. CALLBACK_FACT.FINAL_RECORD
_CB_FIRST_OUT_IXN_ID

Introduced: 8.5.200.07		 The call ID of the first outbound call that the callback service created. CALLBACK_FACT.FIRST_OUT_IXN_ID
_CB_IXN_START_IGNORING_AVAILABILITY

Introduced: 8.5.200.07		 For premise callback, _CB_IXN_START_IGNORING_AVAILABILITY will always be 0. CALLBACK_DIM_4.DIAL_IGNORING_AVAILABILITY
_CB_LAST_OUT_IXN_ID

Introduced: 8.5.200.07		 The call ID of the last outbound call that the callback service created. CALLBACK_FACT.LAST_OUT_IXN_ID
_CB_N_ABANDONED_DURING_CALLBACK_OFFER

Introduced: 8.5.111.04		 Indicates whether the caller dropped the call without explicitly accepting or rejecting the callback offer: 0 = No, 1 = Yes. CALLBACK_DIM_4.ABANDONED_DURING_CB_OFFER (referenced through CALLBACK_FACT.CALLBACK_DIM_4_KEY)
_CB_N_AGENT_ADDED_TO_IXN
 Indicates whether the agent was successfully added to the callback interaction: 0 = No, 1 = Yes. CALLBACK_FACT.AGENT_ADDED_TO_IXN
_CB_N_CALLBACK_ACCEPTED
 Indicates whether a callback offer was accepted: 0 = No, 1 = Yes. CALLBACK_FACT.CALLBACK_ACCEPTED
_CB_N_CALLBACK_MEDIA_ATTEMPTS
 The total number of callback attempts or notifications, both successful and unsuccessful. CALLBACK_FACT.CALLBACK_ATTEMPTS
_CB_N_CALLBACK_OFFERED
 Indicates whether callback was offered, at least once, during the session: 0 = No, 1 = Yes.

Note: This KVP is mandatory for Genesys Info Mart reporting.		 CALLBACK_FACT.CALLBACK_OFFERED
_CB_N_CUSTOMER_ABANDONED_WHILE_WAITING_FOR_AGENT
 Indicates whether the customer abandoned the callback interaction while waiting to be connected to an agent: 0 = No, 1 = Yes. CALLBACK_FACT.ABANDONED_WAITING
_CB_N_IXN_REQ_AGENT
 Indicates whether the interaction required agent assistance: 0 = No, 1 = Yes. CALLBACK_FACT.IXN_REQ_AGENT
_CB_N_TIMEOUT_WHILE_WAITING_FOR_AGENT
 Indicates whether the customer was disconnected because the timeout for waiting for an agent was reached: 0 = No, 1 = Yes. CALLBACK_FACT.TIMEOUT_WAITING
_CB_N_TRANSFER_TO_AGENT_FAILED
 Number of times the callback interaction failed to transfer to the agent. CALLBACK_FACT.XFER_TO_AGENT_FAILED
_CB_OFFER_EWT_INBOUND_VQ

Introduced: 8.5.111.04		 Estimated Wait Time for the queue where rejected calls and not offered callbacks are being placed. This value is identical to _CB_EWT_WHEN_CALLBACK_WAS_OFFERED if the same Virtual Queue is used to place accepted callbacks. CALLBACK_FACT.EWT_WHEN_REJECTED
_CB_ORIGINATION_IXN_ID

Introduced: 8.5.200.07		 The ID of the inbound call where the callback was originally offered and accepted. You must pass the _cb_origination_ixn_id parameter in your Start Callback query when creating a callback request. If you do not pass the _cb_origination_ixn_id parameter, the value of _CB_ORIGINATION_IXN_ID will be undefined. For chat scenarios, this ID should be the chat interaction ID. CALLBACK_FACT.ORIGINATION_IXN_ID
_CB_ORS_SESSION_ID

Introduced: 8.5.114.09		 The Orchestration Server (ORS) session ID used to manage the callback. If multiple sessions were used (for example, because an ORS session terminated unexpectedly during the callback), the last session ID is reported. CALLBACK_FACT.ORS_SESSION_ID
_CB_POS_WHEN_CALLBACK_WAS_OFFERED
 The customer position in the queue when callback was offered. CALLBACK_FACT.POS_WHEN_OFFERED
_CB_POS_WHEN_READY_TO_START_LAST_MEDIA_IXN

Introduced: 8.5.200.07		 Position in queue when the last dial attempt was made or the last push notification sent. CALLBACK_FACT.POS_WHEN_LAST_DIAL
_CB_POS_WHEN_READY_TO_START_MEDIA_IXN
 The customer position in the queue when the contact center was ready to start the first callback interaction, such as an outbound dialing attempt. CALLBACK_FACT.POS_READY_TO_START_IXN
_CB_PRIORITY_AT_THE_END_OF_ONLINE_WAIT

Introduced: 8.5.200.07		 Priority of the virtual interaction when the customer was connected to the agent.

If the customer abandoned while waiting in queue, then this value is the priority of the call when the customer disconnected.

CALLBACK_FACT.PRIORITY_WHEN_A_CONNECTED
_CB_PRIORITY_WHEN_CALLBACK_ACCEPTED

Introduced: 8.5.200.07		 Priority of the interaction (real or virtual) when the callback offer was accepted. CALLBACK_FACT.PRIORITY_WHEN_CB_ACCEPTED
_CB_PRIORITY_WHEN_CUSTOMER_CONNECTED

Introduced: 8.5.200.07		 Priority of the virtual interaction when the customer was connected. CALLBACK_FACT.PRIORITY_WHEN_C_CONNECTED
_CB_SERVICE_ID*
 The ID of the callback service request. Depending on the scenario, the value equals the ID of the GMS service instance or ID of the ORS session.

Note: This KVP is mandatory for Genesys Info Mart reporting.		 CALLBACK_FACT.SERVICE_ID
_CB_TENANT_DBID
 The Tenant DBID. CALLBACK_FACT.TENANT_KEY
_CB_T_CALLBACK_ACCEPTED*
 The UTC timestamp when the callback offer was accepted. CALLBACK_FACT.CALLBACK_ACCEPTED_TS
_CB_T_CALLBACK_OFFERED
 The UTC timestamp when the callback was offered.

Note: This KVP is mandatory for Genesys Info Mart reporting.		 CALLBACK_FACT.CALLBACK_OFFERED_TS
_CB_T_CUSTOMER_CONNECTED*
 The UTC timestamp when the customer was reconnected to the contact center and started waiting for an agent to be connected. CALLBACK_FACT.CUSTOMER_CONNECTED_TS
_CB_T_DIAL_1

Introduced: 8.5.200.07		 UTC Timestamp of the first dialing attempt. CALLBACK_FACT.DIAL_1_TS
_CB_T_DIAL_2

Introduced: 8.5.200.07		 UTC Timestamp of the second dialing attempt. CALLBACK_FACT.DIAL_2_TS
_CB_T_DIAL_3

Introduced: 8.5.200.07		 UTC Timestamp of the third dialing attempt. CALLBACK_FACT.DIAL_3_TS
_CB_T_DIAL_4

Introduced: 8.5.200.07		 UTC Timestamp of the fourth dialing attempt. CALLBACK_FACT.DIAL_4_TS
_CB_T_DIAL_5

Introduced: 8.5.200.07		 UTC Timestamp of the fifth dialing attempt. CALLBACK_FACT.DIAL_5_TS
_CB_T_READY_TO_START_MEDIA_IXN
 The UTC timestamp when the contact center was ready to start the callback interaction. The value matches the time of either an outbound dialing attempt or a push notification prompting the customer to start a call or chat session.

Note: Set this value only once, before the first dial attempt.

CALLBACK_FACT.READY_START_MEDIA_IXN_TS
_CB_T_SERVICE_END

Introduced: 8.5.111.04		 UTC timestamp for when service was completed or terminated. CALLBACK_FACT.SERVICE_END_TS
_CB_T_SERVICE_START*
 The UTC timestamp when the callback service started. This value represents either the time of the callback request or the time that the callback offer was played, depending on deployment.

Note: This KVP is mandatory for Genesys Info Mart reporting.		 CALLBACK_FACT.SERVICE_START_TS, CALLBACK_FACT.START_DATE_TIME_KEY



Genesys Predictive Routing (GPR)

Starting with release 8.5.009, Genesys Info Mart supports reporting on GPR usage and performance, provided that GPR has been configured to send the required user data and that ICON has been configured to store it. For full information about configuring GPR for historical reporting, see Deploying: Integrating with Genesys Reporting in the Genesys Predictive Routing (formerly Predictive Matching) Deployment and Operations Guide.

Genesys Info Mart stores GPR-related data in GPM_* tables in the Info Mart database. The user-data mapping is predefined and cannot be customized. No additional configuration or mapping is required. For more information about the GPR-related tables, see the Genesys Info Mart Physical Data Model for your RDBMS.

The following table describes the KVPs that Genesys Info Mart requires GPR to send in UserEvents. The information is reproduced for your convenience from the Integrating with Genesys Reporting page cited above. Release numbers mentioned in the table (for example, indicating when a particular KVP was introduced) refer to the GPR release. The gpm and GPM_ prefixes shown in the table are correct.


KVP Description KVP Type Info Mart Database Target
KVP Description KVP Type Info Mart Database Target
ADDED_TS
 UTC timestamp, indicating the date and time when the record was added as inherited from the T-Server TEvent.
Default value: no default value
Valid values: any valid UTC timestamp

Note: This KVP is mandatory for Genesys Info Mart reporting.		 INT GPM_FACT.ADDED_TS
CALLID
 Value of AttributeCallUUID for the interaction.
Default value: a valid CALLID

Note: This KVP is mandatory for Genesys Info Mart reporting.		 CHAR(32) GPM_FACT.MEDIA_SERVER_IXN_GUID
CustomerID

Introduced: 9.0.016.00		 The GPRIxnCleanup subroutine takes this KVP from user data attached to the interaction, and passes it to the Genesys Historical Reporting solution in the EventUserEvent event. GPR does not generate this KVP. Postgres: varchar(255); Oracle: VARCHAR2(255 CHAR); Microsoft SQL: varchar(255)/nvarchar(255) IRF_USER_DATA_GEN_1.CUSTOMER_ID
gpmAdjustedAgentScore

Introduced: 9.0.015.00		 The final agent score used to route the associated interaction to the selected agent. This score is calculated from the gpmAgentScore combined with any agent occupancy factor.
Default value: 0
Valid values: any non-negative float value		 FLOAT GPM_FACT.ADJUSTED_SCORE
gpmAgentDBID
 Optional. The DBID of the agent to whom the interaction was routed.
Default value: no default value		 INT RESOURCE_.RESOURCE_CFG_DBID (referenced through GPM_FACT.RESOURCE_KEY)
gpmAgentRank
 The rank of the agents in the target group, based on agent scores sorted in descending order.
Default value: 0
Valid values: 0, any positive integer		 SHORT GPM_FACT.AGENT_RANK
gpmAgentScore
 The score of the agent to whom the interaction was routed.
Default value: 0
Valid values: any non-negative float value		 FLOAT GPM_FACT.AGENT_SCORE
gpmCustomerFound
 Indicates whether features from the customer record specified in the routing strategy were successfully retrieved from the Customer Profile schema uploaded to the AI Core Services and used to calculate agent scores.
Default value: unknown
Valid values: 0 (= No), 1 (= Yes), unknown		 Enum GPM_RESULT.CUSTOMER_FOUND (referenced through GPM_FACT.GPM_RESULT_KEY)
gpmDefaultAgentScore

Introduced: 9.0.015.00		 This default agent score for the associated interaction. The value is the outcome, for this interaction, of the setting specified in the default-agent-score configuration option.
Default value: 0
Valid values: any non-negative float value		 FLOAT GPM_FACT.DEFAULT_SCORE
gpmDefaultScoredAgents

Introduced: 9.0.015.00		 The number of agents assigned the default score for the associated interaction.
Default value: 0
Valid values: 0, any positive integer		 INT GPM_FACT.DEFAULT_SCORES_COUNT
gpmDefaultScoreUsed

Introduced: 9.0.015.00
  • 0 - The agent score for the associated interaction is taken from the scoring response returned by GPR.
  • 1 - The agent score for the associated interaction is calculated based on the value set for the default-agent-score configuration option.

Default value: 0
Valid values: 0, 1		 INT GPM_FACT.DEFAULT_SCORE_USED
gpmFinalScoreThreshold

Introduced: 9.0.015.00		 The final threshold value used to route the associated interaction to the selected agent. The routing strategy calculates the value from the configured score threshold combined with values resulting from any agent holdout options.
Default value: 0
Valid values: any integer		 INT GPM_FACT.FINAL_SCORE_THRESHOLD
gpmGlobalScore
 The mean score calculated for an interaction using the Global Model.
Default value: 0
Valid values: any non-negative float value		 FLOAT GPM_FACT.GLOBAL_SCORE
gpmGlobalScoreCount

Introduced: 9.0.015.00		 Describes the number of agent scores returned for an interaction using a GLOBAL model.
Default value: 0
Valid values: 0, any positive integer		 INT GPM_FACT.GLOBAL_SCORES_COUNT
gpmInitialScoreThreshold

Introduced: 9.0.015.00		 The initial threshold value used for the interaction, taken from the value set in the score-base-threshold configuration option.
Default value: 0
Valid values: any integer		 INT GPM_FACT.INITIAL_SCORE_THRESHOLD
gpmMaxScore
 The score of the best-matching agent in the target group.
Default value: 0
Valid values: any non-negative float value		 FLOAT GPM_FACT.MAX_SCORE
gpmMedianScore
 The median score for the target group of agents to which the agent who received the interaction belongs.
Default value: 0
Valid values: any non-negative float value		 FLOAT GPM_FACT.MEDIAN_SCORE
gpmMessage
 The message that displays when the Predictive Routing result reported in the gpmResult KVP is an error.
Default value: no default value		 CHAR(255) GPM_FACT.MESSAGE
gpmMinScore
 The score of the worst-matching agent in the target group.
Default value: 0
Valid values: any non-negative float value		 FLOAT GPM_FACT.MIN_SCORE
gpmMode

Modified: 9.0.015.00 - The value off was added.		 The mode in which Predictive Routing is operating, as specified by the prr-mode configuration option. For information about turning predictive routing off, see Turn Off Predictive Routing.
Default value: unknown
Valid values: prod, off, dry-run, ab-test-time-sliced, unknown		 Enum GPM_RESULT.GPM_MODE (referenced through GPM_FACT.GPM_RESULT_KEY)
gpmModel
 The name of the Model used to calculate agent scores for the interaction.
Default value: unknown
Valid values: the name of any Model in your environment		 CHAR(255) GPM_MODEL.MODEL (referenced through GPM_FACT.GPM_MODEL_KEY)
gpmModelId
 The UUID of the Model used to calculate agent scores for the interaction.
Default value: unknown
Valid values: the ID for any Model in your environment		 CHAR(24) GPM_MODEL.MODEL_ID (referenced through GPM_FACT.GPM_MODEL_KEY)
gpmPredictor
 The name of the Predictor in the AI Core Services (AICS). If an error is encountered, the section name specified in the Predictive_Route_DataCfg Transaction List object is used as the Predictor name.
Default value: unknown
Valid values: the name of any Predictor in your environment		 CHAR(255) GPM_PREDICTOR.PREDICTOR (referenced through GPM_FACT.GPM_PREDICTOR_KEY)
gpmPredictorId
 The UUID of the Predictor used for scoring.
Default value: unknown
Valid values: the ID for any Predictor in your environment		 CHAR(24) GPM_PREDICTOR.PREDICTOR_ID (referenced through GPM_FACT.GPM_PREDICTOR_KEY)
gpmPredictorType

Introduced: 9.0.015.00		 Reserved for future use.
Default value: unknown
Valid values: Sales, Service		 CHAR[32] GPM_DIM1.PREDICTOR_TYPE
gpmPriorityIncrement

Introduced: 9.0.016.00		 If the value is 0, the priority of the interaction did not increase above the configured base_priority value. If the value is 1, the priority of the interaction did increase above the configured base_priority and, as a result, the selected agent was not verified for the expected threshold score.

Note: This KVP is not currently stored as a separate column in the Genesys Info Mart database. It can be accessed from the score_log file using the GPR API.


Default value: 0
Valid values: 0,1		 N/A N/A
gpmResult

Modified: 9.0.015.00 - The values 12, 13, 14, and 15 were added.		 The result of Predictive Routing processing. If there is an error, the gpmMessage KVP contains the error message.
  • 1 - Ok
  • 2 - Authentication to scoring engine failed
  • 3 - Scoring request failed
  • 4 - Agent list is empty
  • 5 - URS overload, interaction skipped
  • 6 - Predictor not found
  • 7 - Failed to build scoring request
  • 8 - SetIdealAgent or SetReadyCondition execution error
  • 9 - Interaction log not found in global map
  • 10 - Unknown error
  • 11 - Channel is not supported
  • 12 - Reserved for future use
  • 13 - Call Abandoned
  • 14 - Call Routing Failed
  • 15 - Predictive Routing is turned off or not used for this interaction

Default value: no default value
Valid values: 1–15

Note: This KVP is mandatory for Genesys Info Mart reporting.		 Enum GPM_RESULT.GPM_RESULT (referenced through GPM_FACT.GPM_RESULT_KEY)
gpmRouteAttemptId
 The sequence number of the attempt to route an interaction using Predictive Routing. The value of this KVP is incremented each time the ActivatePredictiveRouting subroutine is called by the strategy, starting from 1.
Default value: 0
Valid values: integers starting from 1		 INT GPM_FACT.ROUTE_ATTEMPT_ID
gpmRoutingMethod

Introduced: 9.0.015.00		 Reserved for future use.
Default value: unknown		 CHAR[32] GPM_DIM1.ROUTING_CRITERIA
gpmScoreAboveMedian
 Indicates whether the score for the selected agent was better than the median score for the target group.
Default value: unknown
Valid values: 0 (no), 1 (yes), unknown		 Enum GPM_FACT.SCORE_ABOVE_MEDIAN
gpmStatus
 Indicates the scenario under which the interaction was processed. For more information about the scenarios, see Routing Scenarios Using Predictive Routing.
Default value: unknown
Valid values: agent-surplus, call-surplus, unknown		 Enum GPM_RESULT.GPM_STATUS (referenced through GPM_FACT.GPM_RESULT_KEY)
gpmSuitableAgentsCount

Introduced: 9.0.015.00		 The number of agents who had scores greater than or equal to the initial threshold value when the scoring response was received.
Default value: 0
Valid values: 0, any positive integer		 INT GPM_FACT.SUITABLE_AGENTS_COUNT
gpmTargetSize
 The size of the scored target group (in other words, the length of the list of agents received from the scoring engine).
Default value: 0
Valid values: 0, any positive integer		 SHORT GPM_FACT.TARGET_SIZE
gpmUse
 The meaning depends on the mode in which Predictive Routing is operating (see the description of the gpmMode KVP). This field is set to one of the following values:
  • 1 - When the mode is ab-test-time-sliced, indicates that the interaction was selected for Predictive Routing. When the mode is prod, indicates the normal case, when Predictive Routing occurred without error.
  • 0 - When the mode is ab-test-time-sliced, indicates the interaction was processed with skill-based routing. When the mode is dry-run, indicates that the interaction completed without error.
  • unknown - For any mode, indicates that an error occurred in one of the Predictive Routing subroutines, and the solution defaulted to skill-based routing.

Default value: unknown
Valid values: 1, 0, unknown		 Enum GPM_RESULT.GPM_USE (referenced through GPM_FACT.GPM_RESULT_KEY)
gpmVQDBID

Introduced: 9.0.016.00		 The DBID of the virtual queue or DN configured in the vq-for-reporting configuration option (configured on the Predictive_Route_DataCfgTransaction List object).
  • Requires Genesys Info Mart release 8.5.014.19 or higher.
  • This KVP is sent only to Genesys Info Mart. It does not appear in the score_log file.

Default value: No default value
Valid values: Any valid DBID		 INT RESOURCE_.RESOURCE_CFG_DBID (referenced through GPM_FACT.VQ_RESOURCE_KEY)
gpmVQGUID

Introduced: 9.0.016.00		 Value of the Virtual Queue ID (RPVQID) stored in the interaction user data. This is a special GUID value that uniquely identifies the entrance of the interaction into certain virtual queues. The RPVQID is created by URS when the interaction enters into the virtual queue and is present in all VirtualQueue events that URS distributes.
  • Requires Genesys Info Mart release 8.5.014.19 or higher.
  • This KVP is sent only to Genesys Info Mart. It does not appear in the score_log file.

Default value: No default value
Valid values: Any valid Virtual Queue GUID		 CHAR[32] GPM_FACT.VQ_GUID
gpmWaitTime
 The amount of time, in seconds, the interaction spent in the queue used for Predictive Routing decision-making, starting from when the strategy started to process the interaction until it was routed to the agent. Note that the point when processing starts might depend on how you have configured your strategy.
Default value: 0
Valid values: 0, any positive integer		 INT GPM_FACT.WAIT_TIME
ServiceType

Introduced: 9.0.016.00		 The GPRIxnCleanup subroutine takes this KVP from user data attached to the interaction, and passes it to the Genesys Historical Reporting solution in the EventUserEvent event. GPR does not generate this KVP. Oracle: VARCHAR2(255 CHAR); Postgres: varchar(255); Microsoft SQL: nvarchar(170) INTERACTION_DESCRIPTOR.SERVICE_TYPE
START_TS
 UTC timestamp, indicating the time when the interaction arrived at the contact center.

Note that this value is different from gpm-ixn-timestamp (previously called prr-ixn-timestamp), which, in release 9.0.014.04 and earlier, indicates the time when the strategy started processing the interaction. gpm-ixn-timestamp is configured in the default_skill_data object, from which it is passed to the ActivatePredictiveRouting_v3 subroutine.

In URS Strategy Subroutines 9.0.015.00 and higher, gpm-ixn-timestamp is not used, and START_TS must be passed in the default_skill_data parameter. gpmWaitTime (the actual wait time of the interaction in the queue before an agent is selected) is calculated based on the difference between the UTC time when agent is selected minus the START_TS value.


Default value: no default value
Valid values: a valid UTC timestamp

Note: This KVP is mandatory for Genesys Info Mart reporting.		 INT GPM_FACT.START_DATE_TIME_KEY



Chat Server

Starting with release 8.5.011, in eServices deployments that include Chat Server 8.5.203.09 or higher, Genesys Info Mart supports detailed reporting on Genesys Chat session activity, provided that Chat Server has been configured to send the required user data and that ICON has been configured to store it. Starting with release 8.5.011.14, in eServices deployments that include Chat Server 8.5.302.03 or higher, Genesys Info Mart support for chat session reporting has been extended to include support for asynchronous (async) chat sessions. For full information about enabling chat session reporting for both regular and async chat, see Integrating Chat Server with Genesys Historical Reporting in the eServices Administrator's Guide. For additional links to more information, including information about aggregation and available out-of-box Genesys CX Insights reports, see New in Release 8.5.011 and New in Release 8.5.011.14 in this document.

Genesys Info Mart stores chat session data in the CHAT_SESSION_FACT and CHAT_SESSION_DIM tables in the Info Mart database. The user-data mapping is predefined and cannot be customized. No additional configuration or mapping is required. For more information about the chat session tables, see the Genesys Info Mart Physical Data Model for your RDBMS.

At a minimum, Genesys Info Mart requires Chat Server to send the ChatServerSessionStartedAt and ChatServerSessionClosedAt KVPs in the chat session–related reporting event. Genesys Info Mart will not insert a row for a chat session in the CHAT_SESSION_FACT table if either of these KVPs is missing.

The following table describes the KVPs that Genesys Info Mart requires Chat Server to send in Interaction Server reporting events. The information is reproduced for your convenience from information on the Integrating Chat Server with Genesys Historical Reporting page cited above. Release numbers mentioned in the table (for example, indicating when a particular KVP was introduced) refer to the Chat Server release.

Tip
When you configure ICON, Genesys recommends that you use the ICON attached-data specification file (ccon_adata_spec_GIM_Example.xml) included in a Genesys Info Mart IP that supports the required functionality, to ensure that ICON has been configured to capture the required KVPs.


KVP Description Info Mart Database Target
KVP Description Info Mart Database Target
ChatServerSessionClosedAt
 Timestamp of chat session closure.‏ Always attached.

Note: This KVP is mandatory for Genesys Info Mart reporting.		 CHAT_SESSION_FACT.END_DATE_TIME_KEY
ChatServerSessionStartedAt
 Timestamp of chat session creation.‏ Always attached.

Note: This KVP is mandatory for Genesys Info Mart reporting.		 CHAT_SESSION_FACT.START_DATE_TIME_KEY
cse_ActiveIdleMaxTime

Introduced: 8.5.301.06		 The maximum time (in seconds) a chat session has been inactive while at least one agent was connected and a configured inactivity threshold was exceeded. Not mapped
cse_ActiveIdleTotalCount

Introduced: 8.5.301.06		 The total number of times when an inactivity period exceeded a configured threshold while at least one agent was connected to the chat session (in other words, while the chat session was technically in an active state). CHAT_SESSION_FACT.ACTIVE_IDLE_COUNT
cse_ActiveIdleTotalTime

Introduced: 8.5.301.06		 The total amount of time (in seconds), exceeding configured threshold, without any activity when the chat session was in the active state (at least one Agent participated). CHAT_SESSION_FACT.ACTIVE_IDLE_DURATION
cse_AgentReplyMaxTime
 The maximum time (in seconds) an agent spent on replying to a customer.

Note: For async chat sessions, if a chat session was in a dormant state while a customer message was received, the time until the agent rejoins the session is excluded.

CHAT_SESSION_FACT.AGENT_REPLY_MAX_DURATION
cse_AgentReplyTotalCount
 The number of times an agent replied to a customer. CHAT_SESSION_FACT.AGENT_REPLY_COUNT
cse_AgentReplyTotalTime
 The total time (in seconds) an agent spent on replying to a customer.

Note: For async chat sessions, if a chat session was in a dormant state while a customer message was received, the time until the agent rejoins the session is excluded.

CHAT_SESSION_FACT.AGENT_REPLY_DURATION
cse_AgentWaitMaxTime
 The maximum time (in seconds) an agent spent on waiting the reply from a customer.

Note: For async chat sessions, cumulative dormant time until a customer's reply is received is excluded.

CHAT_SESSION_FACT.AGENT_WAIT_MAX_DURATION
cse_AgentWaitTotalCount
 The number of times an agent waited for replies from a customer. CHAT_SESSION_FACT.AGENT_WAIT_COUNT
cse_AgentWaitTotalTime
 The total time (in seconds) an agent spent on waiting the reply from a customer.

Note: For async chat sessions, cumulative dormant time until a customer's reply is received is excluded.

CHAT_SESSION_FACT.AGENT_WAIT_DURATION
cse_AsyncDormantMaxTime

Introduced: 8.5.301.06		 The maximum time (in seconds) a chat session was staying in dormant state. Not mapped
cse_AsyncDormantTotalCount

Introduced: 8.5.301.06		 The total number of times session entered dormant state CHAT_SESSION_FACT.ASYNC_DORMANT_COUNT
cse_AsyncDormantTotalTime

Introduced: 8.5.301.06		 The total amount of time (in seconds), customer chat session was in the dormant state (with no Agent participant). Routing time is excluded from dormant time. CHAT_SESSION_FACT.ASYNC_DORMANT_DURATION
cse_AsyncIdleMaxTime

Introduced: 8.5.301.06		 The maximum time (in seconds) an async chat session was staying in idle state. Not mapped
cse_AsyncIdleTotalCount

Introduced: 8.5.301.06		 Total number of times an async session entered idle state. CHAT_SESSION_FACT.ASYNC_IDLE_COUNT
cse_AsyncIdleTotalTime

Introduced: 8.5.301.06		 The total amount of time (in seconds), exceeding configured threshold, without any activity when the chat session was in the dormant state (with no Agent participant). CHAT_SESSION_FACT.ASYNC_IDLE_DURATION
cse_CustomerReplyMaxTime
 The maximum time (in seconds) a customer spent on replying to an agent. CHAT_SESSION_FACT.CUSTOMER_REPLY_MAX_DURATION
cse_CustomerReplyTotalCount
 The number of times a customer replied to an agent. CHAT_SESSION_FACT.CUSTOMER_REPLY_COUNT
cse_CustomerReplyTotalTime
 The total time (in seconds) a customer spent on replying to an agent. CHAT_SESSION_FACT.CUSTOMER_REPLY_DURATION
cse_CustomerWaitMaxTime
 The maximum time (in seconds) a customer spent on waiting the reply from an agent. CHAT_SESSION_FACT.CUSTOMER_WAIT_MAX_DURATION
cse_CustomerWaitTotalCount
 The number of times a customer waited for the reply from an agent. CHAT_SESSION_FACT.CUSTOMER_WAIT_COUNT
cse_CustomerWaitTotalTime
 The total time (in seconds) a customer spent on waiting the reply from an agent. CHAT_SESSION_FACT.CUSTOMER_WAIT_DURATION
cse_SessionHandleMaxTime

Introduced: 8.5.301.06		 The maximum time (in seconds) that at least one agent was connected to a chat session. Not mapped
cse_SessionHandleTotalCount

Introduced: 8.5.301.06		 The total number of times a session was in an active state, that at least one agent was connected to a chat session. CHAT_SESSION_FACT.HANDLE_COUNT
cse_SessionHandleTotalTime

Introduced: 8.5.301.06		 The total time (in seconds) that at least one agent was connected to a chat session. CHAT_SESSION_FACT.HANDLE_DURATION
csg_ChatAsyncMode

Introduced: 8.5.301.06		 Denotes async session. Equals "1" for async chat session or "0" for regular chat session. CHAT_SESSION_DIM.ASYNC_MODE (referenced through CHAT_SESSION_FACT.CHAT_SESSION_DIM_KEY)
csg_ChatSessionID
 The ID (identifier) of chat session. Could be different from Interaction ID.‏ Attached only if the value of attach-session-statistics is not none. Not mapped
csg_LanguageName
 The value identifies the language specified for the chat session.‏ Might be absent. Attached only if the initial UserData for the chat session includes the GCTI_LanguageName KVP, and the value of attach-session-statistics is not none. CHAT_SESSION_DIM.LANGUAGE_NAME (referenced through CHAT_SESSION_FACT.CHAT_SESSION_DIM_KEY)
csg_MediaOrigin
 The value identifies the origination of the chat session (web chat, social media channels, sms, and so on).‏ Might be absent. Attached only if the initial UserData for the chat session includes the MediaOrigin KVP, and the value of attach-session-statistics is not none. CHAT_SESSION_DIM.MEDIA_ORIGIN (referenced through CHAT_SESSION_FACT.CHAT_SESSION_DIM_KEY)
csg_MediaType

Introduced: 8.5.203.09 (restricted release)		 The MediaType for chat interaction.‏ Always attached. CHAT_SESSION_FACT.MEDIA_NAME_CODE
csg_MessagesFromAgentsCount
 The total number of all messages sent by all agents (messages which are visible to customer). Note: There can be several agents in a chat session, for example, conferences, transfers, and others. CHAT_SESSION_FACT.MSG_FROM_AGENTS_COUNT
csg_MessagesFromAgentsSize
 The total character count (including spaces) of all messages sent by agents. CHAT_SESSION_FACT.MSG_FROM_AGENTS_SIZE
csg_MessagesFromCustomersCount
 The total number of messages sent by customers. CHAT_SESSION_FACT.MSG_FROM_CUSTOMERS_COUNT
csg_MessagesFromCustomersSize
 The total character count (including spaces) of all messages sent by customers. CHAT_SESSION_FACT.MSG_FROM_CUSTOMERS_SIZE
csg_PartiesAsAgentCount
 The number of parties that participated in a session as agents.

Note: Only unique parties are counted. For example, if the same party joins the session several times, it only counts as one for the purpose of this statistic.

CHAT_SESSION_FACT.AGENTS_COUNT
csg_PartiesAsCoachCount
 The number of parties that participated in a session in the coaching mode (for example, an agent joins with the VIP visibility).

Note: Only unique parties are counted. For example, if the same party joins the session several times, it only counts as one for the purpose of this statistic.

Not mapped
csg_PartiesAsMonitorCount
 The number of parties that participated in a session in the monitoring mode (for example, a supervisor join with the INT visibility).

Note: Only unique parties are counted. For example, if the same party joins the session several times, it only counts as one for the purpose of this statistic.

Not mapped
csg_SessionEndedAgent

Introduced: 8.5.109		 The indication of agent presence in chat session.

Please note that in this reason code, only human (in other words, non-bot) agents who are visible to a customer are taken into account.
Valid values: * ABSENT — Session considered as abandoned. No agent (in other words, not-bot participant visible to client) ever joins chat session.

  • PRESENT — Session considered as not abandoned. At least one agent is still participating in chat session during the moment of chat session closure.
  • VISITED — Session could be considered either as abandoned or not abandoned - depending on business requirements. At least one agent participated in chat session, but no agents were present at the moment of chat session closure.
Note: In the very specific condition of a session restoration having occurred where an agent joins the session before restoration and does not re-join after restoration, and no messages are sent by any chat party before restoration, the value of csg_SessionEndedAgent will be ABSENT.		 Not mapped
csg_SessionEndedBy

Introduced: 8.5.105		 The type of participant that triggered the chat session closure.


Valid values: * CLIENT — Denotes a customer. This value is provided whenever a client leaves the chat session first. For example, this value will be set when a client leaves while the session continues due to the presence of an agent and ended later by an agent.

  • AGENT, SUPERVISOR, BOT — Denotes either agent, supervisor or chat bot participant. This type is provided only when:
    • A session is closed because the actor (agent/supervisor/bot) sent the Release request with the close if no more agents, or force close after-action; or
    • A session without a customer during the course of this chat session is closed because the actor sent a Release request.
  • SYSTEM — Denotes a server/system. See the csg_SessionEndedReason table for possible reasons.
 CHAT_SESSION_DIM.ENDED_BY (referenced through CHAT_SESSION_FACT.CHAT_SESSION_DIM_KEY)
csg_SessionEndedReason

Introduced: 8.5.105		 The description of how a chat session was closed.


Valid values: * DISCONNECT — The participant left due to a disconnect (basic protocol) or a flex timeout expiration (denotes disconnect in flex protocol).

  • Possible values for the associated csg_SessionEndedBy: CLIENT, AGENT, SUPERVISOR, BOT
  • QUIT — The participant left a chat session in a normal way (flex logout or basic self-release request, that is with the keep alive after-action).
    Possible values for the associated csg_SessionEndedBy: CLIENT, AGENT, SUPERVISOR, BOT
  • FORCE — The participant left a chat session in a normal way and requested the session to be closed (either close if no more agents or force closure after-action).
    Possible values for the associated csg_SessionEndedBy: AGENT, SUPERVISOR, BOT
  • INACTIVE — Chat Server closed a chat session due to activated inactivity control monitoring.
    Possible values for the associated csg_SessionEndedBy: SYSTEM
  • DB_ERROR — Chat Server closed a chat session because it received the non-recoverable error from UCS while attempting to save the intermediate chat transcript (only possible when the transcript-save-on-error option is set to close).
    Possible values for the associated csg_SessionEndedBy: SYSTEM
 CHAT_SESSION_DIM.ENDED_REASON (referenced through CHAT_SESSION_FACT.CHAT_SESSION_DIM_KEY)
csg_SessionTotalTime
 The total duration of a chat session from the time it was created until it was completely finished/closed in Chat Server.

Note: This does not include the time between Chat Session End and Mark Done, as the interaction can still be handled by an agent.

CHAT_SESSION_FACT.SESSION_DURATION
csg_SessionUntilFirstAgentTime
 The duration of the waiting period, or the period of time a customer waits until the first agent (visible to a customer) joined the session.

Note: The 0 (zero) value has two alternative interpretations: no agents ever joined the session (if csg_PartiesAsAgentCount=0) or an agent joined immediately when the session was started (if csg_PartiesAsAgentCount > 0).

CHAT_SESSION_FACT.UNTIL_FIRST_AGENT_DURATION
csg_SessionUntilFirstReplyTime
 The period of time until the first agent submits the first visible to a customer greeting/message into a chat session. CHAT_SESSION_FACT.UNTIL_FIRST_REPLY_DURATION
csg_SessionWithCustomerTime
 The period of time a customer is in a chat session. Not mapped
csg_TenantId
 The tenant ID for the chat session.‏ Always attached. CHAT_SESSION_FACT.TENANT_KEY



Related Information

For additional discussion of topics related to user-data processing in Genesys Info Mart, see User Data Processing and Storage, User Data Mapping, and Propagation Rules. For a list of the KVPs that contact centers most commonly use for reporting purposes, see Common Attached Data KVPs.

This page was last edited on May 10, 2019, at 14:41.
Comments or questions about this documentation? Contact us for support!