In working to retrieve Speech and Analytic Conversations Sentiment score with related Topics we are using the following APIs:
• /api/v2/analytics/transcripts/aggregates/query
o BODY: {"interval":"2023-04-03T15:43:08.203Z/2023-04-10T11:10:05.026Z","groupBy":["conversationId","topicId","userId"],"granularity":"P1D","flattenMultivaluedDimensions":true,"metrics":["oSentimentScore"],"alternateTimeDimension":"eventTime"}
• /api/v2/speechandtextanalytics/conversations/[ConversationID]
To retrieve all conversations, including the Topic ID’s and Conversation ID’s, we are using the first API. We then pass the Conversation ID’s through to the second API to retrieve the scores.
However, the first API seems to require the body to include the intervals for when the conversation started and ended.
In testing, when we run the first API and use the exact start and end times of a conversation, the result is returned. However, if we take one minute from the conversation end time, the result is no longer returned.
Seven days seemed to be the maximum response we could receive.
This isn't an issue for calls and chats as they have defined start and end times. However, we are concerned about messengers as they only expire 72 hours after the last response. This could mean that messengers could roll on for periods that exceed the 7-day limit.
So the question is, how can we be sure to get all the Conversation topic information for messages if they can exceed the seven day limit?
Is there a different API that would get us what we want?
Per more recent discussion:
The Genesys engineers and they are looking into it.
Here are the main takeaways from our quick discussion:
The period limit would be an issue for asynchronous conversations (emails and webmessenger):
the Genesys setup provides that asynchronous interactions are considered “closed” once they reach a 72-hour period without activity.
If a customer contacts us through webmessenging every 2 days over a long period it might mean that the conversation exceeds the 7-day limit.
So it will come up in our activity data but not in the S&T transcripts because it isn’t “closed” in the last 7 days.
However, they thinks the interaction should still appear in later S&T extractions, once the interaction is “closed”:
The “end time” should work, regardless of the start time (to be checked with Genesys engineers)
Worthy of note: a single webmessenging conversation ID will usually have multiple transcript IDs, especially when conducted over a long period (a new transcript ID for every new message sent in the webmessenging thread)
They will continue looking into that with the engineers and making sure we can pull that data through one way or another, but he would like to confirm that they have understood our needs and concerns correctly. He was unsure about the scope of our question of the forum: Questions Genesys has for Alex H:
Do we want to reconcile the number of interactions transcribed with the ones in our activity data for any given 7-day period, even if some interactions aren’t finished in that time?
Or do we just want to make sure that all S&T data for transcribed conversations can be pulled from the API at some point, even if it comes after more than 7 days since their start time?
In response to the questions I feel the optimal approach would involve extracting S&T conversations after they have concluded. This ensures that the sentiment score remains unchanged since the conversation is complete.
Ideally, we would utilize this API to perform this extraction based on the Conversation Closed datetime. However, this API has limitations in terms of the available 'alternateTimeDimension' options. Unlike other APIs, such as Evaluations which allow for more options to be passed (e.g., 'Valid Values: conversationStart, evaluationCreatedDate, evaluationReleaseDate, eventTime'), the current API only allows the use of 'eventTime'.
I would like to clarify a reference made in a previous post regarding a 7-day period. It's important to note that this 7-day period is not a fixed limitation imposed by the API itself, but rather a result of the volume of data being returned by the API. This high volume of data is causing the API to return an error message stating, 'Result set is larger than result limit. Avoid grouping on high-cardinality fields, or use filter predicates to reduce the number of groups for that field.'
It's worth mentioning that the 7-day period is the limitation we are seeing currently based on the existing volumes of data. However, if there were to be an increase in volumes, I would expect this window to reduce.