Help with Conversations api metrics

Platform API
1

Hi team,
We need your help with the following cases:

  1. What metric within the Conversations API tells us if a conversation has generated a callback after being queued for a while?
  2. And how can we know when a conversation has generated a callback, without queuing.

Best regards.

2

Hi @Alfredo,

After some testing, I'd like to share my insights regarding your inquiries.

  1. To access conversation data, you can use the following API endpoint:
POST /api/v2/analytics/conversations/details/query

For testing purposes, I used the Analytics Query Builder with the Query Type: Conversation Detail.

In my request, my focus was on callbacks that originated after being queued. Essentially, this involves inbound calls that get transformed into callbacks through a call flow in Architect. Or, it could be cases where an agent responded to the call and then scheduled a callback manually through the UI.

Belown the JSON Body of the request:

image
image1153×949 53.2 KB

For these cases, I used these filters:

  • Conversation Filters:

    • originatingDirection: This dimension should be set to inbound to exclude outbound calls.

  • Segment Filters:

    • callbackNumber: This dimension must exist to make sure the callback was set with ANI correctly.

The response I received included the inbound calls that were transformed into callbacks.

  1. How to know when a ocnversation has generated a callback without queuing ?

To answer this question, I made a comparison between two types of conversations:

  • Scenario 1: A conversation where a callback is generated within the inbound call flow whithout queueing.

  • Scenario 2: A conversation that enters a queue and generated a callback within the in-queue call flow.

Below, the result of this comparison:

image
image1317×817 111 KB

As you can see, in the participant section where the purpose is identified as 'ivr', there is a flow object within the sessions array.
When there is no queueing involved, the exitReason is labeled as "FLOW_DISCONNECT", and the issuedCallback is flagged as true.
On the other hand, in conversations where queueing has occured, the exitReason is changed to "TRANSFER", and there is no issuedCallback property present. Instead, we have the transferTargetName indicating the name of the queue where the queueing process took place.

I apologize if my answer was extensive, but I hope it provided the information you were seeking :slight_smile:

Best regards,

Charaf

1 Like
3

Hello Charaf,

Thank you very much for the great explanation you have made, and for the time you have invested in it.
The explanation has been enough to know how I can analyze the conversation, and thus obtain the values I am looking for.

Again, thanks a lot for the help.

Best regards.

4

I'm glad the explanation was helpful to you :slight_smile:

Best regards,

Charaf

5

This topic was automatically closed 31 days after the last reply. New replies are no longer allowed.