Conversation aggregates API call

[Julian_Alejandro_Vil]

Hi,

I'm currently using this endpoint from the API /api/v2/analytics/conversations/aggregates/query but i wanted to check if this query only pulls interactions that have finished in the particular interval or if this has as well living interactions (is there a way to filter them out via the query body?).

Also i want to understand what would happen in this scenario:

• Query 1: from 02/02/2023 10:00am - 02/02/2023 10:30 am Where there is a live interaction ocurring, and has not ended within the timeframe. Would this appear in the results? Would it have metrics associated?

• Query 2: from 02/02/2023 10:30am - 02/02/2023 11:00 am Where the previous interaction is live but ends within the timeframe. Would this appear in the results as the whole call or only the part that ocurred within the timeframe? Would it have aggregated metrics associated?

I want to make sure that i am not double counting the interactions as well as biasing the metrics with the API calls.

Thanks a lot in advance!

[SimonBrown]

Not looking at 2 queries in particular but you can include in the query a predicate for conversationEnd existing.
That way you will only pull completed conversations in you interval. (They may have started in earlier interval though)

Snippet in query looks like

"predicates": [
  {
    "type": "property",
    "operator": "exists",
    "value": "conversationEnd"

Done away from PC but I think that is correct.

[Julian_Alejandro_Vil]

@Julian_Alejandro_Vil

/api/v2/analytics/conversations/aggregates/query

Hi Simon,

I'm not sure this is working for this specific endpoint /api/v2/analytics/conversations/aggregates/query

[Eos_Rios]

The conversation start and stop have nothing to do with the interval parameter of /api/v2/analytics/conversations/aggregates/query

Metrics have their own individual timestamps within the boundaries of the conversation and those are what the interval pertain to.

Each metric has it's own emittance schedule.
tHandle for example emits when the handling is done.
tAnswered emits when the call was actually answered.
In the general the n prefixed metrics post in real time and the t prefixed metrics post when whatever they've measured completes, which may or may not be related to the end of the call.

So whether the call is still ongoing or not, any metric that occurred within the conditions you supplied will be picked up by the API.

This is often a source of confusion so a visual may help. Take Talk Time; if you aggregate into 30 minute intervals and the calls start/stop at the times listed.

Interval	Call 1	Call 2		Expectation	Reality
9:00 AM		09:16		14 minutes	0 minutes
9:30 AM	09:35	09:32		27 minutes	16 minutes
10:00 AM	10:05			5 minutes	30 minutes

9 am has 0, because the call didn't end yet, it's talk time hasn't posted. When it ends at 9:32 the entire 16 minutes of talk posts to the 9:30 interval.
They both reach the conclusion of 46 minutes but not necessarily when/where expected.

Likewise, no portion of call 1 is present in the 9:30 interval even though 25 minutes of it happened there, because it ended at 10:05 so the full 30 minutes posted in the 10 am interval.

If a rep is on a 2 hour call when that call hangs up all 2 hours post to the interval it ended, even if the interval is only 30 minutes long.

Example metrics from an agent on a single call;

				"metrics": [
					{
						"emitDate": "2023-02-21T00:59:18.555Z",
						"name": "tAlert",
						"value": 57
					},
					{
						"emitDate": "2023-02-21T00:59:18.555Z",
						"name": "tAnswered",
						"value": 397
					},
					{
						"emitDate": "2023-02-21T01:13:09.778Z",
						"name": "nConsult",
						"value": 1
					},
					{
						"emitDate": "2023-02-21T01:22:42.519Z",
						"name": "tTalk",
						"value": 1403964
					},
					{
						"emitDate": "2023-02-21T01:22:42.519Z",
						"name": "tTalkComplete",
						"value": 1403964
					},
					{
						"emitDate": "2023-02-21T01:22:45.519Z",
						"name": "tAcw",
						"value": 3000
					},
					{
						"emitDate": "2023-02-21T01:22:45.519Z",
						"name": "tHandle",
						"value": 1406964
					}
				],

[ralegner]

@Eos_Rios covered this quite well and I agree with the write up. The concepts section in the developer docs helps explain how metrics show up in certain intervals and why. https://developer.genesys.cloud/analyticsdatamanagement/analytics/metrics#concepts

The main concept to understand is that metrics will show up in the interval where they are calculated. Metrics are calculated in realtime where when all qualifying activities for the given metric have ended, it will emit and show up in that interval. For example, tACD will wait for the ACD segment to end and emit once that event happens. If you want an overview to get a feel for when a particular metric emits, the detail record for a conversation notes the emitDate time stamp which will tell you what interval that metric will land in.

There is no existing metric around conversation end time, all metrics are calculated based on session activity so conversation start/end is not relevant to metrics.