User aggregate query qualifier ON_QUEUE definition

1

Hello

We're using following query : https://developer.mypurecloud.com/api/rest/v2/analytics/user_aggregate.html

we looking at following qualifiers :

  1. tOrganizationPresence contains following qualifiers:
  2. AVAILABLE
  3. BUSY
  4. BREAK
  5. ON_QUEUE
  6. OFFLINE
  7. tAgentRoutingStatus contains following qualifiers:
  8. INTERACTING
  9. NOT_RESPONDING
  10. IDLE

We have following assumption
ON_QUEUE = (INTERACTING + NOT_RESPONDING + IDLE )
but the numbers don't seem to add exactly up

Are we using the wrong assumption - are there other qualifiers we should consider in our formula? Is it because there is maybe tagentroutingstatus values in previous or next interval ?

Tx Renaud

2

User Aggregate generates pre-calculated results, so what you are checking the values against when you state "the numbers don't seem to add exactly up"? Are you comparing against values from the User Status Detail Report?

3

tx for response
we take values for INTERACTING/NOT_RESPONDING/IDLE AND ON QUEUE in the same result txt file
Yet the ON_QUEUE is not exactly equal to the sum of the 3 other qualifiers

On queue value is 23678248 while sum of the 3 other qualifiers is 23690421

Below the result table from a single user aggregate query

Column1.interval Column1.metrics.metric Column1.metrics.qualifier Column1.metrics.stats.sum Column1
2019-12-14T00:00:00.000Z/2019-12-14T23:59:59.000Z tAgentRoutingStatus INTERACTING 20624787
2019-12-14T00:00:00.000Z/2019-12-14T23:59:59.000Z tAgentRoutingStatus NOT_RESPONDING 17418
2019-12-14T00:00:00.000Z/2019-12-14T23:59:59.000Z tAgentRoutingStatus IDLE 3048216
2019-12-14T00:00:00.000Z/2019-12-14T23:59:59.000Z tOrganizationPresence ON_QUEUE 23678248 23690421
2019-12-14T00:00:00.000Z/2019-12-14T23:59:59.000Z tOrganizationPresence 03af8d19-653f-45f7-97db-803bf86bde50 3310054
2019-12-14T00:00:00.000Z/2019-12-14T23:59:59.000Z tOrganizationPresence 227b37e2-f1d0-4dd0-8f50-badd7cf6d158 4296171
2019-12-14T00:00:00.000Z/2019-12-14T23:59:59.000Z tOrganizationPresence 6a3af858-942f-489d-9700-5f9bcdcdae9b 610552
2019-12-14T00:00:00.000Z/2019-12-14T23:59:59.000Z tOrganizationPresence ccf3c10a-aa2c-4845-8e8d-f59fa48c58e5 54503975
4

I can see why you would think that ON_QUEUE = (INTERACTING + NOT_RESPONDING + IDLE ), but that is actually an incorrect assumption. ON_QUEUE is a presence status and the others are routing statuses and they are tracked separately, so the times will be close but will never add up exactly the same.

For instance I subscribed to the "v2.users.{id}.activity" event and I received this where "IDLE" is my routing status and "ON_QUEUE" is my presence:

{
"id": "1c1ca8b5-8740-481e-92f5-cf23870284bd",
"routingStatus": {
"status": "IDLE",
"startTime": "2019-12-31T15:28:09.980Z"
},
"presence": {
"presenceDefinition": {
"id": "e08eaf1b-ee47-4fa9-a231-1200e284798f",
"systemPresence": "ON_QUEUE"
},
"presenceMessage": "PureCloud World Domination",
"modifiedDate": "2019-12-31T15:01:33.319Z"
},
"outOfOffice": {},
"activeQueueIds": [
"162d472f-adc3-4cdd-8222-98379ee38390"
],
"dateActiveQueuesChanged": "2019-08-15T19:32:50.765Z"
}

As a side note... You are using tOrganizationPresence and you may want to use tSystemPresence to factor in any custom statuses.

5

tx - that makes sense

6

This topic was automatically closed 31 days after the last reply. New replies are no longer allowed.