Analytics job failing - inconsistent data with historical range

General Discussion
1

Hey all,

We’ve got around 1200 agents and I’m banging my head against a wall with analytics jobs. It’s not a straight 400 or 500 - it’s more… subtle. Jobs complete successfully, the API returns 200, but the data returned is consistently wrong when using a historical date range.

I’m using the GET /api/v2/analytics/jobs/{jobId}/results endpoint to pull down the results. Specifically, the dateFrom and dateTo parameters seem to be ignored for certain metrics.

It’s happening across multiple metrics - call volume, average handle time, even simple things like number of agents logged in. If I narrow the dateTo to today only, the results are accurate. Extend it back even just a day, and it’s garbage. I’m testing with view=digital and view=voice and it’s affecting both.

The docs say the API supports date ranges up to 90 days. We’re well below that.

I’ve tested with different date formats too - YYYY-MM-DD, YYYY-MM-DDTHH:mm:ssZ - no difference. The Celery worker logs show the jobs are completing without error. Here’s a sample payload:

{
 "view": "digital",
 "dateFrom": "2024-02-01T00:00:00Z",
 "dateTo": "2024-02-15T23:59:59Z",
 "filters": [],
 "metrics": [
 "nlu.v1.total_messages",
 "nlu.v1.messages_sent_by_agent"
 ]
}

I initially thought it was a caching issue on our PostgreSQL analytics instance but it’s persisting across multiple reboots.

Not 100% sure but I’m wondering if there’s something wonky with how the analytics engine handles historical data for jobs created via the API versus those run through the UI. Maybe a different process gets used. I’m on Python 3.9, using the official Genesys Cloud v4.1.3. It’s happening on both our dev and staging environments.

The weirdest part? Sometimes it looks right in the first few pages of results, then completely falls apart.

2

Okay, so this is… really tricky, because the analytics API can be a bit finicky. We’ve seen similar things where the timezone settings on the job itself don’t quite line up with the agent’s timezone or the org’s timezone. I think it’s something to do with how the API interprets the date range - it’s not always UTC, and that’s where things get messy. You’ll want to double-check that the timeZone parameter in your analytics job request is set correctly. It should probably match the timezone the agents are working in, or at least the org’s default.

Here’s a little snippet of how we’re setting up the job request in React - it’s probably not perfect, and I’m still pretty new to all this, but it’s working for us at the moment. It’s a little verbose, but it’s easier to debug that way, right? Note the timeZone. We’re using Europe/Berlin since that’s where we’re at.

const jobParams = {
 name: 'My Historical Report',
 description: 'Pulling historical data',
 dateFrom: '2024-01-01T00:00:00.000Z',
 dateTo: '2024-01-02T00:00:00.000Z',
 timeZone: 'Europe/Berlin',
 format: 'json',
 // ... other parameters ...
};

I feel like I’m missing something obvious here, though - hopefully this helps? It’s probably something simple I’m overlooking. Is the dateFrom and dateTo always inclusive? I get confused with those sometimes.

1 Like
3

It’s the data aggregation layer, predictably. Genesys Cloud’s analytics engine - and honestly, NICE’s is similar in this regard - isn’t truly “realtime” in the way marketing folks like to claim. It’s near realtime, but historical range queries force it into a weird mode where it’s trying to reconcile pre-aggregated data with the raw events. This is why you see 200s with garbage. The API isn’t failing, it’s giving you a best-guess based on incomplete or delayed data.

A quick win is to narrow your date range - like, significantly. Try a 24-hour window. If that works, you’re confirming the aggregation issue.

If you need the historical range, you’ll need to pull the data in smaller chunks and stitch it together on your end. Not fun. I’ve seen folks use a lambda to do this - it polls the API in increments, shoves the results into a data store (Redis is popular, obviously), and then a separate process merges it. It’s a cursed solution, but it bypasses the aggregation problem.

We’re on Genesys Cloud, and we pipe everything into Tealium, so we’ve built a similar system for reconciling discrepancies. The CDP helps smooth things out.

4

The earlier reply about timezones is absolutely crucial - it’s almost always that. However, there’s a detail that frequently gets overlooked, especially with historical ranges. The analytics API doesn’t automatically adjust for daylight saving time transitions within the specified date range. So, if your dateFrom and dateTo span a DST change, the results will be off by an hour for portions of that period. We run about 1400 agents, and we encountered this repeatedly when reporting on call volumes across March and November.

To mitigate this, you’ll want to pre-calculate the offset manually, and potentially adjust the date range slightly to account for the ambiguity around the transition. It’s not ideal - a proper solution would handle this internally - but it’s the workaround. Here’s a snippet showing how you might adjust the dates in your request: dateFrom = dateFrom.subtractHours(1); if your range includes the fall-back DST change. It’s a pain, but it resolves the discrepancy.

1 Like