Jdruker/non-ICON
Application-Related Data
New page
Writer's note: Reviewers, I thought it made more sense to group things based on core/legacy vs. newer add-ons, which matches up with the mapping methods. Please advise if you think it would be better to rather present this topic as ICON vs. non-ICON sources, in which case we could retitle this page to something like "Application Data from Alternative (non-ICON) Data Streams," and I would adjust content on this page and on User Data Sources and KVPs accordingly.
While interaction- and agent-related data that comes to Genesys Info Mart from Interaction Concentrator is the core of Info Mart reporting, Genesys Info Mart is continually extending the range of data it encompasses, to include reporting on application usage associated with interactions. This page describes Genesys Info Mart support for supplementary reporting based on application-related data.
About Application-Related Reporting in Genesys Info Mart
In addition to data from its core data sources (T-Server/SIP Server, Interaction Server, Outbound Contact Server, Configuration Server), Genesys Info Mart supports obtaining data from other Genesys applications involved in processing interactions or agent activity. For example, Genesys Info Mart 8.5.011+ processes data from Bot Gateway Server (BGS) on chat bot activity within a chat session. The application-related data can be used to supplement core Info Mart reporting.
Genesys Info Mart support for application-related reporting is predefined and cannot be customized. For a list of supported application reporting features, see Supported Application Reporting.
As Genesys Info Mart support for a wider range of application reporting has evolved, the mechanisms for delivering application-related data to Genesys Info Mart have changed, from user data stored by ICON in IDB to non-ICON channels such as Elasticsearch (ES) and Apache Kafka. Conceptually, there is no difference between the types of data that Genesys Info Mart requires to be sent through one channel or another. Whether Genesys Info Mart requires data from a particular application data source to be sent through ICON, ES, or Kafka is largely a function of development schedules and timing.
Internally, the method for mapping application-related data to Info Mart fact and dimension tables and columns differs from the method used to map customizable user data (see Processing User Data), even for application-related data that comes through ICON. For more information, see How Genesys Info Mart Processes Application-Related Data.
Supported Application Reporting
The following table summarizes the Genesys applications for which Genesys Info Mart provides supplementary reporting.
Writer's note: Reviewers, FYI, the following table is generated by query from the same source content that populates faceted tables on the elasticsearch-<data-source-id> section page and Kafka g:topic option in the Options Ref. Formatting is controlled by template and can easily be tweaked if you'd like to change the wording or what gets displayed.
How Genesys Info Mart Processes Application-Related Data
Processing of application-related data is part of the regular ETL cycle.
- For application reporting data that is sent as user data via ICON, the extraction job extracts the data from IDB and stores the KVPs in the usual way in GIDB tables. The extraction job does not extract data from ES or Kafka data stores.
- The transformation job processes the application-related data from GIDB and from the ES and Kafka nodes Genesys Info Mart has been configured to access.
- Genesys Info Mart uses XML to transform the application data, with the transformation definition stored in the CTL_XML_CONFIG table. For data that comes through Kafka, Genesys Info Mart uses Avro to deserialize the data, and the Avro schema definition is also stored in the CTL_XML_CONFIG table. The XML transformations and, where applicable, Avro schemas are defined in the make_gim_* SQL scripts that create the Info Mart database schema. Writer's note: Reviewers, is it worth mentioning use of Xpath, so that we get the term into the doc to yield a search result?
- Based on the mappings in the CTL_XML_CONFIG table, Genesys Info Mart creates records in the fact and dimension tables defined for the application reporting feature—fact tables for high-cardinality data, and dimension tables for low-cardinality data. To prevent the transformation job from failing if a value is not received for a reporting data attribute mapped to a non-nullable column, default or fallback values are defined in the XML transformation. Writer's note: Alexey, (1) we deferred documenting the error-policy-ue-on-fail config option from an early implementation. Please confirm that we do not need to document it now either. (2) Please see step 5 under Processing User Data ("If the attempt to convert a KVP value...fails..."). Do we need to include equivalent info here about STG_TRANSFORM_DISCARDS?
- Writer's note: Alexey, please esp. confirm this next paragraph, which covers the kind of information I think we need to provide. It's partially based on information you provided in our Q&A for Kafka, but I've extended it based on a lot of assumptions. If Elasticsearch or Kafka throw an exception (for example, because of a connection loss), Genesys Info Mart logs the exception as a transformation job error in log message 55-20049. The transformation job itself does not fail, regardless of the value set for any error-policy-* configuration options. When the error condition is resolved, Genesys Info Mart resumes processing from the previous transformation high-water mark (HWM).
- Tables that store application-related data are included in Genesys Info Mart processing of General Data Protection Regulation (GDPR) "forget" or export requests if the reporting attributes that populate the columns potentially contain personally identifiable information (PII). For a list of the tables and columns that are included in GDPR processing, see the description of the CTL_GDPR_HISTORY table in the Physical Data Model for your RDBMS.
Configuration Requirements
The documentation suites for the respective application data sources provide detailed information about configuring the application, the intermediary data storage/delivery mechanism, Genesys Info Mart, and RAA (if applicable) to enable reporting on a particular application feature. Configuration requirements depend on the data delivery channel.
See Application-Specific Considerations for links to detailed configuration information for the respective applications. In general:
- Data from ICON—Ensure that ICON has been configured to store the required user data. There are no additional configuration requirements or considerations on the Genesys Info Mart side.
- Data from Elasticsearch—Configure the option(s) in the [elasticsearch-<data-source-id>] section, to specify deployment-specific connection information. Genesys recommends that you set an alarm on log message 55-20049, to alert you to connection issues or other ES errors that are interrupting Genesys Info Mart processing. Ensure that your ES data retention policy provides a sufficient buffer to enable Genesys Info Mart to recover from unexpected delays, so that ES indices are not deleted before Genesys Info Mart has transformed the data. On the other hand, if any index properties potentially contain PII, ensure that ES data will not be stored for more than 30 days.
- Data from Kafka—Configure the options in the [kafka-<cluster-name>] section, to specify deployment-specific connection information and application-specific topic information. Genesys recommends that you set an alarm on log message 55-20049, to alert you if Genesys Info Mart loses connection to the Kafka cluster. Ensure that your Kafka data retention policy provides a sufficient buffer to enable Genesys Info Mart to recover from unexpected delays, so that messages are not discarded before Genesys Info Mart has consumed them. On the other hand, if any Kafka messages potentially contain PII, ensure that Kafka records will not be stored for more than 30 days.
- Aggregation—If your deployment includes Genesys-provided aggregation, Reporting and Analytics Aggregates (RAA) requires you to configure enable- options in the [agg-feature] section on the Genesys Info Mart application object, to enable population of application-related data in the applicable aggregate tables.
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
- Universal Routing
- eServices/Multimedia
- Outbound Contact Solution
- Agent Desktop Applications
- Writer's note: Links to sections that have been moved to another page have been deleted.
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.
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_ | 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_ |
VQ_ | 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_ |
_ 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_ |
_ Introduced: 8.5.200.07 | The result of the first callback dialing attempt. One of the following values:
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_ |
_ Introduced: 8.5.200.07 | The result of the second callback dialing attempt. See _CB_DIAL_1_RESULT for possible values. | CALLBACK_ |
_ Introduced: 8.5.200.07 | The result of the third callback dialing attempt. See _CB_DIAL_1_RESULT for possible values. | CALLBACK_ |
_ Introduced: 8.5.200.07 | The result of the fourth callback dialing attempt. See _CB_DIAL_1_RESULT for possible values. | CALLBACK_ |
_ Introduced: 8.5.200.07 | The result of the fifth callback dialing attempt. See _CB_DIAL_1_RESULT for possible values. | CALLBACK_ |
_ | 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:
| CALLBACK_ |
_ | The direction of the final callback interaction. One of the following values:
| CALLBACK_ |
_ | The interaction channel from which the callback originated. One of the following values:
| CALLBACK_ |
_ | The order in which the final callback interaction was connected. One of the following values:
| CALLBACK_ |
_ | The result of the final dialog for the callback. One of the following values:
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_ |
_ | The result of the final callback dialing attempt. One of the following values:
Notes: 2. CANCEL is set when the on_dial plugin returned action=CANCEL. | CALLBACK_ |
_ | The routing target that was used to find the agent. | CALLBACK_ |
_ | Specifies whether the callback offer was made during operational (business) or non-operational hours. One of the following values:
| CALLBACK_ |
_ | The type of callback the customer requested. One of the following values:
| CALLBACK_ |
_ | 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_ |
_ | 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_ |
_ | Callback state using the format <state>.<sub state> where:
| CALLBACK_ |
_ | The duration of the callback offer, in seconds.
Note: This KVP is mandatory for Genesys Info Mart reporting. | CALLBACK_ |
_ | The amount of time, in seconds, the customer was waiting to be connected to the agent after the callback interaction was established. | CALLBACK_ |
_ Introduced: 8.5.106.14 | The amount of time, in seconds, the customer waited in the queue before a callback was offered. | CALLBACK_ |
_ | The amount of time, in seconds, it took to establish the callback interaction, such as an outbound call. | CALLBACK_ |
_ | The amount of time, in seconds, the customer was waiting offline for an agent to become available. | CALLBACK_ |
_ 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_ |
_ | The value of EWT, in seconds, at the time the callback was offered. | CALLBACK_ |
_ Introduced: 8.5.200.07 | Estimated Wait Time in seconds when the last dial attempt was made or the last push notification sent. | CALLBACK_ |
_ | 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_ |
_ | Indicates whether this is a final record about this callback service: 0 = No, 1 = Yes. | CALLBACK_ |
_ Introduced: 8.5.200.07 | The call ID of the first outbound call that the callback service created. | CALLBACK_ |
_ Introduced: 8.5.200.07 | For premise callback, _CB_IXN_START_IGNORING_AVAILABILITY will always be 0. | CALLBACK_ |
_ Introduced: 8.5.200.07 | The call ID of the last outbound call that the callback service created. | CALLBACK_ |
_ 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_ |
_ | Indicates whether the agent was successfully added to the callback interaction: 0 = No, 1 = Yes. | CALLBACK_ |
_ | Indicates whether a callback offer was accepted: 0 = No, 1 = Yes. | CALLBACK_ |
_ | The total number of callback attempts or notifications, both successful and unsuccessful. | CALLBACK_ |
_ | 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_ |
_ | Indicates whether the customer abandoned the callback interaction while waiting to be connected to an agent: 0 = No, 1 = Yes. | CALLBACK_ |
_ | Indicates whether the interaction required agent assistance: 0 = No, 1 = Yes. | CALLBACK_ |
_ | Indicates whether the customer was disconnected because the timeout for waiting for an agent was reached: 0 = No, 1 = Yes. | CALLBACK_ |
_ | Number of times the callback interaction failed to transfer to the agent. | CALLBACK_ |
_ 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_ |
_ 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_ |
_ 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_ |
_ | The customer position in the queue when callback was offered. | CALLBACK_ |
_ Introduced: 8.5.200.07 | Position in queue when the last dial attempt was made or the last push notification sent. | CALLBACK_ |
_ | 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_ |
_ 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_ |
_ Introduced: 8.5.200.07 | Priority of the interaction (real or virtual) when the callback offer was accepted. | CALLBACK_ |
_ Introduced: 8.5.200.07 | Priority of the virtual interaction when the customer was connected. | CALLBACK_ |
_ | 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_ |
_ | The Tenant DBID. | CALLBACK_ |
_ | The UTC timestamp when the callback offer was accepted. | CALLBACK_ |
_ | The UTC timestamp when the callback was offered.
Note: This KVP is mandatory for Genesys Info Mart reporting. | CALLBACK_ |
_ | The UTC timestamp when the customer was reconnected to the contact center and started waiting for an agent to be connected. | CALLBACK_ |
_ Introduced: 8.5.200.07 | UTC Timestamp of the first dialing attempt. | CALLBACK_ |
_ Introduced: 8.5.200.07 | UTC Timestamp of the second dialing attempt. | CALLBACK_ |
_ Introduced: 8.5.200.07 | UTC Timestamp of the third dialing attempt. | CALLBACK_ |
_ Introduced: 8.5.200.07 | UTC Timestamp of the fourth dialing attempt. | CALLBACK_ |
_ Introduced: 8.5.200.07 | UTC Timestamp of the fifth dialing attempt. | CALLBACK_ |
_ | 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_ |
_ Introduced: 8.5.111.04 | UTC timestamp for when service was completed or terminated. | CALLBACK_ |
_ | 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_ |
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_ | 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_ |
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_ |
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_ |
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_ |
gpmAgentDBID | Optional. The DBID of the agent to whom the interaction was routed.
Default value: no default value | INT | RESOURCE_ |
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_ |
gpmAgentScore | The score of the agent to whom the interaction was routed.
Default value: 0 Valid values: any non-negative float value | FLOAT | GPM_ |
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_ |
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_ |
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_ |
gpmDefaultScoreUsed Introduced: 9.0.015.00 |
Default value: 0 Valid values: 0, 1 | INT | GPM_ |
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_ |
gpmGlobalScore | The mean score calculated for an interaction using the Global Model.
Default value: 0 Valid values: any non-negative float value | FLOAT | GPM_ |
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_ |
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_ |
gpmMaxScore | The score of the best-matching agent in the target group.
Default value: 0 Valid values: any non-negative float value | FLOAT | GPM_ |
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_ |
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_ |
gpmMinScore | The score of the worst-matching agent in the target group.
Default value: 0 Valid values: any non-negative float value | FLOAT | GPM_ |
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_ |
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_ |
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_ |
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_ |
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_ |
gpmPredictorType Introduced: 9.0.015.00 | Reserved for future use.
Default value: unknown Valid values: Sales, Service | CHAR[32] | GPM_ |
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.
Default value: no default value Valid values: 1–15 Note: This KVP is mandatory for Genesys Info Mart reporting. | Enum | GPM_ |
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_ |
gpmRoutingMethod Introduced: 9.0.015.00 | Reserved for future use.
Default value: unknown | CHAR[32] | GPM_ |
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_ |
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_ |
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_ |
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_ |
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:
Default value: unknown Valid values: 1, 0, unknown | Enum | GPM_ |
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).
Default value: No default value Valid values: Any valid DBID | INT | RESOURCE_ |
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.
Default value: No default value Valid values: Any valid Virtual Queue GUID | CHAR[32] | GPM_ |
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_ |
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_ |
START_ | 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_ |
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.
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_ |
ChatServerSessionStartedAt | Timestamp of chat session creation. Always attached.
Note: This KVP is mandatory for Genesys Info Mart reporting. | CHAT_ |
cse_ 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_ 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_ |
cse_ 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_ |
cse_ | 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_ |
cse_ | The number of times an agent replied to a customer. | CHAT_ |
cse_ | 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_ |
cse_ | 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_ |
cse_ | The number of times an agent waited for replies from a customer. | CHAT_ |
cse_ | 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_ |
cse_ Introduced: 8.5.301.06 | The maximum time (in seconds) a chat session was staying in dormant state. | Not mapped |
cse_ Introduced: 8.5.301.06 | The total number of times session entered dormant state | CHAT_ |
cse_ 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_ |
cse_ Introduced: 8.5.301.06 | The maximum time (in seconds) an async chat session was staying in idle state. | Not mapped |
cse_ Introduced: 8.5.301.06 | Total number of times an async session entered idle state. | CHAT_ |
cse_ 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_ |
cse_ | The maximum time (in seconds) a customer spent on replying to an agent. | CHAT_ |
cse_ | The number of times a customer replied to an agent. | CHAT_ |
cse_ | The total time (in seconds) a customer spent on replying to an agent. | CHAT_ |
cse_ | The maximum time (in seconds) a customer spent on waiting the reply from an agent. | CHAT_ |
cse_ | The number of times a customer waited for the reply from an agent. | CHAT_ |
cse_ | The total time (in seconds) a customer spent on waiting the reply from an agent. | CHAT_ |
cse_ Introduced: 8.5.301.06 | The maximum time (in seconds) that at least one agent was connected to a chat session. | Not mapped |
cse_ 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_ |
cse_ Introduced: 8.5.301.06 | The total time (in seconds) that at least one agent was connected to a chat session. | CHAT_ |
csg_ Introduced: 8.5.301.06 | Denotes async session. Equals "1" for async chat session or "0" for regular chat session. | CHAT_ |
csg_ | 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_ | 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_ |
csg_ | 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_ |
csg_ Introduced: 8.5.203.09 (restricted release) | The MediaType for chat interaction. Always attached. | CHAT_ |
csg_ | 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_ |
csg_ | The total character count (including spaces) of all messages sent by agents. | CHAT_ |
csg_ | The total number of messages sent by customers. | CHAT_ |
csg_ | The total character count (including spaces) of all messages sent by customers. | CHAT_ |
csg_ | 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_ |
csg_ | 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_ | 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_ 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.
| Not mapped |
csg_ Introduced: 8.5.105 | The type of participant that triggered the chat session closure.
| CHAT_ |
csg_ Introduced: 8.5.105 | The description of how a chat session was closed.
| CHAT_ |
csg_ | 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_ |
csg_ | 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_ |
csg_ | The period of time until the first agent submits the first visible to a customer greeting/message into a chat session. | CHAT_ |
csg_ | The period of time a customer is in a chat session. | Not mapped |
csg_ | The tenant ID for the chat session. Always attached. | CHAT_ |