Conversation Aggregate Query - Data discrepancy with granularity

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

Can you post the JSON query bodies you're using for the requests?

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
}

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
}

I have taken both the queries from the logs, as the queries are being built using the purecloud Java API.

I've been able to reproduce this issue and have logged AR-4945 for it.

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 ?

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.

Thanks for the information Tim.
If you get any updates on this issue, can you please post it here please ?

1 Like