Aggregate API(/api/v2/analytics/conversations/aggregates/query) data change with time span

[smishra]

Hi All,

We're working with the API convesation query aggregate.
https://api.mypurecloud.com/api/v2/analytics/conversations/aggregates/query for accumulating data on half hourly basis, 5 minutes past the interval.
We have encountered that the data from the API don't match with the reports on Genesys UI. If we hit the API 2 -3 hours later, we see the data starts matching.
Does Genesys API reconcile data post conversation is closed and keep on reconciliation for past intervals?

What is the best practice to sync data from these API to be sure that we have the latest data from the API.

Based on Metrics (genesys.cloud)

If a call ended in interval and the ACW is complete in the same interval say 10:00 10:30 , then I should have thandle in the same interval and then it should never get updated.

Hope to get some guidance from the community for this issue.

Thanks
Sanyog

[Eos_Rios]

What does your aggregate query look like?

[smishra]

Thanks for quick response.

Here is the sample query for one interval, we query every half an hour
{
"interval": "2024-03-25T15:30:59.999Z/2024-03-25T16:00:59.999Z",
"groupBy": [
"queueId"
"
],
"metrics": [
"NCONNECTED",
"NOFFERED",
"NOUTBOUND",
"NOUTBOUNDCONNECTED",
"NOVERSLA",
"TABANDON",
"TACD",
"TACW",
"TANSWERED",
"TFLOWOUT",
"THANDLE",
"THELD",
"TSHORTABANDON",
"TTALK",
"TWAIT"
],
"filter": {

    "type": "AND",
    "predicates": [
        {
            "dimension": "direction",
            "value": "inbound",
            "operator": "matches"
        }
    ]
}
    
}

[Eos_Rios]

Just be clear, are you also specifiying:

 "granularity": "PT30M",

Because that is the appropriate way to conform your data to static intervals that align with the UI

[smishra]

Thanks Eios, let me check adding this as of now I was not specifying the granularity.

[Eos_Rios]

You may want to adjust your interval to

2024-03-25T15:30:00.000Z/2024-03-25T16:00:00.000Z

Without granularity specified your interval was becoming your granularity.
With it specified it will conform to rounded chunks on the half hour boundary, for anything that falls within the specified range

Which means your current way you'd get 29 minutes of data in the 15:30 interval and 1 minute worth of the 16:00 interval, or an error that it couldn't evenly divide the time as specified. It can be weird about that.

[smishra]

Thanks, Eos, for the suggestion,
we have tested with modified query, but it has made no difference for us. The data only matched when we hit after 2-3 hours only, so while your suggestion is right thing to cover the boundary condition yet seems like there is something else also on Genesys side which keeps on data reconciliation the data post, we hit our original query.

[ralegner]

Sanyog,

One suggestion for troubleshooting is to gather a second query to group by conversationId so you can compare which conversations were not counted in the original query that later showed up in the second. Once you have that, take a look at the detail record to investigate the emitDate on the metrics you're focusing on. Sometimes that can uncover some uncommon call flows that might lead to explain what you're seeing. If that leads you to more questions, then you now have precise examples for support to help look into this further.

The realtime data stack doesn't have anything that specifically trigger metric calculations to happen 2-3 hours after the interval. Lag in processing events can sometimes lead to a bit of delay of a couple minutes depending on load at the time the metric was supposed to be calculated. With those examples in hand, support can help you dive into your issue further.

[smishra]

Thanks Relegner, let me dive into the details to find out which flows are the culprits, but don't you think the delays in the pipeline process to Analytics may delay the data by hours.

[ralegner]

Nightly maintenance doesn't look at conversations until they're > 48 hours at the time of processing. Pipeline wouldn't be your culprit if you see the issue after a couple hours.

[smishra]

Thanks for confirming

[Eos_Rios]

@smishra

The data only matched when we hit after 2-3 hours only,

That is quite curious, my own process that runs 4th minute of every half hour generally matches UI at run time with occassional one offs catching up the next cycle. Hopefully Ralegner's idea will help you pinpoint what may be happening.