But when I posted the query throw developer-tools after setting these two metrics ,there came out a 400 bad request error. I also tried other metrics written on the webpage above, they are all ok except for these two.
■query detail
POST /api/v2/analytics/conversations/aggregates/query
I'm in a similar situation. Not with the error code 400, but just... fields that should be there are not allowed. Like I wanted to get the user IDs of the agents who took the calls (probably empty if abandoned). I can group by "userId" but I can' actually request that as a data point/field/"metric"/whatever they call it. The docs make it sound similar to a DB query, but they've object-oriented it so that a field is not really a field. Funky, a bit counter-intuitive, but trendy?
Anyway, my best guess (and again this is coming from a relative noob) would be one of the other query functions (I'm currently researching their whole "query vs. jobs" philosophical deep-dive lol). My best guess is that the fields you're looking for (which would also help me I think) are only allowed for some queries but not others. I wish they would just let fields be fields lol... anyway, idk what platform or SDKs you're using (if any) but the functions I'm studying at the moment are analytics/conversations/details, analytics/conversation/details, and analytics/conversations/details/jbs. Hopefully one of those will lead to the info you're looking for.
The function I am try to use is as below, similar to yours. Analytics APIs (genesys.cloud)
POST /api/v2/analytics/conversations/aggregates/query
I already knew some columns written in the dimensions description part can not use as a field ,for example userId. But I think columns written in metrics description part(below webpage) all can be used as field. I guess the list of the metrics is not updated written in the webpage below. Conversation Aggregate query (genesys.cloud)
・Convesation Aggregate Metricsy→description of metrics
Do you have any idea who should I ask help for to check whether the description about the metrics on the webpage above is updated or not?
@Jli Check the response body. It usually provides some insight as to what was wrong with your request. If the body doesn't tell you, you can provide the correlation ID and I can see if there's any additional server-side tracing.
@LighthouseMike the only thing you can get from analytics queries is full conversations. You can filter your query to affect which conversations are returned, but you have to extract the data you need from each conversation.
@LighthouseMike Use queries for real-time needs like a dashboard. Use jobs for bulk data extraction/data warehousing.
The API Explorer documentation and the list of metrics/dimensions is always up to date. If you've noticed a discrepancy between what the docs say and the behavior of the API, please be specific about your observation.
I think their docs are generated by some program. That's a very common practice, though IMO leads to docs that are a bit... trying to think of a nicer word than "scatterbrained". I'm sure they're doing the best they can - if their system is this tough for us to master as API users, I can't even imagine how crazy it must all be under the hood.
But getting back to your problem and mine: one thing that's helping me (kinda) is experimenting with different values in "groupBy". For example, one of the fields I've been asked to have a program calculate is "number of agents taking calls" (and by that they mean, "total agents who took more than one call during the selected day"). I can't put "userId" in the "metrics" parameter, but by putting it in "groupBy" I'm still able to get user IDs. It's not like I can do a literal DB query, SELECT DISTINCT userId FROM conversations WHERE interval = the day. So I'm having to trial'n'error my way to the right results, trying different combinations of different parameters to try and guess out exactly how that number is supposed to be calculated. This "scavenger hunt" approach is less than idea, but with such a complex API I think it's the best we can do. One important gotcha with this workaround though: when you use multiple groupBy values, you run the risk of duplicate records (which I learned the hard way by adding conversationId into the mix). So there are 1.21 jiggawatts of factors/variables that require extremely detailed study, and either prayer or luck (whichever you believe in lol) but it can be done.
During the course of my endless experiments, I tried the "tCallback" field as well and get the same error as Jli: "unsupported metric tCallback" (which makes me wonder why it's in the docs at all if it's not supported - I can kinda understand why the question was "are the docs up to date" lol). Anyway, we'll have to try that API call to get extended error info. Good to know that trick exists (and I'm sure I will need it very soon, lol).
Now not to hijack the question (cuz I know this was about the "unsupported" tCallback), but some of your answers kind of just lead to more questions.
So when you say "Use queries for real-time needs like a dashboard. Use jobs for bulk data extraction/data warehousing", which would you call a report that runs daily? It's kind of middle-of-the-road, cuz it's "bulk" in the sense that there's a lot of data for the day, but it's not like I'm requesting gigs at a time.
On the other hand, I think my issue is less about query vs. jobs and more about aggregate vs. details. Like to figure out how many calls were abandoned - aggregate queries may give you "whole conversations" but there is no nAbandon (there's a tAbandon tho, so at times I've guessed there must be a way to programmatically total i.e. all records that have a "tAbandon"). But then I run into duplicates due to how I'm using "groupBy" (because I'm using "groupBy" to get fields that are not allowed in "metrics" like queue ID and user ID. I guess my question is, when you say aggregate queries give us "whole conversations", is there a way to get the whole whole conversation (all the fields/data points/metrics/whatever)? I'm sorry, I'm not even sure how to ask this.
EDIT: I think - and I still have to play with it some more - but I think the API endpoint I'm looking for is conversation details query. It's another shot in the dark, but I think it might help in your situation too. I'm still reading the section on "segments", but I bet there's a way to get tCallback from each conversation that way. It's funny, because the details query is still kind of "aggregate" in that it gives a lot of results... it just gives different data. I'm sure there is some subtle wordplay here that I'm not picking up (still learning call center slanguage on top of API endpoints and SDKs and such ) but the "details" query looks like it'll solve my problem, so maybe it'll help with yours as well.
EDIT 2: Well... I guess not. interestingly enough, I tried filtering the details query by queue ID (because again, from my mere mortal logic and reasoning, which queue the call was for should be part of "details") buuuut...... nope...... okay, there must be a "details about the details" query someplace.
Here is the response,thank you for your help.
{
"message": "unsupported metric tCallback",
"code": "bad.request",
"status": 400,
"messageParams": {},
"contextId": "d5e86d6a-e2cf-44ba-8a67-9e6c3b6f1ad4",
"details": [],
"errors": []
}
I already knew some columns written in the dimensions description part can not use as a field ,for example userId. But I think columns written in metrics description part(below webpage) all can be used as field. I guess the list of the metrics is not updated written in the webpage below.
tCallback and tCallbackComplete are beta metrics not yet available for production. This page notes which are in preview mode. https://developer.genesys.cloud/analyticsdatamanagement/analytics/metrics Metrics in preview will throw back 400s if you try to query them because they aren't yet valid metrics. However they'll still show up on the page because the code base contains the metric which automatically populates this doc. We mark them as preview to note that they're not yet available and to also give you some insight into what new metrics we have coming soon.
