Conversation Aggregate query discrepancy based on granularity

Analytics and Reporting
1

Hi Genesys,

I am working you the "Conversation Aggregate query" in our SQL server.
We have to report that use the table but in two different Stored Procedure.
SP 1 uses conversationId as a granularity level.
SP 2 does not use conversationId.

For talktime I get two different results.

Why do I get different result based on granularity.

2

I think we would need to see the full criteria both versions are using to be able to troubleshoot any differences in results they're getting.

3

I dont now of the API call but I have the queies:
SELECT
Calendarkey
,[mediaType]
,[queueId]
, UserID
,[Direction]
,[metric]
,[Value] -- Via Unpivot Clausen fyldes den her kolonne med metric identifierne (Max,Min,Count,Sum)
,[Values] -- Via Unpivot Clausen fyldes dne her kolonne med de respektive værdier for (Max,Min,Count,Sum)
FROM (
SELECT *
FROM (
SELECT
[Calendarkey] = CONVERT(date, startTime)
,cqa.[mediaType]
,cqa.[queueId]
, UserID
,cqa.[metric]
,cqa.[Direction]
,cqa.[count]
,cqa.[sum]
FROM [sourceGenesysAPI].[ConversationQueryAggregates_history] AS cqa

		) AS sub

	UNPIVOT( [Values] 
	FOR [Value] IN ( [sum], [count] )
		   ) AS upvt
) AS sub
where queueId is not null

)
,
SELECT
Calendarkey
,[mediaType]
,[queueId]
, UserID
,[Direction]
,[metric]
,[Value] -- Via Unpivot Clausen fyldes den her kolonne med metric identifierne (Max,Min,Count,Sum)
,[Values] -- Via Unpivot Clausen fyldes dne her kolonne med de respektive værdier for (Max,Min,Count,Sum)
FROM (
SELECT *
FROM (
SELECT
[Calendarkey] = CONVERT(date, startTime)
,cqa.[mediaType]
,cqa.[queueId]
, UserID
,cqa.[metric]
,cqa.[Direction]
,cqa.[count]
,cqa.[sum]
FROM [sourceGenesysAPI].[ConversationQueryAggregates_history] AS cqa

		) AS sub

	UNPIVOT( [Values] 
	FOR [Value] IN ( [sum], [count] )
		   ) AS upvt
) AS sub
where queueId is not null

)

Where the only difference is that we have included conversatoinId in one table and not in the other?

4

That's the only difference you can see on the database side, but without knowing what APIs were used to load those tables it'd be impossible to do more than guess at why they're different.

It could be a bad load strategy, timing differences, slight variations in the API criteria, etc.
At this point you're asking us to debug your implementation of the data, not the API, and I don't think anyone here can do that for you.

5

I will return with some better knowledge when I have talked to our engineer.

Tank you for the response so far I will write back soon :slight_smile:

6

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.