Hello everyone. We recently deployed Web Messaging for our customer support website. I am observing a large discrepancy in our reporting. When I look at the Performance Interactions view, it shows fifty abandoned messages for yesterday. However, when I run an API query using /api/v2/analytics/conversations/details/query and filter for the disconnectType equal to client, the total number is much higher, around two hundred. Why is there a difference between the user interface and the raw API data? Does an abandoned digital interaction have a different definition than a voice call?
Hello. Yes, there is a very important difference. For voice calls, an abandon usually means the caller hung up while waiting in the queue.
For asynchronous messaging, the definition is completely different. A web messaging interaction might disconnect because the session timed out after 72 hours of inactivity.
The API will show this disconnect type, but the Performance view filters out these system timeouts by default so your supervisors only see genuine customer abandons. You must apply a specific metric filter in your API query for tAbandon if you want it to match the view.
This is exactly what drives me insane about Genesys Cloud reporting! You cannot just trust the numbers on the screen. My agents were getting penalized because the API reports showed hundreds of disconnected messages, and upper management thought we were ignoring customers! It turns out that if a customer simply closes the browser tab after the agent already solved their problem, the system logs it as a client disconnect. You absolutely have to filter by the tAbandon metric like the other reply said, otherwise you are comparing apples to oranges and ruining your team metrics!
Greetings! This is a fascinating data challenge! When we built our enterprise data lake on AWS, we ran into this exact same discrepancy! The native Performance Views are heavily curated to provide immediate operational value, which means they use complex backend logic to define an ‘Abandon’. Instead of trying to reverse engineer that logic using the conversation details query, we shifted to the Conversation Aggregates API! If you query /api/v2/analytics/conversations/aggregates/query, you can request the exact nAbandon and tAbandon metrics that the user interface uses! It completely solved our data mismatch issues and let us build perfectly synchronized QuickSight dashboards!