Is it possible to reconcile VDN interaction metrics with Bot Conversation Analytics in Performance Views? We have deployed a comprehensive AI Virtual Agent flow within our Europe/Paris organization, utilizing standard Genesys Cloud Architect components for intent classification and entity extraction. The objective is to track the efficiency of the bot in resolving inquiries without human escalation, specifically focusing on the ‘First Contact Resolution’ rate as reported in the Agent Performance dashboard versus the raw data available in the Bot Analytics reports.
The discrepancy arises when comparing the total number of conversations initiated against the VDN. The Performance Dashboard under ‘Queue Activity’ reports a significantly higher volume of interactions than the ‘Bot Conversation Analytics’ report. This variance suggests that certain interactions are not being correctly attributed to the bot session or are being terminated prematurely in the analytics pipeline.
Steps to reproduce the issue:
- Configure a Virtual Agent flow with a primary intent set to ‘General Inquiry’.
- Ensure the flow includes a ‘Transfer to Human’ action upon confidence score thresholds being met.
- Generate test traffic via the Web Chat widget, simulating both resolved and escalated scenarios.
- Navigate to the Performance Dashboard and select the specific VDN associated with the bot.
- Compare the ‘Total Conversations’ metric in the Queue Activity view against the ‘Total Sessions’ metric in the Bot Analytics report for the same time period.
The Queue Activity view includes all inbound requests, whereas the Bot Analytics view appears to filter out sessions that do not complete a full intent match or those that timeout during the initial greeting phase. We require a unified metric for executive reporting that accurately reflects the bot’s true resolution rate. Is there a specific configuration in the Architect flow or a custom report definition that aligns these two data sources? We are currently unable to validate the ROI of the AI implementation due to this data inconsistency. Any guidance on standardizing these metrics would be appreciated.
You need to recognize that VDN metrics and Bot Analytics operate on fundamentally different data models within the platform architecture. VDN interactions are tracked at the telephony or digital channel ingress level, measuring queue performance and abandonment, whereas Bot Conversation Analytics focus on intent success rates and dialogue turns. To reconcile these, you cannot simply join tables in a standard report. Instead, you must leverage the Interaction ID that persists through the entire engagement lifecycle, from the initial VDN entry to the bot’s final resolution or transfer. This requires a custom reporting approach that bridges the gap between the two distinct analytics modules.
The most robust solution involves creating a custom report using the Genesys Cloud Reporting API. You will need to query the interaction object to capture the initial channel data and the bot_conversation object to capture the AI metrics. By filtering on the interactionId, you can correlate the VDN queue performance with the bot’s resolution status. Here is a sample API call structure to fetch the necessary interaction details:
{
"type": "interaction",
"filter": {
"interactionId": "your_specific_interaction_id"
}
}
Ensure that your report includes the botConversationId field from the interaction object. This field allows you to pull the detailed bot analytics for that specific session. You can then calculate the First Contact Resolution rate by comparing the bot’s resolution status against the VDN’s disposition data. This method provides a unified view of performance, allowing you to track how effectively the bot is handling inquiries before they potentially escalate to human agents.
Be aware that this approach requires careful handling of data latency. Bot analytics may update slightly after the VDN interaction concludes. It is advisable to schedule your reports to run during off-peak hours to ensure all data points are fully synchronized. Additionally, verify that your bot flow is correctly tagging all interactions with the appropriate resolution codes. Without consistent tagging, the reconciliation process will yield inaccurate results. This manual correlation is currently the only reliable way to achieve a holistic view of bot and VDN performance in Performance Views.
the documentation actually says you can stitch these together using the interaction id, but doing it via the ui is painful. since i’m focused on load testing, i usually just hit the analytics apis directly. you can pull the bot metrics from get /api/v2/analytics/conversations/summary and match them against the vdn queue stats using the external id or interaction uuid. it’s not a native join in performance views, so you have to do the correlation in your own tooling or a data warehouse. i’ve seen this cause issues when the bot handoff happens asynchronously, leaving a gap in the interaction chain. make sure your jmeter scripts or data pipelines handle the eventual consistency. the api throughput is decent, but watch out for rate limits if you’re pulling historical data in bulk. just map the interaction id from the bot summary to the vdn interaction record and you’ll get the fcr rate you’re looking for.
Yep, this is a known issue… The interaction ID is indeed the golden key here. While the API approach works, keep an eye on data latency. Bot analytics often lag behind real-time VDN metrics by a few minutes, which can skew immediate reconciliation efforts.
Note: Ensure your custom Architect flow explicitly passes the interaction ID to the bot container for seamless tracking.