Messaging Channel Discrepancy in Agent Performance Views

Just noticed that the conversation counts reported in the Agent Performance view do not align with the raw data available in the Conversation Detail view for our digital messaging queues. This inconsistency is causing significant confusion during weekly performance reviews with the operations team. The environment is Genesys Cloud EU-West BYOC, and the issue persists across multiple agents assigned to the primary WhatsApp and Web Chat queues.

The specific workflow in question is version 6.1, deployed last month. It routes inbound messages to a queue based on language detection before handing off to a human agent. When reviewing the Agent Performance dashboard, the ‘Handled Conversations’ metric for a specific agent shows 45 interactions for yesterday. However, when filtering the Conversation Detail view by the same agent and the same date range, only 38 conversations are listed. The missing seven conversations appear in the queue summary reports but are absent from the individual agent’s detail log.

The business impact is substantial, as leadership relies on the Agent Performance view for productivity metrics and incentive calculations. If the data is incomplete, the reported efficiency rates are artificially inflated. The discrepancy seems isolated to digital channels; voice metrics appear consistent across both views. There are no error messages or alerts in the system logs, and the flow execution logs indicate successful completion for all routed conversations.

Could this be related to how the system defines a ‘handled’ conversation in the context of asynchronous messaging? Perhaps the metric excludes certain interaction types, such as those terminated by the customer or those that did not result in a state change? Clarification on the exact criteria for the ‘Handled Conversations’ count in the Agent Performance view versus the Conversation Detail view is required. The team needs to understand whether this is a reporting latency issue or a fundamental difference in metric definition.

The easiest way to fix this is to stop relying on the standard Agent Performance dashboard for digital channels. It’s a known limitation in the current release. The UI often aggregates data differently than the raw conversation logs, especially for WhatsApp and Web Chat where session handling is distinct from voice.

• Switch to using the PureCloud API directly. The dashboard uses cached aggregation, which can lag or drop specific interaction types. Querying the GET /api/v2/analytics/conversations/details/summary endpoint gives you the exact count.
• Ensure your date range filters are set to UTC. The EU-West BYOC environment stores timestamps in UTC. If your local reporting tool converts this to CET/CEST, you might see split-day discrepancies.
• Check the state filter in your API call. The dashboard might be including queued but excluding active if the session timed out, whereas the Conversation Detail view shows every state transition. Filter for ["accepted", "completed"] to match what ops usually care about.
• Verify that the agents are assigned to the correct routing language. If a message comes in without a language tag and the agent doesn’t match the default, it might not count toward their handled metric in the summary view, even if they interacted with it.

Here’s a quick snippet for the API call:

import purecloud

api_instance = purecloud.AnalyticsApi()
body = purecloud.ConversationsDetailsQuery(
 view="by-conversation",
 date_from="2023-10-01T00:00:00Z",
 date_to="2023-10-08T00:00:00Z",
 select=["conversationId", "channel", "state"]
)
result = api_instance.post_analytics_conversations_details_query(body)

Run this against a few agents. Compare the JSON output with the dashboard numbers. You’ll likely see the dashboard is missing short-lived sessions or those marked as no-answer. The Resource Center article on “Analytics Data Latency” mentions this specifically for digital channels. It’s not a bug, just a design choice to keep the UI fast. Use the API for audits.

Check your interactionType filters in the API call. The dashboard excludes message type interactions by default if they’re part of a larger session.

Use /api/v2/analytics/conversations/summary with those params to get the real count.

this looks like a caching issue with the dashboard aggregation. the api response is usually accurate. try pulling the data via the outbound api instead. here is a quick curl to check the raw counts. it bypasses the ui cache. curl -X GET "https://api.mypurecloud.com/api/v2/analytics/conversations/queues/ranges" -H "Authorization: Bearer $TOKEN"

the dashboard isn’t lying, it’s just blind to how your custom channel registers sessions. if you’re building a custom DFO channel, the default agent performance view often drops MESSAGE interactions unless they’re explicitly linked to a parent conversation with a valid routingState.

The point above is correct about the filter, but the root cause is usually the payload structure sent to the DFO endpoint. if the conversationId isn’t consistent across the initial connect and the subsequent messages, the analytics engine treats them as orphaned events. these get counted in the raw logs but stripped from the agent’s handle time and interaction count.

check your POST /api/v2/interactions payload. you need to ensure the routing object is present on the initial connect and that subsequent messages reference the same conversationId.

{
 "type": "MESSAGE",
 "routing": {
 "queueId": "your_queue_id",
 "state": "ACTIVE",
 "skill": "digital_support"
 },
 "conversationId": "consistent_id_here",
 "externalContactId": "user_123"
}

if you’re seeing a split in counts, run this check against the Conversation API for a specific agent’s session:

GET /api/v2/conversations/{conversationId}

look at the interactions array. if the message type entries are missing the routing context or have a different conversationId than the parent, that’s your leak. the analytics pipeline skips them because they don’t map to an active agent assignment.

also, verify your timezone settings. if the agent is in a different zone than the queue’s reporting zone, the daily rollup might shift interactions into the next day, creating a apparent mismatch in real-time views.

fix the payload consistency first. the dashboard will catch up within 15 minutes of the fix.