Genesys Cloud - Developer Community!

Hi Joel,

For real-time queue metrics, you can subscribe to the Queue Observations notification topic:
v2.analytics.queues.{id}.observations

The notifications provide observation metrics for the queue. However, for the actual abandoned interaction count (nAbandon), I would recommend using the Analytics Conversation Aggregates API, since nAbandon is an aggregate metric rather than relying only on the real-time observation payload.

You could use the WebSocket notification to trigger/refresh your dashboard and query the aggregate endpoint for metrics such as nOffered, nConnected, and nAbandon.

There is also a useful overview of the Analytics APIs here:

https://developer.genesys.cloud/analyticsdatamanagement/analytics/aggregate/conversation/

https://developer.genesys.cloud/analyticsdatamanagement/analytics/extraction/

thank you for the response.

What is the name of the metric to use with v2.analytics.queues.{id}.observations to get the abandon count?

And what is the downside of using it vs using the Analytics Conversation Aggregates API?

Hi Joel,

For real-time queue metrics, you can subscribe to the Queue Observations notification topic:
v2.analytics.queues.{id}.observations

The notifications provide observation metrics for the queue. However, for the actual abandoned interaction count (nAbandon), I would recommend using the Analytics Conversation Aggregates API, since nAbandon is an aggregate metric rather than relying only on the real-time observation payload.

You could use the WebSocket notification to trigger/refresh your dashboard and query the aggregate endpoint for metrics such as nOffered, nConnected, and nAbandon.

There is also a useful overview of the Analytics APIs here:

https://developer.genesys.cloud/analyticsdatamanagement/analytics/aggregate/conversation/

https://developer.genesys.cloud/analyticsdatamanagement/analytics/extraction/

Good day, Joel,

I am not aware of a metric for abandoned interactions with that payload. 

My opinion on downsides of using Observations vs. Aggregates, others might have a different view.

Since observations only reflect current active states, I wouldn't build a live dashboard exclusively off the WebSocket stream; it introduces some real issues:

1. You have to guess the outcome. To track abandons via WebSocket, you'd need custom logic to watch for every drop in the oWaiting count. If it drops without a corresponding rise in oInteracting, you'd have to assume it was an abandon.
2. That guess is often wrong. If a caller opts out of the queue back to the IVR, or a system timeout routes them to voicemail, that's a flow-out, not an abandon. Custom logic built on the WebSocket stream will misclassify these as abandons every time. The Aggregates API sorts these into the right buckets natively, so you don't have to reverse-engineer the logic yourself.
3. You're exposed to desyncs. WebSockets are a live stream; if your connection drops for even a few seconds, or your client misses a payload, your running tally breaks and stays out of sync with Genesys Cloud for the rest of the day.

Hope you have a wonderful day. 

thank you for the response.

What is the name of the metric to use with v2.analytics.queues.{id}.observations to get the abandon count?

And what is the downside of using it vs using the Analytics Conversation Aggregates API?

Hi Joel,

For real-time queue metrics, you can subscribe to the Queue Observations notification topic:
v2.analytics.queues.{id}.observations

The notifications provide observation metrics for the queue. However, for the actual abandoned interaction count (nAbandon), I would recommend using the Analytics Conversation Aggregates API, since nAbandon is an aggregate metric rather than relying only on the real-time observation payload.

You could use the WebSocket notification to trigger/refresh your dashboard and query the aggregate endpoint for metrics such as nOffered, nConnected, and nAbandon.

There is also a useful overview of the Analytics APIs here:

https://developer.genesys.cloud/analyticsdatamanagement/analytics/aggregate/conversation/

https://developer.genesys.cloud/analyticsdatamanagement/analytics/extraction/

I agree with you, but I have a problem

 We have over 40 queues on the dashboard and if I need to call api's for each queue separately and keep on calling it(since the requirement is for it to be live) we will definitely hit into rate limiting issues.

Currently, I am calculating it by subtracting calls answered count for a queue from call received for that queue, and also subtracting calls waiting. It's working for the most part, the problem I am having is, that sometimes the numbers go up and down for a few seconds until they settle to the right number and I think it due to race conditions.

Good day, Joel,

I am not aware of a metric for abandoned interactions with that payload. 

My opinion on downsides of using Observations vs. Aggregates, others might have a different view.

Since observations only reflect current active states, I wouldn't build a live dashboard exclusively off the WebSocket stream; it introduces some real issues:

1. You have to guess the outcome. To track abandons via WebSocket, you'd need custom logic to watch for every drop in the oWaiting count. If it drops without a corresponding rise in oInteracting, you'd have to assume it was an abandon.
2. That guess is often wrong. If a caller opts out of the queue back to the IVR, or a system timeout routes them to voicemail, that's a flow-out, not an abandon. Custom logic built on the WebSocket stream will misclassify these as abandons every time. The Aggregates API sorts these into the right buckets natively, so you don't have to reverse-engineer the logic yourself.
3. You're exposed to desyncs. WebSockets are a live stream; if your connection drops for even a few seconds, or your client misses a payload, your running tally breaks and stays out of sync with Genesys Cloud for the rest of the day.

Hope you have a wonderful day. 

thank you for the response.

What is the name of the metric to use with v2.analytics.queues.{id}.observations to get the abandon count?

And what is the downside of using it vs using the Analytics Conversation Aggregates API?

Hi Joel,

For real-time queue metrics, you can subscribe to the Queue Observations notification topic:
v2.analytics.queues.{id}.observations

The notifications provide observation metrics for the queue. However, for the actual abandoned interaction count (nAbandon), I would recommend using the Analytics Conversation Aggregates API, since nAbandon is an aggregate metric rather than relying only on the real-time observation payload.

You could use the WebSocket notification to trigger/refresh your dashboard and query the aggregate endpoint for metrics such as nOffered, nConnected, and nAbandon.

There is also a useful overview of the Analytics APIs here:

https://developer.genesys.cloud/analyticsdatamanagement/analytics/aggregate/conversation/

https://developer.genesys.cloud/analyticsdatamanagement/analytics/extraction/

Joel,

I hope your week went well. I thought about this some and here are my thoughts -

What you're seeing is a classic race condition from relying on real-time event streams for aggregate math. When state changes come in over WebSocket, like a call moving from waiting to disconnected, they don't always arrive in order. That means your dashboard sometimes crunches the numbers before all the data is in, so totals jump around until things catch up. On top of that, this approach still misses flow-outs, so your daily numbers will drift over time.

The good news is you don't need to fire off 40 separate API calls. The Analytics Conversation Aggregates API is built for bulk queries.

You can pull metrics for all 40 queues in one shot by using the API's grouping and filtering features. Here's how I'd tackle it:

1. Send a single POST request to the /api/v2/analytics/conversations/aggregates/query endpoint.
2. In your JSON payload, set "groupBy": ["queueId"] and include your 40 queue IDs in the filter. The API will return metrics for each queue separately.
3. Set a specific time window each time you poll. The endpoint needs an explicit interval (e.g., start of day to now), so update it with every request instead of repeating the same payload.
4. Before you pick a polling interval, check your org's actual rate limit for this endpoint under Admin, Integrations, API Rate Limits. It varies by category, so I don't want to guess. Once you know your limit, polling every 5 to 10 seconds with a single grouped query will use just a small slice of your quota; much less than 40 separate calls.

One thing to keep in mind: this approach smooths out jitter, but it's not as instant as the WebSocket stream. Aggregate data only updates after each conversation segment closes, so there's a short delay before a new abandon shows up in your totals. In practice, your abandon count will be accurate but a bit behind-not wrong and then right, just slightly delayed. For this metric, I'd take a number that's a few seconds old but always correct over one that's instant but sometimes mislabels flow-outs as abandons.

I hope this works for you but that is probably the best idea that I could come up with. 

Have a wonderful weekend. 

I agree with you, but I have a problem

 We have over 40 queues on the dashboard and if I need to call api's for each queue separately and keep on calling it(since the requirement is for it to be live) we will definitely hit into rate limiting issues.

Currently, I am calculating it by subtracting calls answered count for a queue from call received for that queue, and also subtracting calls waiting. It's working for the most part, the problem I am having is, that sometimes the numbers go up and down for a few seconds until they settle to the right number and I think it due to race conditions.

Good day, Joel,

I am not aware of a metric for abandoned interactions with that payload. 

My opinion on downsides of using Observations vs. Aggregates, others might have a different view.

Since observations only reflect current active states, I wouldn't build a live dashboard exclusively off the WebSocket stream; it introduces some real issues:

1. You have to guess the outcome. To track abandons via WebSocket, you'd need custom logic to watch for every drop in the oWaiting count. If it drops without a corresponding rise in oInteracting, you'd have to assume it was an abandon.
2. That guess is often wrong. If a caller opts out of the queue back to the IVR, or a system timeout routes them to voicemail, that's a flow-out, not an abandon. Custom logic built on the WebSocket stream will misclassify these as abandons every time. The Aggregates API sorts these into the right buckets natively, so you don't have to reverse-engineer the logic yourself.
3. You're exposed to desyncs. WebSockets are a live stream; if your connection drops for even a few seconds, or your client misses a payload, your running tally breaks and stays out of sync with Genesys Cloud for the rest of the day.

Hope you have a wonderful day. 

thank you for the response.

What is the name of the metric to use with v2.analytics.queues.{id}.observations to get the abandon count?

And what is the downside of using it vs using the Analytics Conversation Aggregates API?

Hi Joel,

For real-time queue metrics, you can subscribe to the Queue Observations notification topic:
v2.analytics.queues.{id}.observations

The notifications provide observation metrics for the queue. However, for the actual abandoned interaction count (nAbandon), I would recommend using the Analytics Conversation Aggregates API, since nAbandon is an aggregate metric rather than relying only on the real-time observation payload.

You could use the WebSocket notification to trigger/refresh your dashboard and query the aggregate endpoint for metrics such as nOffered, nConnected, and nAbandon.

There is also a useful overview of the Analytics APIs here:

https://developer.genesys.cloud/analyticsdatamanagement/analytics/aggregate/conversation/

https://developer.genesys.cloud/analyticsdatamanagement/analytics/extraction/