anil.kumar | 2017-02-05 22:53:25 UTC | #1
We are trying to get the aggregates for the 30 minute intervals by adding the granularity as 30 minutes in the aggregate query. However, there seems to be a difference in the data that is obtained with the 30 min granularity and the default granularity that our reporting team has reported. Could you please help us understand how the granularity works and if there is any difference in the data retrieved with and without granularity levels in the request.
This is the data that we have got with default granularity. The data is for 23rd January and it is the data for the duration of 1 day.
Talk : 1620715 Held: 289255 ACW: 405653 Handling Time : 2315623
Here is the data that is obtained with the granularity of 30 minutes for the same duration as above. All the data obtained for 30 minutes interval have been summed up here.
Talk: 1620439 Held :289094 ACW :405653 Handling Time : 2315186
The difference is always with the Talk and Held durations.
I am using the aggregate conversation query through the Java API - api.postConversationsAggregatesQuery(query).
For the both the queries mentioned in my ticket, there is a predicate list "match userId" and there is a list of all user ids here and we are grouping by UserId and QueueId
The only difference in the query is the granularity for the results posted above. The second query has "granularity": "PT30M" which gives us the results for every 30 minutes interval.
Thanks in advance
tim.smith | 2017-02-03 14:48:12 UTC | #2
Can you post the JSON query bodies you're using for the requests?
anil.kumar | 2017-02-06 15:47:30 UTC | #3
Here is the query with granularity null (default).. The query is actually huge as we are matching every userId in the predicate. I have cut down those predicates so that I can post it here.
AggregationQuery {
interval: 2017-02-02T13:00:00.000Z/2017-02-03T12:59:00.000Z
granularity: null
timeZone: null
groupBy: [userId, queueId]
filter: class AnalyticsQueryFilter {
type: or
clauses: [class AnalyticsQueryClause {
type: or
predicates: [class AnalyticsQueryPredicate {
type: dimension
dimension: userId
propertyType: null
property: null
metric: null
operator: matches
value: 9034d377-e244-4b37-929b-f5cc49c98e81
range: null
}, class AnalyticsQueryPredicate {
type: dimension
dimension: userId
propertyType: null
property: null
metric: null
operator: matches
value: 59bfbbc5-a7e6-4e27-969a-fadc0f04561d
range: null
}, class AnalyticsQueryPredicate {
type: dimension
dimension: userId
propertyType: null
property: null
metric: null
operator: matches
value: 686aef9b-c059-4a78-a793-d900d68655cd
range: null
}, class AnalyticsQueryPredicate {
type: dimension
dimension: userId
propertyType: null
property: null
metric: null
operator: matches
value: d6f94c60-70b4-4278-8814-fed5c8930452
range: null
}]
}]
predicates: []
}
metrics: []
flattenMultivaluedDimensions: true
}
anil.kumar | 2017-02-06 15:47:20 UTC | #4
This is the second query with granularity of PT30M. which gives aggregates for 30 minutes interval.
AggregationQuery {
interval: 2017-02-02T13:00:00.000Z/2017-02-03T12:59:00.000Z
granularity: PT30M
timeZone: null
groupBy: [userId, queueId]
filter: class AnalyticsQueryFilter {
type: or
clauses: [class AnalyticsQueryClause {
type: or
predicates: [class AnalyticsQueryPredicate {
type: dimension
dimension: userId
propertyType: null
property: null
metric: null
operator: matches
value: 9034d377-e244-4b37-929b-f5cc49c98e81
range: null
}, class AnalyticsQueryPredicate {
type: dimension
dimension: userId
propertyType: null
property: null
metric: null
operator: matches
value: 59bfbbc5-a7e6-4e27-969a-fadc0f04561d
range: null
}, class AnalyticsQueryPredicate {
type: dimension
dimension: userId
propertyType: null
property: null
metric: null
operator: matches
value: 686aef9b-c059-4a78-a793-d900d68655cd
range: null
}, class AnalyticsQueryPredicate {
type: dimension
dimension: userId
propertyType: null
property: null
metric: null
operator: matches
value: d6f94c60-70b4-4278-8814-fed5c8930452
range: null
}]
}]
predicates: []
}
metrics: []
flattenMultivaluedDimensions: true
}
anil.kumar | 2017-02-05 23:00:11 UTC | #5
I have taken both the queries from the logs, as the queries are being built using the purecloud Java API.
tim.smith | 2017-02-06 17:11:24 UTC | #6
I've been able to reproduce this issue and have logged AR-4945 for it.
anil.kumar | 2017-02-06 22:38:25 UTC | #7
Thanks Tim. Is there any expected date for this defect to be fixed ? Were you able to find whether this is an issue with the Java API or the query itself ? Where can I access AR-4945 ?
tim.smith | 2017-02-06 22:45:54 UTC | #8
Is there any expected date for this defect to be fixed ?
The ticket has been put into their work queue, but has not been fully triaged or prioritized. There isn't an ETA yet.
Were you able to find whether this is an issue with the Java API or the query itself ?
I assume you're referring to the Java SDK. The issue is in the backend PureCloud analytics service and is unrelated to any SDK.
Where can I access AR-4945 ?
The details of issues are not publicly available. The issue number is provided only for reference purposes to indicate that this thread is related to the issue or for working with PureCloud Support.
anil.kumar | 2017-02-06 22:57:14 UTC | #9
Thanks for the information Tim. If you get any updates on this issue, can you please post it here please ?
system | 2017-08-28 19:31:52 UTC | #10
This post was migrated from the old Developer Forum.
ref: 883