I’m a heavy user of the Performance Dashboards in the Genesys Cloud UI, specifically the ‘Top 10 agents by AHT’ and ‘Top 10 agents by Answer Rate’ widgets. Lately, I’ve noticed a consistent discrepancy between these widgets and the raw data I get when I run a ‘Conversation Detail’ export via the Analytics API for the exact same time interval.
For example, yesterday the dashboard showed Agent A as having the lowest AHT at 180s. But my API export shows Agent B actually had 165s AHT and isn’t even in the Top 10 list on the dashboard. We use Divisions, but both agents are in the same Division and Queue.
Are the dashboard widgets using a different aggregation logic or a sampling rate that differs from the raw API data? This is making it hard to trust the built-in visualizations for performance reviews.
I’ve seen this on our Edge-monitored queues. The Performance Dashboard widgets use ‘Pre-Aggregated’ data tables for speed. These tables are updated periodically (every 15-30 minutes), whereas the Analytics API queries the ‘Near-Real-Time’ index. If you’re looking at a time window that includes the last hour, the dashboard is almost certainly lagging behind the raw API.
Exactly. Also, check your ‘Filters’ on the dashboard. The ‘Top 10’ widgets sometimes have implicit filters (like only counting conversations that started and ended within the interval), while a raw API query might include segments that started before the interval but ended during it. In the SIP world, we call this ‘In-Flight’ data management, and it’s a common cause of reporting drift.
To build on Raj’s point, look at how you calculate AHT. Does your API script include ‘Hold Time’ and ‘ACW’? The dashboard widgets follow the standard Genesys definition (Talk + Hold + ACW). If your script only looks at ‘Talk Time’, you’ll never match.
One more thing: check for ‘Multiple Segments’. If an agent handles a call, transfers it, and then it’s transferred back to them, the API will show two separate segments for that agent, while some dashboard widgets might aggregate them into a single ‘Interaction’ for that user. This nuance is documented in the Analytics data model, but it’s easy to miss!