shotes | 2019-03-05 20:01:59 UTC | #1
Reading into the documentation for detail query syntax found here: https://developer.mypurecloud.com/api/rest/v2/analytics/query_syntax_detail.html
I am assuming the conversation detail query uses this syntax, with the required interval query following the specification in the detail query syntax doc. Maybe this is my misinterpretation but the detail query syntax states that regardless of the timestamp in the interval query, if the start date of the conversation overlaps with the date specified in the interval, it will show in the result set. This sounds like the interval timestamp is completely ignored and only the dates are considered, eliminating fine-grain control over querying on the interval minutes. Using the Conversation Details API though, (analytics/conversations/details/query) the interval timestamps seem to also be considered. How should I interpret the note below found in the documentation (bolded and italicized)?
Important The interval will filter based on the conversation start timestamp. Conversations will only be included in the results if their start occurs on a day that the interval touches. The actual time of the conversation start need not be within the interval as long as it occurs on a day involved in the interval. This is because conversations are stored in daily indexes based on their start timestamp, and we only search the indexes corresponding to days included in the interval for performance reasons. A live conversation that started yesterday will need the start of the interval to include yesterday for said conversation to be included in the results.
ralegner | 2019-03-06 14:41:01 UTC | #2
When a search is submitted, the search doesn't run against the entire data store. Instead, it searches all the indices relevant to the search which is what's being provided in the interval parameter. The search can be further fine tuned with other predicates.
The index structure of our data store is set up that conversations are only contained in the index of the day they were created and indices are segmented per day. In other words, a conversation created yesterday would not be contained in the index for today even if it has activity for today. This limitation is only noticeable for conversations that span multiple GMT days. The interval search must touch the index that contains the conversation in order for it to return in the result. Otherwise if the search only touched the index for today, the conversation you're looking for wouldn't be included in the search because it only exists in the previous day's index and that index wasn't included in the search.
As a result, the fine-grain control is more limited when it comes to conversations that span multiple days. We do plan on supporting this in the future, but writing conversations into multiple indices or expanding out searches on the backend to better support the front end has major performance and resource considerations. For now, searches looking for multi-day conversations would need to expand out the interval to ensure the conversation's index is included. Further fine tuning can be performed in the predicates or filtering application side.
system | 2019-04-06 14:41:03 UTC | #3
This topic was automatically closed 31 days after the last reply. New replies are no longer allowed.
This post was migrated from the old Developer Forum.
ref: 4724