Jose.druker@genesys.com/CallbackReporting
Contents
Configure Historical Reporting
Writer's note: This is from Configure Historical Reporting in the GMS Dep Guide (which is transcluded to Set up Historical Reporting in the Callback Solution Guide.
...
Historical Reporting Architecture
Reporting on Genesys Callback relies on the user-event mechanism to provide Callback-related metrics and requires Interaction Concentrator, Genesys Info Mart, and Reporting and Analytics Aggregates (RAA) to collect and organize data to produce a database from which Genesys Interactive Insights (GI2) Genesys CX Insights (GCXI) can rapidly extract the needed data.
Relabel GI2 --> GCXI
- Genesys Callback reports callback metrics through UserEvents to the configured DN. SCXML strategies that you load through the templates in the Service Management UI collect metrics, and then pass the metrics as user data (KVPs) with two UserEvent events, one sent at the start of the session and another, at the end of the session. Genesys Info Mart has certain minimum requirements for the KVPs that must be sent. The out-of-box templates include these KVPs, as well as other KVPs that Genesys Info Mart requires for meaningful reporting. See Genesys Info Mart KVP Requirements for details.
- Interaction Concentrator (ICON) stores the user data (KVPs) attached to these events into the G_CUSTOM_DATA_S table of the Interaction Database (IDB).
- Genesys Info Mart transforms the data into the CALLBACK_FACT table and related CALLBACK_* dimensions of the Info Mart database; this format can be more quickly loaded into reports.
- Reporting and Analytics Aggregates (RAA) aggregates the data; in other words, RAA summarizes and organizes the data from Genesys Info Mart in such a way that GCXI is able to extract meaning.
- Genesys CX Insights (GCXI) then presents two out-of-box callback reports: Callback Summary Report and Callback Details Report.
For example, for reporting purposes, the following are some of the keys that GMS sends in UserEvents related to Outbound calls:
- _CB_T_SERVICE_START
- _CB_SERVICE_ID
- _CB_D_CALLBACK_OFFER
- _CB_N_CALLBACK_OFFERED
- _CB_T_CALLBACK_OFFERED
- _CB_T_CALLBACK_ACCEPTED
- _CB_T_CUSTOMER_CONNECTED
- _CB_N_IS_SNOOZED
- _CB_T_NEXT_REDIAL_ATTEMPT
- _CB_N_CALLBACK_MEDIA_ATTEMPTS
- _CB_T_LAST_DIAL_ATTEMPT
- _CB_N_AGENT_ADDED_TO_IXN
The keys that GMS sends depend on the scenario. To get a complete list of the keys that might be sent, refer to the Callback KVPs reference in this page.
Genesys Info Mart KVP Requirements
The following KVPs are mandatory. Genesys Info Mart will not create a record for the callback event if the KVP is missing from the UserEvent.
- _CB_SERVICE_ID
- _CB_T_SERVICE_START
- _CB_D_CALLBACK_OFFER
- _CB_N_CALLBACK_OFFERED
- _CB_T_CALLBACK_OFFERED
The following four KVPs need to be sent in both UserEvents and as call-based attached data in TEvents.The duplicated KVPs enable Genesys Info Mart to associate the callback event with interaction data.
- _CB_T_CALLBACK_ACCEPTED
- _CB_T_SERVICE_START
- _CB_SERVICE_ID
- _CB_T_CUSTOMER_CONNECTED
For meaningful reporting, Genesys Info Mart requires a number of other KVPs, depending on the callback scenario. See the Callback KVPs reference, below, for the complete list.
- The _CB_SERVICE_ID is returned by the GMS API in response to the callback request.
- For Inbound Calls, where the in-queue callback offer was presented and accepted, _CB_T_CALLBACK_ACCEPTED, _CB_T_SERVICE_START, and _CB_SERVICE_ID must be attached at the time at which the callback was accepted.
- For Virtual and Outbound Calls, _CB_T_CUSTOMER_CONNECTED must be attached at the time at which the customer was connected.
Virtual Queues
As a best practice, Genesys recommends to create virtual queues associated with the following interaction types:
- Virtual Queue for Inbound calls—This queue is where the regular inbound calls are going to be reported. Those calls are callbacks that were not offered or, offered and rejected.
- Virtual Queue for Virtual callbacks—This queue is where the virtual callbacks are going to be waiting for an agent.
- Virtual Queue for Outbound calls—This is where the callback application will place the real outbound call when it gets confirmation that the right person is connected. The call is removed from this queue after it is successfully delivered to an agent or is abandoned by the customer.
Related Resources for Historical Reporting
You may also be interested in reading:
- The Supplement page in the Genesys Interactive Insights Universe Guide.
- The Genesys Info Mart Physical Data Model documentation for your RDBMS.
- The Reporting and Analytics Aggregates Physical Data Model documentation for your RDBMS.
Configure Historical Reporting
Configure a Reporting DN
Open Genesys Administrator or Configuration Manager and create a new DN of type Trunk Group DN. The name of the DN is used inside SCXML scripts, so it should be meaningful and recognizable.
For example: Sip_Switch > DN > REPORTING
Configure your Callback Service
Configure Orchestration Server
In the connections of your Orchestration Server application, add the T-Server used to define the reporting Switch and DN in the GMS service configuration. For example, Sip_Switch.
Configure Interaction Concentrator
To make Callback reporting work, you need to configure Interaction Concentrator (ICON) for Voice. See here for details.
Set the KVP list
- Configure ICON to store the KVP data provided in the UserData section of EventUserEvents. ICON will store this data in the G_CUSTOM_DATA_S table of the Interaction Database (IDB):
- ICON > Options > custom-states/store-event-data=all
- By default, store-event-data is set to none.
- Configure ICON to store required duplicate KVP data provided in the UserData attribute of TEvents. ICON will store this data in the G_USERDATA_HISTORY table. To enable this storage, modify your ccon_adata_spec.xml file to capture the four TEvents KVPs described in the Callback KVPs reference below:
- _CB_T_CALLBACK_ACCEPTED
- _CB_T_CUSTOMER_CONNECTED
- _CB_T_SERVICE_START
- _CB_SERVICE_ID
Check Interaction Concentrator Connections
Make sure that Interaction Concentrator is connected to the T-Server that is servicing the switch specified in the Callback Service.
For example: Sip_Switch.
Start Interaction Concentrator and use logs to verify that it registered on the REPORTING DN.
Configure Reporting and Analytics Aggregates
Edit the Genesys Info Mart application to enable the agg-feature\enable-callback option:
agg-feature\enable-callback=yes
Verify Reporting Data
- Run your scenario by triggering Genesys Mobile Services and Orchestration Server (ORS) APIs directly.
- Make sure user events are being delivered to Interaction Concentrator applications by checking T-Server logs. You should see something like this:
00:34:20.757 Int 04543 Interaction message "RequestDistributeUserEvent" received from
516 ("OrchestrationServer")
-- Absent ThisDN, REPORTING was used
@00:34:20.7570 [0] 8.1.000.62 send_to_client: message EventACK
AttributeEventSequenceNumber 0000000000000ef8
AttributeCustomerID 'Environment'
AttributeTimeinuSecs 757000
AttributeTimeinSecs 1348817660 (00:34:20)
AttributeReferenceID 431
AttributeThisDN 'REPORTING'
AttributeUserEvent RequestDistributeUserEvent
00:34:20.757 Trc 04542 EventACK sent to [516] (00000003 OrchestrationServer 192.168.27.50:40727)
@00:34:20.7570 [0] 8.1.000.62 distribute_user_event: message EventUserEvent
AttributeEventSequenceNumber 0000000000000ef9
AttributeCustomerID 'Environment'
AttributeTimeinuSecs 757000
AttributeTimeinSecs 1348817660 (00:34:20)
AttributeUserEvent EventUserEvent
AttributeUserData [347] 00 0c 00 00..
'gms_AgentAvailable' '1348817660755'
'gms_AgentConnected' ''
'gms_IxnCompleted' ''
'gms_ServiceName' 'inbound-delay'
'gms_ServiceStartAt' '1348817660553'
'gms_ServiceStoppedAt' ''
'gms_SessionEventSeq' 3
'gms_SessionId' '65UA6ISSJH76R340BNDQ2DG0DG000036'
'gms_UserConnected' ''
'gms_UserId' ''
'gms_WaitingForAgent' '1348817660744'
'gms_externalId' ''
AttributeANI '777'
AttributeDNIS '333'
AttributeReferenceID 431
AttributeThisDN 'REPORTING'
00:34:20.758 Trc 04542 EventUserEvent sent to [508] (0000000c Icon_Voice 192.168.27.50:42678)
00:34:20.758 Trc 04542 EventUserEvent sent to [588] (00000004 Stat_Server 192.168.27.50:40728)
00:34:20.758 Trc 04542 EventUserEvent sent to [592] (00000005 Universal_Routing_Server
192.168.27.50:40744)3. Check your Interaction Concentrator logs and the G_CUSTOM_DATA_S table in Interaction Database and make sure that data is recorded properly.
For example, you should see in Interaction Concentrator logs:
00:39:19.569 Int 04543 Interaction message "EventUserEvent" received from 65200 ("SIP_Server@REPORTING")
00:39:19.751 Int 04543 Interaction message "EventUserEvent" received from 65200 ("SIP_Server@REPORTING")
00:39:19.766 Int 04543 Interaction message "EventUserEvent" received from 65200 ("SIP_Server@REPORTING")
00:39:19.987 Trc 25016 Persistent Queue GUD: transaction 10929 is committed. 5 records written
into the queue
00:39:19.987 Trc 25003 Database queue [GUD]: persistent queue transaction 10929 is being processed.
00:39:20.001 Trc 25004 Database queue [GUD]: persistent queue transaction 10929 is processed, committed
and removed. 5 records are written.4. Optionally, you can also check the content of the CALLBACK_FACT table in the Info Mart database to make sure that the transformation process is correctly executed as well. For example, you can try the following query:
SELECT * FROM dbo. CALLBACK_FACT
How to Pass Reporting KVPs of the Inbound Call in the Callback Request
Some historical reporting KVP values are known only by the IVR or application that requests the callback service. Including these KVPs in the historical reporting is optional. If you want to include them, the values can be passed in the HTTP request that starts the Callback service. The following is the list of the KVP parameters that can be passed in the HTTP request. Each maps to the corresponding _CB_X KVP.
- _cb_t_callback_offered
- _cb_d_callback_offer
- _cb_ewt_when_callback_was_offered
- _cb_pos_when_callback_was_offered
- _cb_t_callback_accepted
- _cb_dim_channel
- _cb_dim_callback_offer_type
- _cb_dim_offer_timing
- _cb_n_callback_offers_per_session
- _cb_d_last_callback_offer
Reference: Callback KVPs
The following table describes the KVPs that, if sent by GMS in UserEvents, Genesys Info Mart uses to enable Callback reporting.
The following four KVPs must also be sent as call-based attached data.
- _CB_SERVICE_ID
- _CB_T_SERVICE_START
- _CB_T_CALLBACK_ACCEPTED
- _CB_T_CUSTOMER_CONNECTED
| KVP | Description | Info Mart Database Target |
|---|---|---|
|
{{{KVP}}} |
{{{KVPDesc}}} | |
|
csg_ |
The total number of messages visible to the customer that were sent by all bots that participated in the chat session. | CHAT_ |
|
csg_ |
The total character count (including spaces) of all messages sent by bots that participated in the chat session. | CHAT_ |
|
csg_ |
The duration of the waiting period, or the period of time a customer waits until the first bot (visible to a customer) joined the chat session. Note: The 0 (zero) value has two alternative interpretations: No bots ever joined the session (if csg_PartiesAsBotCount=0) or a bot joined immediately when the chat session was started (if csg_PartiesAsBotCount > 0). |
CHAT_ |
|
csg_ |
The number of parties that participated in a chat session as bots. If the same bot (in other words, a bot with the same ID) connects multiple times, it is counted as a separate participant each time it joins. | CHAT_ |
|
{{{KVP}}} |
{{{KVPDesc}}} | |
|
csg_ |
The total number of messages visible to the customer that were sent by all bots that participated in the chat session. | CHAT_ |
|
csg_ |
The total character count (including spaces) of all messages sent by bots that participated in the chat session. | CHAT_ |
|
csg_ |
The duration of the waiting period, or the period of time a customer waits until the first bot (visible to a customer) joined the chat session. Note: The 0 (zero) value has two alternative interpretations: No bots ever joined the session (if csg_PartiesAsBotCount=0) or a bot joined immediately when the chat session was started (if csg_PartiesAsBotCount > 0). |
CHAT_ |
|
csg_ |
The number of parties that participated in a chat session as bots. If the same bot (in other words, a bot with the same ID) connects multiple times, it is counted as a separate participant each time it joins. | CHAT_ |
|
{{{KVP}}} |
{{{KVPDesc}}} | |
|
csg_ |
The total number of messages visible to the customer that were sent by all bots that participated in the chat session. | CHAT_ |
|
csg_ |
The total character count (including spaces) of all messages sent by bots that participated in the chat session. | CHAT_ |
|
csg_ |
The duration of the waiting period, or the period of time a customer waits until the first bot (visible to a customer) joined the chat session. Note: The 0 (zero) value has two alternative interpretations: No bots ever joined the session (if csg_PartiesAsBotCount=0) or a bot joined immediately when the chat session was started (if csg_PartiesAsBotCount > 0). |
CHAT_ |
|
csg_ |
The number of parties that participated in a chat session as bots. If the same bot (in other words, a bot with the same ID) connects multiple times, it is counted as a separate participant each time it joins. | CHAT_ |
|
{{{KVP}}} |
{{{KVPDesc}}} | |
|
csg_ |
The total number of messages visible to the customer that were sent by all bots that participated in the chat session. | CHAT_ |
|
csg_ |
The total character count (including spaces) of all messages sent by bots that participated in the chat session. | CHAT_ |
|
csg_ |
The duration of the waiting period, or the period of time a customer waits until the first bot (visible to a customer) joined the chat session. Note: The 0 (zero) value has two alternative interpretations: No bots ever joined the session (if csg_PartiesAsBotCount=0) or a bot joined immediately when the chat session was started (if csg_PartiesAsBotCount > 0). |
CHAT_ |
|
csg_ |
The number of parties that participated in a chat session as bots. If the same bot (in other words, a bot with the same ID) connects multiple times, it is counted as a separate participant each time it joins. | CHAT_ |
|
{{{KVP}}} |
{{{KVPDesc}}} | |
|
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. | |
|
csg_ |
The tenant ID for the chat session. Always attached. | CHAT_ |
|
csg_ |
The MediaType for chat interaction. Always attached. | 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_ |
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_ |
|
ChatServerSessionStartedAt |
Timestamp of chat session creation. Always attached. | CHAT_ |
|
ChatServerSessionClosedAt |
Timestamp of chat session closure. Always attached. | CHAT_ |
|
csg_ |
The type of participant that triggered the chat session closure. | CHAT_ |
|
csg_ |
The description of how a chat session was closed. | CHAT_ |
|
csg_ |
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. |
|
|
cse_ |
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_ |
The total time (in seconds) that at least one agent was connected to a chat session. | CHAT_ |
|
cse_ |
The maximum time (in seconds) that at least one agent was connected to a chat session. | |
|
cse_ |
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_ |
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) a chat session has been inactive while at least one agent was connected and a configured inactivity threshold was exceeded. | |
|
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. |
|
|
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. |
|
|
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. | |
|
cse_ |
The number of times an agent replied to a customer. | 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 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 number of times an agent waited for replies from a customer. | 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 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_ |
The number of times a customer replied to an agent. | CHAT_ |
|
cse_ |
The maximum time (in seconds) a customer spent on replying to an agent. | CHAT_ |
|
cse_ |
The total time (in seconds) a customer spent on replying to an agent. | CHAT_ |
|
cse_ |
The number of times a customer waited for the reply from an agent. | CHAT_ |
|
cse_ |
The maximum time (in seconds) a customer spent on waiting the reply from an agent. | CHAT_ |
|
cse_ |
The total time (in seconds) a customer spent on waiting the reply from an agent. | CHAT_ |
|
cse_ |
The total number of times session entered dormant state | CHAT_ |
|
cse_ |
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_ |
Total number of times an async session entered idle state. | CHAT_ |
|
cse_ |
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_ |
|
csg_ |
Denotes async session. Equals "1" for async chat session or "0" for regular chat session. | CHAT_ |
|
cse_ |
The maximum time (in seconds) an async chat session was staying in idle state. | |
|
cse_ |
The maximum time (in seconds) a chat session was staying in dormant state. | |
|
{{{KVP}}} |
{{{KVPDesc}}} | |
|
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. | |
|
csg_ |
The tenant ID for the chat session. Always attached. | CHAT_ |
|
csg_ |
The MediaType for chat interaction. Always attached. | 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_ |
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_ |
|
ChatServerSessionStartedAt |
Timestamp of chat session creation. Always attached. | CHAT_ |
|
ChatServerSessionClosedAt |
Timestamp of chat session closure. Always attached. | CHAT_ |
|
csg_ |
The type of participant that triggered the chat session closure. | CHAT_ |
|
csg_ |
The description of how a chat session was closed. | CHAT_ |
|
csg_ |
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. |
|
|
cse_ |
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_ |
The total time (in seconds) that at least one agent was connected to a chat session. | CHAT_ |
|
cse_ |
The maximum time (in seconds) that at least one agent was connected to a chat session. | |
|
cse_ |
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_ |
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) a chat session has been inactive while at least one agent was connected and a configured inactivity threshold was exceeded. | |
|
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. |
|
|
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. |
|
|
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. | |
|
cse_ |
The number of times an agent replied to a customer. | 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 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 number of times an agent waited for replies from a customer. | 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 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_ |
The number of times a customer replied to an agent. | CHAT_ |
|
cse_ |
The maximum time (in seconds) a customer spent on replying to an agent. | CHAT_ |
|
cse_ |
The total time (in seconds) a customer spent on replying to an agent. | CHAT_ |
|
cse_ |
The number of times a customer waited for the reply from an agent. | CHAT_ |
|
cse_ |
The maximum time (in seconds) a customer spent on waiting the reply from an agent. | CHAT_ |
|
cse_ |
The total time (in seconds) a customer spent on waiting the reply from an agent. | CHAT_ |
|
cse_ |
The total number of times session entered dormant state | CHAT_ |
|
cse_ |
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_ |
Total number of times an async session entered idle state. | CHAT_ |
|
cse_ |
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_ |
|
csg_ |
Denotes async session. Equals "1" for async chat session or "0" for regular chat session. | CHAT_ |
|
cse_ |
The maximum time (in seconds) an async chat session was staying in idle state. | |
|
cse_ |
The maximum time (in seconds) a chat session was staying in dormant state. | |
|
{{{KVP}}} |
{{{KVPDesc}}} | |
|
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. | |
|
csg_ |
The tenant ID for the chat session. Always attached. | CHAT_ |
|
csg_ |
The MediaType for chat interaction. Always attached. | MEDIA_ |
|
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_ |
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_ |
|
ChatServerSessionStartedAt |
Timestamp of chat session creation. Always attached. | CHAT_ |
|
ChatServerSessionClosedAt |
Timestamp of chat session closure. Always attached. | CHAT_ |
|
csg_ |
The type of participant that triggered the chat session closure. | CHAT_ |
|
csg_ |
The description of how a chat session was closed. | CHAT_ |
|
csg_ |
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. |
|
|
cse_ |
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_ |
The total time (in seconds) that at least one agent was connected to a chat session. | CHAT_ |
|
cse_ |
The maximum time (in seconds) that at least one agent was connected to a chat session. | |
|
cse_ |
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_ |
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) a chat session has been inactive while at least one agent was connected and a configured inactivity threshold was exceeded. | |
|
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. |
|
|
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. |
|
|
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. | |
|
cse_ |
The number of times an agent replied to a customer. | 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 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 number of times an agent waited for replies from a customer. | 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 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_ |
The number of times a customer replied to an agent. | CHAT_ |
|
cse_ |
The maximum time (in seconds) a customer spent on replying to an agent. | CHAT_ |
|
cse_ |
The total time (in seconds) a customer spent on replying to an agent. | CHAT_ |
|
cse_ |
The number of times a customer waited for the reply from an agent. | CHAT_ |
|
cse_ |
The maximum time (in seconds) a customer spent on waiting the reply from an agent. | CHAT_ |
|
cse_ |
The total time (in seconds) a customer spent on waiting the reply from an agent. | CHAT_ |
|
cse_ |
The total number of times session entered dormant state | CHAT_ |
|
cse_ |
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_ |
Total number of times an async session entered idle state. | CHAT_ |
|
cse_ |
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_ |
|
csg_ |
Denotes async session. Equals "1" for async chat session or "0" for regular chat session. | CHAT_ |
|
cse_ |
The maximum time (in seconds) an async chat session was staying in idle state. | |
|
cse_ |
The maximum time (in seconds) a chat session was staying in dormant state. | |
|
{{{KVP}}} |
{{{KVPDesc}}} | |
|
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. | |
|
csg_ |
The tenant ID for the chat session. Always attached. | CHAT_ |
|
csg_ |
The MediaType for chat interaction. Always attached. | MEDIA_ |
|
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_ |
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_ |
|
ChatServerSessionStartedAt |
Timestamp of chat session creation. Always attached. | CHAT_ |
|
ChatServerSessionClosedAt |
Timestamp of chat session closure. Always attached. | CHAT_ |
|
csg_ |
The type of participant that triggered the chat session closure. | CHAT_ |
|
csg_ |
The description of how a chat session was closed. | CHAT_ |
|
csg_ |
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. |
|
|
cse_ |
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_ |
The total time (in seconds) that at least one agent was connected to a chat session. | CHAT_ |
|
cse_ |
The maximum time (in seconds) that at least one agent was connected to a chat session. | |
|
cse_ |
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_ |
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) a chat session has been inactive while at least one agent was connected and a configured inactivity threshold was exceeded. | |
|
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. |
|
|
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. |
|
|
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. | |
|
cse_ |
The number of times an agent replied to a customer. | 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 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 number of times an agent waited for replies from a customer. | 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 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_ |
The number of times a customer replied to an agent. | CHAT_ |
|
cse_ |
The maximum time (in seconds) a customer spent on replying to an agent. | CHAT_ |
|
cse_ |
The total time (in seconds) a customer spent on replying to an agent. | CHAT_ |
|
cse_ |
The number of times a customer waited for the reply from an agent. | CHAT_ |
|
cse_ |
The maximum time (in seconds) a customer spent on waiting the reply from an agent. | CHAT_ |
|
cse_ |
The total time (in seconds) a customer spent on waiting the reply from an agent. | CHAT_ |
|
cse_ |
The total number of times session entered dormant state | CHAT_ |
|
cse_ |
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_ |
Total number of times an async session entered idle state. | CHAT_ |
|
cse_ |
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_ |
|
csg_ |
Denotes async session. Equals "1" for async chat session or "0" for regular chat session. | CHAT_ |
|
cse_ |
The maximum time (in seconds) an async chat session was staying in idle state. | |
|
cse_ |
The maximum time (in seconds) a chat session was staying in dormant state. | |
|
_ |
The Tenant DBID. | 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. | CALLBACK_ |
|
_ |
Indicates whether this is a final record about this callback service: 0 = No, 1 = Yes. | 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_ |
|
_ |
The value of EWT, in seconds, at the time the callback was offered. | 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_ |
|
_ |
The customer position in the queue when callback was offered. | CALLBACK_ |
|
_ |
The duration of the callback offer, in seconds. | CALLBACK_ |
|
_ |
The amount of time, in seconds, the customer was waiting offline for an agent to become available. | 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 to be connected to the agent after the callback interaction was established. | CALLBACK_ |
|
_ |
The UTC timestamp when the callback offer was accepted. | CALLBACK_ |
|
_ |
The UTC timestamp when the callback was offered. | 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. | CALLBACK_ |
|
_ |
The UTC timestamp when the customer was reconnected to the contact center and started waiting for an agent to be connected. | CALLBACK_ |
|
_ |
Indicates whether the agent was successfully added to the callback interaction: 0 = No, 1 = Yes. | CALLBACK_ |
|
_ |
Number of times the callback interaction failed to transfer to the agent. | 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 customer was disconnected because the timeout for waiting for an agent was reached: 0 = No, 1 = Yes. | CALLBACK_ |
|
_ |
Indicates whether the interaction required agent assistance: 0 = No, 1 = Yes. | CALLBACK_ |
|
_ |
Indicates whether callback was offered, at least once, during the session: 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_ |
|
_ |
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. | 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_ |
|
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_ |
|
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_ |
|
_ |
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 interaction channel from which the callback originated. One of the following 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 type of callback the customer requested. 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:
|
CALLBACK_ |
|
_ |
The direction of the final callback interaction. One of the following values:
|
CALLBACK_ |
|
_ |
The result of the final callback dialing attempt. One of the following values:
Note: 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_ |
|
_ |
Specifies whether the callback offer was made during operational (business) or non-operational hours. One of the following values:
|
CALLBACK_ |
|
_ |
The routing target that was used to find the agent. | CALLBACK_ |
|
_ |
The Tenant DBID. | 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. | CALLBACK_ |
|
_ |
Indicates whether this is a final record about this callback service: 0 = No, 1 = Yes. | 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_ |
|
_ |
The value of EWT, in seconds, at the time the callback was offered. | 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_ |
|
_ |
The customer position in the queue when callback was offered. | CALLBACK_ |
|
_ |
The duration of the callback offer, in seconds. | CALLBACK_ |
|
_ |
The amount of time, in seconds, the customer was waiting offline for an agent to become available. | 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 to be connected to the agent after the callback interaction was established. | CALLBACK_ |
|
_ |
The UTC timestamp when the callback offer was accepted. | CALLBACK_ |
|
_ |
The UTC timestamp when the callback was offered. | 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. | CALLBACK_ |
|
_ |
The UTC timestamp when the customer was reconnected to the contact center and started waiting for an agent to be connected. | CALLBACK_ |
|
_ |
Indicates whether the agent was successfully added to the callback interaction: 0 = No, 1 = Yes. | CALLBACK_ |
|
_ |
Number of times the callback interaction failed to transfer to the agent. | 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 customer was disconnected because the timeout for waiting for an agent was reached: 0 = No, 1 = Yes. | CALLBACK_ |
|
_ |
Indicates whether the interaction required agent assistance: 0 = No, 1 = Yes. | CALLBACK_ |
|
_ |
Indicates whether callback was offered, at least once, during the session: 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_ |
|
_ |
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. | 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_ |
|
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_ |
|
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_ |
|
_ |
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 interaction channel from which the callback originated. One of the following 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 type of callback the customer requested. 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:
|
CALLBACK_ |
|
_ |
The direction of the final callback interaction. One of the following values:
|
CALLBACK_ |
|
_ |
The result of the final callback dialing attempt. One of the following values:
Note: 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_ |
|
_ |
Specifies whether the callback offer was made during operational (business) or non-operational hours. One of the following values:
|
CALLBACK_ |
|
_ |
The routing target that was used to find the agent. | CALLBACK_ |
|
_ |
The Tenant DBID. | CALLBACK_ |
|
_ |
Callback state using the format <state>.<sub state> where:
|
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. | CALLBACK_ |
|
_ |
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_ |
|
_ |
The call ID of the first outbound call that the callback service created. | CALLBACK_ |
|
_ |
The call ID of the last outbound call that the callback service created. | CALLBACK_ |
|
_ |
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_ |
|
_ |
The result of the second callback dialing attempt. See _CB_DIAL_1_RESULT for possible values. | CALLBACK_ |
|
_ |
The result of the third callback dialing attempt. See _CB_DIAL_1_RESULT for possible values. | CALLBACK_ |
|
_ |
The result of the fourth callback dialing attempt. See _CB_DIAL_1_RESULT for possible values. | CALLBACK_ |
|
_ |
The result of the fifth callback dialing attempt. See _CB_DIAL_1_RESULT for possible values. | CALLBACK_ |
|
_ |
UTC Timestamp of the first dialing attempt. | CALLBACK_ |
|
_ |
UTC Timestamp of the second dialing attempt. | CALLBACK_ |
|
_ |
UTC Timestamp of the third dialing attempt. | CALLBACK_ |
|
_ |
UTC Timestamp of the fourth dialing attempt. | CALLBACK_ |
|
_ |
UTC Timestamp of the fifth dialing attempt. | CALLBACK_ |
|
_ |
For premise callback, _CB_IXN_START_IGNORING_AVAILABILITY will always be 0. | CALLBACK_ |
|
_ |
Indicates whether this is a final record about this callback service: 0 = No, 1 = Yes. | 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_ |
|
_ |
The value of EWT, in seconds, at the time the callback was offered. | 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_ |
|
_ |
The customer position in the queue when callback was offered. | CALLBACK_ |
|
_ |
The duration of the callback offer, in seconds. | CALLBACK_ |
|
_ |
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_ |
|
_ |
Indicates whether the caller dropped the call without explicitly accepting or rejecting the callback offer: 0 = No, 1 = Yes. | CALLBACK_ |
|
_ |
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_ |
|
_ |
UTC timestamp for when service was completed or terminated. | CALLBACK_ |
|
_ |
The amount of time, in seconds, the customer waited in the queue before a callback was offered. | CALLBACK_ |
|
_ |
The amount of time, in seconds, the customer was waiting offline for an agent to become available. | 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 to be connected to the agent after the callback interaction was established. | CALLBACK_ |
|
_ |
The UTC timestamp when the callback offer was accepted. | CALLBACK_ |
|
_ |
The UTC timestamp when the callback was offered. | 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_ |
|
_ |
The UTC timestamp when the customer was reconnected to the contact center and started waiting for an agent to be connected. | CALLBACK_ |
|
_ |
Indicates whether the agent was successfully added to the callback interaction: 0 = No, 1 = Yes. | CALLBACK_ |
|
_ |
Number of times the callback interaction failed to transfer to the agent. | 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 customer was disconnected because the timeout for waiting for an agent was reached: 0 = No, 1 = Yes. | CALLBACK_ |
|
_ |
Indicates whether the interaction required agent assistance: 0 = No, 1 = Yes. | CALLBACK_ |
|
_ |
Indicates whether callback was offered, at least once, during the session: 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_ |
|
_ |
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. | 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_ |
|
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_ |
|
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_ |
|
_ |
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 interaction channel from which the callback originated. One of the following 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 type of callback the customer requested. 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 direction of the final callback interaction. One of the following values:
|
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_ |
|
_ |
Specifies whether the callback offer was made during operational (business) or non-operational hours. One of the following values:
|
CALLBACK_ |
|
_ |
The routing target that was used to find the agent. | CALLBACK_ |
|
_ |
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_ |
|
_ |
Estimated Wait Time in seconds when the last dial attempt was made or the last push notification sent. | CALLBACK_ |
|
_ |
Position in queue when the last dial attempt was made or the last push notification sent. | CALLBACK_ |
|
_ |
Priority of the interaction (real or virtual) when the callback offer was accepted. | CALLBACK_ |
|
_ |
Priority of the virtual interaction when the customer was connected. | CALLBACK_ |
|
_ |
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_ |
|
_ |
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 Tenant DBID. | CALLBACK_ |
|
_ |
Callback state using the format <state>.<sub state> where:
|
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. | CALLBACK_ |
|
_ |
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_ |
|
_ |
The call ID of the first outbound call that the callback service created. | CALLBACK_ |
|
_ |
The call ID of the last outbound call that the callback service created. | CALLBACK_ |
|
_ |
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_ |
|
_ |
The result of the second callback dialing attempt. See _CB_DIAL_1_RESULT for possible values. | CALLBACK_ |
|
_ |
The result of the third callback dialing attempt. See _CB_DIAL_1_RESULT for possible values. | CALLBACK_ |
|
_ |
The result of the fourth callback dialing attempt. See _CB_DIAL_1_RESULT for possible values. | CALLBACK_ |
|
_ |
The result of the fifth callback dialing attempt. See _CB_DIAL_1_RESULT for possible values. | CALLBACK_ |
|
_ |
UTC Timestamp of the first dialing attempt. | CALLBACK_ |
|
_ |
UTC Timestamp of the second dialing attempt. | CALLBACK_ |
|
_ |
UTC Timestamp of the third dialing attempt. | CALLBACK_ |
|
_ |
UTC Timestamp of the fourth dialing attempt. | CALLBACK_ |
|
_ |
UTC Timestamp of the fifth dialing attempt. | CALLBACK_ |
|
_ |
For premise callback, _CB_IXN_START_IGNORING_AVAILABILITY will always be 0. | CALLBACK_ |
|
_ |
Indicates whether this is a final record about this callback service: 0 = No, 1 = Yes. | 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_ |
|
_ |
The value of EWT, in seconds, at the time the callback was offered. | 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_ |
|
_ |
The customer position in the queue when callback was offered. | CALLBACK_ |
|
_ |
The duration of the callback offer, in seconds. | CALLBACK_ |
|
_ |
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_ |
|
_ |
Indicates whether the caller dropped the call without explicitly accepting or rejecting the callback offer: 0 = No, 1 = Yes. | CALLBACK_ |
|
_ |
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_ |
|
_ |
UTC timestamp for when service was completed or terminated. | CALLBACK_ |
|
_ |
The amount of time, in seconds, the customer waited in the queue before a callback was offered. | CALLBACK_ |
|
_ |
The amount of time, in seconds, the customer was waiting offline for an agent to become available. | 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 to be connected to the agent after the callback interaction was established. | CALLBACK_ |
|
_ |
The UTC timestamp when the callback offer was accepted. | CALLBACK_ |
|
_ |
The UTC timestamp when the callback was offered. | 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_ |
|
_ |
The UTC timestamp when the customer was reconnected to the contact center and started waiting for an agent to be connected. | CALLBACK_ |
|
_ |
Indicates whether the agent was successfully added to the callback interaction: 0 = No, 1 = Yes. | CALLBACK_ |
|
_ |
Number of times the callback interaction failed to transfer to the agent. | 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 customer was disconnected because the timeout for waiting for an agent was reached: 0 = No, 1 = Yes. | CALLBACK_ |
|
_ |
Indicates whether the interaction required agent assistance: 0 = No, 1 = Yes. | CALLBACK_ |
|
_ |
Indicates whether callback was offered, at least once, during the session: 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_ |
|
_ |
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. | 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_ |
|
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_ |
|
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_ |
|
_ |
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 interaction channel from which the callback originated. One of the following 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 type of callback the customer requested. 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 direction of the final callback interaction. One of the following values:
|
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_ |
|
_ |
Specifies whether the callback offer was made during operational (business) or non-operational hours. One of the following values:
|
CALLBACK_ |
|
_ |
The routing target that was used to find the agent. | CALLBACK_ |
|
_ |
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_ |
|
_ |
Estimated Wait Time in seconds when the last dial attempt was made or the last push notification sent. | CALLBACK_ |
|
_ |
Position in queue when the last dial attempt was made or the last push notification sent. | CALLBACK_ |
|
_ |
Priority of the interaction (real or virtual) when the callback offer was accepted. | CALLBACK_ |
|
_ |
Priority of the virtual interaction when the customer was connected. | CALLBACK_ |
|
_ |
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_ |
|
_ |
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_ |
|
gpmAgentDBID |
Optional. The DBID of the agent to whom the interaction was routed. | RESOURCE_ |
|
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. | GPM_ |
|
gpmMode |
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. | GPM_ |
|
gpmStatus |
Indicates the scenario under which the interaction was processed. For more information about the scenarios, see Routing Scenarios Using Predictive Routing. | 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:
|
GPM_ |
|
gpmResult |
The result of Predictive Routing processing. If there is an error, the gpmMessage KVP contains the error message.
|
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. | 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. | GPM_ |
|
gpmPredictorId |
The UUID of the Predictor used for scoring. | GPM_ |
|
gpmModel |
The name of the Model used to calculate agent scores for the interaction. | GPM_ |
|
gpmModelId |
The UUID of the Model used to calculate agent scores for the interaction. | GPM_ |
|
gpmMessage |
The message that displays when the Predictive Routing result reported in the gpmResult KVP is an error. | GPM_ |
|
gpmAgentScore |
The score of the agent to whom the interaction was routed. | GPM_ |
|
gpmGlobalScore |
The mean score calculated for an interaction using the Global Model. | GPM_ |
|
gpmMedianScore |
The median score for the target group of agents to which the agent who received the interaction belongs. | GPM_ |
|
gpmMaxScore |
The score of the best-matching agent in the target group. | GPM_ |
|
gpmMinScore |
The score of the worst-matching agent in the target group. | GPM_ |
|
gpmScoreAboveMedian |
Indicates whether the score for the selected agent was better than the median score for the target group. | GPM_ |
|
gpmAgentRank |
The rank of the agents in the target group, based on agent scores sorted in descending order. | GPM_ |
|
gpmTargetSize |
The size of the scored target group (in other words, the length of the list of agents received from the scoring engine). | 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. | GPM_ |
|
CALLID |
Value of AttributeCallUUID for the interaction. | GPM_ |
|
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. |
GPM_ |
|
ADDED_ |
UTC timestamp, indicating the date and time when the record was added as inherited from the T-Server TEvent. | GPM_ |
|
gpmDefaultAgentScore |
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. | GPM_ |
|
gpmDefaultScoreUsed |
*0 - The agent score for the associated interaction is taken from the scoring response returned by GPR.
|
GPM_ |
|
gpmDefaultScoredAgents |
The number of agents assigned the default score for the associated interaction. | GPM_ |
|
gpmGlobalScoreCount |
Describes the number of agent scores returned for an interaction using a GLOBAL model. | GPM_ |
|
gpmAdjustedAgentScore |
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. | GPM_ |
|
gpmInitialScoreThreshold |
The initial threshold value used for the interaction, taken from the value set in the score-base-threshold configuration option. | GPM_ |
|
gpmFinalScoreThreshold |
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. | GPM_ |
|
gpmSuitableAgentsCount |
The number of agents who had scores greater than or equal to the initial threshold value when the scoring response was received. | GPM_ |
|
gpmPredictorType |
Reserved for future use. | GPM_ |
|
gpmRoutingMethod |
Reserved for future use. | GPM_ |
|
gpmVQDBID |
The DBID of the virtual queue or DN configured in the vq-for-reporting configuration option (configured on the Predictive_Route_DataCfgTransaction List object).
|
RESOURCE_ |
|
gpmVQGUID |
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.
|
GPM_ |
|
CustomerID |
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. | IRF_ |
|
ServiceType |
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. | INTERACTION_ |
|
gpmPriorityIncrement |
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. |
N/A |
|
gpmAgentDBID |
Optional. The DBID of the agent to whom the interaction was routed. | RESOURCE_ |
|
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. | GPM_ |
|
gpmMode |
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. | GPM_ |
|
gpmStatus |
Indicates the scenario under which the interaction was processed. For more information about the scenarios, see Routing Scenarios Using Predictive Routing. | 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:
|
GPM_ |
|
gpmResult |
The result of Predictive Routing processing. If there is an error, the gpmMessage KVP contains the error message.
|
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. | 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. | GPM_ |
|
gpmPredictorId |
The UUID of the Predictor used for scoring. | GPM_ |
|
gpmModel |
The name of the Model used to calculate agent scores for the interaction. | GPM_ |
|
gpmModelId |
The UUID of the Model used to calculate agent scores for the interaction. | GPM_ |
|
gpmMessage |
The message that displays when the Predictive Routing result reported in the gpmResult KVP is an error. | GPM_ |
|
gpmAgentScore |
The score of the agent to whom the interaction was routed. | GPM_ |
|
gpmGlobalScore |
The mean score calculated for an interaction using the Global Model. | GPM_ |
|
gpmMedianScore |
The median score for the target group of agents to which the agent who received the interaction belongs. | GPM_ |
|
gpmMaxScore |
The score of the best-matching agent in the target group. | GPM_ |
|
gpmMinScore |
The score of the worst-matching agent in the target group. | GPM_ |
|
gpmScoreAboveMedian |
Indicates whether the score for the selected agent was better than the median score for the target group. | GPM_ |
|
gpmAgentRank |
The rank of the agents in the target group, based on agent scores sorted in descending order. | GPM_ |
|
gpmTargetSize |
The size of the scored target group (in other words, the length of the list of agents received from the scoring engine). | 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. | GPM_ |
|
CALLID |
Value of AttributeCallUUID for the interaction. | GPM_ |
|
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. |
GPM_ |
|
ADDED_ |
UTC timestamp, indicating the date and time when the record was added as inherited from the T-Server TEvent. | GPM_ |
|
gpmDefaultAgentScore |
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. | GPM_ |
|
gpmDefaultScoreUsed |
*0 - The agent score for the associated interaction is taken from the scoring response returned by GPR.
|
GPM_ |
|
gpmDefaultScoredAgents |
The number of agents assigned the default score for the associated interaction. | GPM_ |
|
gpmGlobalScoreCount |
Describes the number of agent scores returned for an interaction using a GLOBAL model. | GPM_ |
|
gpmAdjustedAgentScore |
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. | GPM_ |
|
gpmInitialScoreThreshold |
The initial threshold value used for the interaction, taken from the value set in the score-base-threshold configuration option. | GPM_ |
|
gpmFinalScoreThreshold |
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. | GPM_ |
|
gpmSuitableAgentsCount |
The number of agents who had scores greater than or equal to the initial threshold value when the scoring response was received. | GPM_ |
|
gpmPredictorType |
Reserved for future use. | GPM_ |
|
gpmRoutingMethod |
Reserved for future use. | GPM_ |
|
gpmVQDBID |
The DBID of the virtual queue or DN configured in the vq-for-reporting configuration option (configured on the Predictive_Route_DataCfgTransaction List object).
|
RESOURCE_ |
|
gpmVQGUID |
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.
|
GPM_ |
|
CustomerID |
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. | IRF_ |
|
ServiceType |
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. | INTERACTION_ |
|
gpmPriorityIncrement |
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. |
N/A |
*This KVP must be sent twice -- as call-based attached data in a TEvent and as UserEvent-based user data.