G’day from the APAC region! We’re running into a persistent headache with our daily ‘Average Talk Time’ (ATT) reporting. Many of our support calls start late at night and span across the midnight ‘rollover’ (we’re in UTC+11 right now).
When we run a daily report for ‘Tuesday’, a call that started at 11:55 PM on Monday and ended at 12:15 AM on Tuesday seems to be split. Part of the talk time shows up on Monday’s report and part on Tuesday’s. This makes our daily ATT metrics fluctuate wildly, especially for our night-shift teams.
Is there a way to force Genesys Cloud to attribute the entire interaction’s metrics to the day the call started, or is the ‘Segment-Level’ splitting hardcoded into the analytics engine?
This is definitely hardcoded into the ‘Aggregate’ views. The aggregate engine (what powers the standard dashboards) buckets data based on the interval the segment occurred in. If the interaction crosses midnight, the segments are literally binned into two different days.
If you need ‘Start-Date Attribution’, you have to stop using the aggregate endpoints and use the POST /api/v2/analytics/conversations/details/query endpoint instead. When you query by conversationStart, you’ll get the full interaction details. You can then sum up all segments for that conversation and attribute the total talk time to the day it started. We do this for our remote agent voice quality reports to ensure our ‘Daily’ SLAs are consistent.
Bia is 100% correct. I’ve built dozens of real-time dashboards using WebSockets, and we always use the ‘Conversation Detail’ record as the source of truth for daily stats.
One thing to watch out for: if you move to a ‘Start-Date’ model, your ‘Weekly’ totals might not match the sum of your ‘Daily’ totals if you’re pulling from different endpoints. Make sure your BI tool is doing the aggregation based on the conversationStart timestamp for everything, or you’ll be explaining ‘missing minutes’ to your supervisors every Monday morning!