We experience a 30-90 second delay between placing an API call and seeing the conversation appear in analytics queries.
Our executive dashboard shows a ‘real-time’ view of active calls, but it is consistently 60 seconds behind. When I compare the API POST timestamp to the first analytics query that returns the conversation, the delta averages 47 seconds with a standard deviation of 18 seconds.
Why are we paying for a ‘cloud-native real-time platform’ that has a 60-second data delay?
I need my operations team to explain this to the board. If our competitors can show real-time data and we can’t, we have a competitive disadvantage that affects customer satisfaction.
For our ETL pipeline, we account for the analytics delay by implementing a 2-minute lookback window.
When querying conversations that ended in the last 5 minutes, we actually query the last 7 minutes and deduplicate. This ensures we catch conversations that were delayed in the analytics pipeline. The deduplication key is the conversation ID.
I’m sorry if this is a dumb question, but how do I even know if the conversation ID exists yet?
# My code keeps returning empty
result = api.post_analytics_conversations_details_query(body)
if len(result.conversations) == 0:
print('Not found yet?')
Should I just keep retrying until it appears?
Communicate the analytics delay to your supervisors during onboarding.
If supervisors are trained to believe the dashboard is real-time, they will make incorrect staffing decisions during the first 60 seconds of a shift change. Set the expectation: ‘The dashboard updates within 1-2 minutes of actual events.’
The delay is by design. The analytics pipeline processes conversation events asynchronously.
Architect flows execute in real-time, but the analytics database is an eventually consistent store. For real-time monitoring, subscribe to v2.routing.queues.{queueId}.conversations via WebSocket. For historical reporting, use the analytics API. Don’t mix the two use cases.