Legacy Dev Forum Posts

matthew | 2016-08-09 19:28:00 UTC | #1

Hi ,

I'm issuing the following query ;

{
  "interval": "2016-07-01T00:00:00/2016-08-01T00:00:00",
  "granularity": "PT1H",
  "groupBy": [
    "userId"
  ],
  "filter": {
    "type": "and",
    "clauses": [
      {
        "type": "or",
        "predicates": [
          {
            "type": "dimension",
            "dimension": "userId",
            "value": "bb869599-97ea-4f14-956e-443de1722b01"
          }
        ]
      }
    ]
  },
  "flattenMultivaluedDimensions": false
}

I get a selection of metrics back for this user including nError, tHandle, tTalkComplete, tTalk, tHandle,oInteracting, tAcw, tTalkComplete.

But other metrics like nOffered, tAbandon,tWait,Noversla,nTransferred are not there.

I thought that if the metrics is omitted then its like a select * and all metrics should be returned :

https://developer.mypurecloud.com/api/rest/v2/analytics/index.html

metrics (array, optional): Behaves like a SQL SELECT clause. Enables retrieving only named metrics. If omitted, all metrics that are available will be returned (like SELECT *)

So where are my missing metrics?

please help!

tim.smith | 2016-08-09 19:27:39 UTC | #2

The bolded part is key:

If omitted, all metrics that are available will be returned (like SELECT *)

If a metric doesn't have data, you won't get it.

matthew | 2016-08-09 20:07:14 UTC | #3

ok thanks - so for metrics like tAbandon, nTransfered that are not returned do we assume that they are 0?

Also Is the nOffered metric actually applicable to a user? or is that just for queues?

tim.smith | 2016-08-09 20:29:05 UTC | #4

so for metrics like tAbandon, nTransfered that are not returned do we assume that they are 0?

No, because 0 is a value. :) It should be handled like a null value. It's a slight technical nuance, but may make a difference in your calculations or how you display the stats.

Also Is the nOffered metric actually applicable to a user? or is that just for queues?

I checked with the analytics team and the only metrics valid for user aggregate queries are tSystemPresence, tOrganizationPresence, and tAgentRoutingStatus. There are some pages that accidentally got deleted from the analytics section. I'm working to get those back into the site today.

matthew | 2016-08-10 11:32:23 UTC | #5

OK, so are you saying the metrics that do come back like nError, tHandle, tTalkComplete, tTalk, tHandle,oInteracting, tAcw, tTalkComplete are not valid? Bit confused now, since they seemed to be correct and working.

We are using the analytics api conversationaggregates query by the way.

anon47305574 | 2016-08-10 18:59:07 UTC | #6

As Tim had mentioned, some metrics are only applicable in the context of user aggregate data. Specifically, the user aggregate endpoint which focuses on what people intended to do as well as what they actually did (metrics include tSystemPresence, tOrganizationPresence, and tAgentRoutingStatus): https://developer.mypurecloud.com/api/rest/v2/analytics/user.html

To your last question, no, nothing invalid. To a few of the questions you posed earlier:

For conversation aggregate data, as you have observed, the story can be more complex. As Tim had alluded to, metrics can be omitted from the output because they would otherwise represent something that did not happen during the time interval you're querying for and assuming a value of zero can have some implications. For example, if no callers abandoned today, saying time-to-abandon=0 could imply that some calls abandoned instantaneously (and if included in larger aggregates, they would skew the averages down artificially). Assuming zero for some of the values which are counters would be less impactful, but in general, from our perspective, if it didn't happen, we don't want to imply otherwise.

Additionally, some of the metrics, while a descriptor for something that happened in the conversation, are specifically dimensioned on certain attributes. nOffered, for example, is a count specifically of the number of interactions offered to a queue and not to an individual user, so if the filter/groupby in your query is targeting users and not queues, you won't see queue-only-dimensioned metrics present. nOverSLA is another such queue-only metric (the rationale there being that an interaction could be sitting in queue for a very long time and the user who happened to take that interaction should not be penalized for ultimately taking that one from the queue).

Metrics like tAnswered however pertain to both the queue the interaction came in on as well as the user who took the interaction, so both dimensions would be a point of entry to that data (e.g. if you filtered by queueId and/or userId).

I hope this helps

matthew | 2016-08-12 11:53:15 UTC | #7

yes that helps a lot.

thanks very much.

system | 2017-08-28 19:26:19 UTC | #8

This post was migrated from the old Developer Forum.

ref: 276