Login Time - Hyperion vs. Stat Server Table

[Michael]

Hey Everyone,

We are currently having an issue with reporting (CCA/DMA 7.2 w/ Stat Server 7.5) where the T_Login does not equal the “Login” time from the stat server “Status” table (Status table and ODS/DM stats provided by the same stat server). The T_Login stat has been in production since 2003 and has remained unchanged.

The T_Login stat configuration is:
Name: Total_Login_Time
Category: Total Time
Subject: AgentStatus
Objects: Agent, GroupAgents, GroupPlaces, Place
Main Mask: *, ~LoggedOut, ~NotMonitored

Our business line is comparing the WFM (6.5) Agent Status Report, a custom Hyperion (8.5) report, and direct SQL (2005) query results from the Status table for adherence purposes. The WFM report and the SQL query are “right on” (Total Login Time of 5.08 hours) if you allow for minimal rounding. However, the Hyperion report using T_Login shows only 4.89 hours for a difference of .19 hours or 11.4 minutes. This difference can be quite significant when incentive compensation is tied to adherence.

I’ve confirmed within the Hyperion report that T_Login DOES equal the sum total of all other statuses combined. I’ve also confirmed that the raw data in the DataMart reflects what is reported in Hyperion. I've also confirmed in DMA that there is no other stat configured to capture T_Login.

Any direction / information on what may be causing the differences is appreciated.

Thank you.
Mike

[cavagnaro]

Maybe that ~NotMonitored, few seconds each time that your agent/extension is not being monitored by some reason, call it network, delay, etc.

[Michael]

Cavagnaro,

Thanks for the response. I did some further research and I've narrowed down the variances and the values are off for several different statistics. (See table below)

Hyperion Status Table Status Difference
1680 1760                 Consult 80
13231 13633                 Inbound 402
611 760                 Hold 149
69 72                 Ringing 3
1467 1467                 NR 0
1 1                 Off-Hook 0
532 549                 Wait 17
17591 18242                 Total [b]651[/b]

This is a difference of almost 11 minutes. I've confirmed the statistical setup of each stat in question and found no discrepancies. Maybe I missed something somewhere but I haven't seen any Release Notes on this issue either.

Any other suggestions are appreciated.

Mike

[cavagnaro]

Ok but again, you are not couting/adding the time that your extension is on NotMonitored Status...

[fnunezsa]

Did you check the time profile used in your DMA Report Layout? When is it resetting values to 0?

[borkokrz]

I don't think this is caused by DNs not being monitored, cause this SS is the same source for StatTable and DM. So it should have identical impact on both. I had also an idea - problem with time on server hosting SS (ntp problem?). But this also should have no impact, if this is only one stat server.

[ExodusSS]

I promised myself I wouldn't return, but..... 

Could you also supply the Total Calls for the same period, from each source?

A few things:

"Custom Hyperion Report" - make sure that there are no custom data columns.  Sometimes you find that, although the Column heading states "T_Login", it is not a pure Statistic and it may have an equation or some other calculation sitting behind it.  Be absolutely sure the stat is actually what it says it is.

Comparison of WfM stats, Hyperion/CCA/DMA [i]and [/i]a direct SQL Query seems a bit overkill, even if the business intention is to confirm timings which are tied with incentives for Agents.  WfM works different to CCA...

The stat composition for T_Login contains "*" - that means any other "unknown" status is not counted, along with NotMonitored and LoggedOut. Can you be sure that this is the same for the Status Table and the "pure" Stat for Hyperion?

As a suggestion: Go with CCA/Hyperion for your timings - WfM Status Table is based on Interactions and "Tries", not Calls....

[Michael]

Thanks to everyone for their help on this!

Good news / Bad news depending on your persepctive I guess but while confirming the answers to the questions below, I discovered that DataSourcer had an 11 minute outage during the example timeframe supplied by the business line. This amount of time is pretty much exactly the amount of the missing time in question.

I had the business line confirm that all data sources pre and post the outage matched and they do.

So... good news... no issue with stats. Bad news... DataSourcer experienced an outage. So off I go to investigate the DataSourcer outage now.

Thanks again to everyone who offered assistance on this.
Mike

[cavagnaro]

[quote author=InfluxSS link=topic=6663.msg28992#msg28992 date=1316155148]
I promised myself I wouldn't return, but..... 

[/quote]

Lol! My prediction was right T or Ex now lol
May I say welcome back? At least in a low profile? 

[ExodusSS]

Hummmm - low profile - yes.... lol

[quote author=cavagnaro link=topic=6663.msg28999#msg28999 date=1316187188]
[quote author=InfluxSS link=topic=6663.msg28992#msg28992 date=1316155148]
I promised myself I wouldn't return, but..... 

[/quote]

Lol! My prediction was right T or Ex now lol
May I say welcome back? At least in a low profile? 
[/quote]