Genesys CTI User Forum
Genesys CTI User Forum => Genesys CTI Technical Discussion => Topic started by: Gef Buneri on November 24, 2016, 11:27:20 AM
-
Hi all,
as in object I'm noticing a little difference in numbers between CCPulse view and datamart stored data. At a first look, seems CCPulse adds abandoned in ring calls to entered calls (but entered are created from TotalNumber/CallsEntered)
Any clue, direction on how to fice the troubleshooting?
Regards, Gef.
-
we use the total calls Waiting, Answered, Abandoned & Cleared against calls Entered in each VQ. There will always be differences as you are comparing real time metrics to historical. If the difference is over 2% then we would look to investigate further.
-
Thanx Tambo. The difference is very small (surely less than 2%). Yes, at the moment I'm using that formula as a workaround, instead of the pure CallsEntered value, but wondering about the reason behind this difference.
-
Same SS used for both apps?
Can you post metrics definitions (SS options)?
-
Hi Cav., no :
CCPulse (7.5): ccp_statserver process (7.1)
datasourcer (7.1): ods_statserver process (7.1)
URS75 (7.5): StatServer75URS process (7.5)
http://web.tiscali.it/modifiche/ss_cfg.7z
Here .cfg from ss option export.
***EDIT***
p.s. by the way, OldStatsRemoveInterval "4320" in ccp_statserver options, seems quite suspect... 4320 seems more a port value.
-
And which Metrics are you using to compare??
-
TotalNumber, CallEntered , but not sure if I understood the question.
-
You say you have two reports, in one of them, CCPulse one, shows values different than DataMart one.
So I assume
You are comparing same metric on both of them
Both are historical reports (wouldn't make sense at all compare real time vs historical)
Which is the name of the metric you are comparing?
Enviado de meu E6633 usando Tapatalk
-
Yes, I'm comparing the historical data from datamart, with a screenshot of the ccpulse workspace team leaders collect at service closing.
The metric wich differs, is entered calls per virtual queue, other data matches on both ss.
-
Screenshot? O.o you mean real Time...
Then no way to compare
Historical has data already ended while RT can show information that still haven't gone to DB as the Time Profile for its historical data hasn't yet expired.
For me is just an invalid comparison
Enviado de meu E6633 usando Tapatalk
-
Yes, screenshot; weird, I know, but an outsourcer we use for service, takes a screenshot from ccpulse workspace to do an immediate internal comparison with their crm managed calls, then, the day after, we send them an automated report, and the n_entered from datamart, differs from the n_entered showed by ccpulse (collected by ccp_statserver). The difference seems to coincide with n_abb_ring or n_cleared (I'm still investigating on it). My theory is that ccp_statserver adds cleared or abbring to entered, but in datamart this calls are not counted in entered.
-
It must be caused by some misconfiguration or something like that, check the stat definition on both levels (RT, Historical reporting).
-
Hi Kub, thanks. Going deeper I found that CCPulse uses a different statistical type, even if the configuration (active/relative mask, type, etc) seems the same, but I can't find the statistical type name used by ccpulse, in DMA. Created a new vq template for CCPulse, using the statistical type taken by dma; let's see what happens.
Here, respectively, the stat used in production and the stat I'm testing.
***EDIT***
[img width=361 height=480]http://web.tiscali.it/modifiche/current_stat.PNG[/img]
[img width=361 height=480]http://web.tiscali.it/modifiche/testing_stat.PNG[/img]
-
Got nothing, a little difference still remains.
-
I must insist, not a valid comparison method Gef
-
Hey Gef, have you looked at
http://www.sggu.com/smf/index.php/topic,9724.0.html
Adam covers some of this type of question
-
Hi,
Check the DCID forumla. If it is only used by one of the statservers for calculating calls entered, and some calls go through the same VQ multiple times - then thats whats causing your issue.
-
Thank you all; Tambo, very useful reading. Catan, I'll goo deeper with the DCID formula.
-
Distinct By ConnID (DCID) will be your issue. Without going into too much depth; check to see if your routing passes calls back into a Queue or Group of Queues. If it does, then having DCID applies means it counts a ConnID passing through only once, no matter how many times it passes through/around.
A remedy could be to ensure that you use DCID on both stats (<recommended) - or don't use it on either of them (<not recommended)
-
Hi Adam, thank you very much for the interest.
I was already investigating on DCID, but stats on CCP and DMA seems to be identical, but number difference permains: for the same VQ in the same day, Total_Call_Entered in datamart 628, in CCP: 634:
[img width=436 height=480]http://web.tiscali.it/modifiche/stat_dma.PNG[/img]
[img width=360 height=480]http://web.tiscali.it/modifiche/stat_ccp.PNG[/img]
I'm configuring CCP stats in the properties - options section of the ccp_statserver in CME, and reporting stats on DMA; there's another place I should look to?
Regards.
-
Guys guys guuuuysssss he is comparing a CCPULSE moment versus an ETL fixed stored data...
Why everyone agrees they should match? Real Time vs Historical... No sense
Enviado de meu E6633 usando Tapatalk
-
Cav. it's Christmas! ;D
By the way, the comparison is not between a dynamic moment from ccpulse, is a screenshot done when all the services are stopped, so no change will occur 'til the next day, on that view or in the queue values from datamart, if this can be a useful info.
-
Hahaha hohohoho
I do understand that Geff ;) what is the CCPulse template Time Profile defined as?
Enviado de meu E6633 usando Tapatalk
-
how many cleared calls do you have for this VQ ?
-
lol.
Usually both systems are set on a "Standard" profile (08:00,23:59); on CCP I tried different profiles and intervals, obtaining no significant change.
Tambo, there are little cleared calls, but their number does not match differences with n_entered.
-
ok cool, i still maintain that you go with the historical report and as long as they are within 2% of each other then you're fine :-)
-
I would open 2 CCP, one with each SS before midnight, so at the end you will have same type of data but from different SS.
-
Also create an statistic to measure the AbandonOnRinging on the VQ too, guess this calls do return to the Queue after agents by some reason can't answer and will make the DCID impact.
Check your TServer options for what to do with those calls
-
....I wouldn't want to make this any more painful than it obviously is but the other dimension is to check that your Objects are also defined as the same. Sometimes you find that a Group of Queues - or even a Queue Name/Route Point may have been duplicated in CIM somewhere along the line and DMA/CCP are potentially using different objects. Check veeeery carefully for the naming conventions....
-
[url=http://web.tiscali.it/modifiche/cfg_tserver1.7z]http://web.tiscali.it/modifiche/cfg_tserver1.7z[/url]
Here the Tserver1 extract, Cav, can't find an option wich points clearly to abbring; what's the exact optn name?
How it impacts on DCID, if an interaction changes connectid?
-
....sorry - another thought: It looks like CCP is logging on through a Config Proxy - perhaps try logging in centrally? The proxy might be missing a trick...
-
[quote author=Gef Buneri link=topic=9975.msg45429#msg45429 date=1481644345]
[url=http://web.tiscali.it/modifiche/cfg_tserver1.7z]http://web.tiscali.it/modifiche/cfg_tserver1.7z[/url]
Here the Tserver1 extract, Cav, can't find an option wich points clearly to abbring; what's the exact optn name?
How it impacts on DCID, if an interaction changes connectid?
[/quote]
Why would it change the ConnID?? Lets say, you have call A1 entering your Queue, there Entered = 1 for both SS, routes to agent, agent doesn't answer so call goes back to Queue, at this point is a new Entered, but as ConnID is the same, the metric that has DCID will not consider it, but the one that doesn't will count it again, so now you have 2 entered calls for the metric without DCID.
-
Somethimes, when delivering interation on gvp again, to use a play block with gvp app, ConnID changes (seems to be a normal behaviour in a multiple tserver cfg). By the way, the number of changed ConnID (I trace them with prints, through a comparation between original ConnID and post-play-block ConnID) doesn't matches the differences amount in stats.
***EDIT***
I can add another element, don't know if useful; in strategies, I trace call queuing with a stored procedure to which I send some call data, to write informations on a DB, including GROA and VQ selected for targeting by the SelectDN function. Queued calls from CDRs, never match N_ENTERED for the same virtual queue: CCP counts the bigger number, datamart the middlest, CDRs the lesser. Instinctively I would believe CDRs more, 'cause in my mind they count the real call passage.
-
Suggestion: Add a Peg to the Call UDATA as it passes through the Queue(s) and make sure the maximum value cannot be more than "1". Then create a Stat based on the COUNT of Pegs, rather than the TOTAL calls.
-
Hi Adam, thank you for the idea. Ok 'til the peg, but how (and where) can I port the peg result?
-
As an item of UDATA, you can set up a Stat with a Filter based on the KVP.
-
In wich doc do may I find deeper infos on filter formulas syntax?
-
It's been a while since I've used it in practical terms, but:
https://genesys.secure.force.com/support/servlet/fileField?id=0BEU0000000Teqp
Have a look at Chapter 10 - TEvents: <Custom Formulas: Calculating a Local Key-Value List>
-
Thanks a lot, Adam, I'll search in that document.
-
Please let me know how you get on?
-
Hi Adam. CCP numbers are a lot better after reconfiguring stats using DCID as formula in ccp options, and using a time profile set as "00:00" too. Since a couple days ccp n_entered equals datamart (n_entered+n_abb_ring); ccp seems to add abandoned in ring calls to n_entered even if the stat uses only CallEntered as main mask (relative mask is empty, as for DMA stat); ccp process ver. 7.1.
A difference (~2%) remains on certain VQs used to transfer call back to IVR, and I still studying to figure how to use PEG for those VQs, 'cause I never did it before, so I'm trying to understand how to use KVP created with PEG in CCP. (client ver. 7.5).
Regards.
-
If connid changes then attach data would be lost also probably.
You sure ISCC is well configured and being used on all your transfers?
Enviado de meu E6633 usando Tapatalk
-
cav has a point - if you are losing the ConnID, you are probably losing all of the attached data - so a configured KVP "PEG" for reporting purposes might be useless in this scenario...
-
Good point, indeed; by the way, in this case, during the process in wich those VQs work, ConnID does not changes and attach datas remain on the interaction. The only difference between "regular" VQs usage and VQs usage in those strategies, consists in the fact that I use this VQs as "dummy counters", placing two funct. blocks, one to count the event (SelectDN['VQ001',0,'',StatSelectAny,'','','','','','','','','','']), and the other to clear the target (ClearTargets['VQ001']).
-
I think I understand - are you saying "regular" for those VQ's which keep the ConnID - and non-"regular" VQ's for where it loses the ConnID? Are you able to determine if it keeps the attached data, even if it loses the ConnID?
In truth, this now sounds more like a routing/ERS/URS/ORS issue than it does a reporting issue. I think, once you have cleared up the mystery of losing the ConnID, your stats will probably fall into line...
-
Regular is a selectdn over groags+vq that routes call on a destination target (agent in agent group, event counted on vq).
"Non regular" is a selectdn over a vq to count n_entered calls in a strategy that sends the call in another strategy, instead of a groag/ag target.
In both scenarios ConnID usually does not changes, it changes rarely, after a play block I regularly use to play agent id. By the way, the ConnID change seems not to affect numbers.
-
??? ??? ???
but you said DCID did changed numbers, meaning, you had repetitive interactions going on...
Changing ConnID does affect as said, would be counted as 2 instead of 1...that shouldn't happen and you should focus on the WHY. Isolate the scenario and fix it
-
Actually... it makes sense :-[
I'll try to isolate duplicated instances.