Averages on a Formula Indicator

[Josh Cooper]

I recently had a question come up from one of my customers, and it seemed like it could be a bit tricky, so I thought I'd put it out here for consideration as well.

They were looking at the "Average Time to Resolve an Incident" indicator - when they changed it to By Month Sum +, it jumped to a huge number and they wanted me to make sure it was working.

After considering it for a bit, I understood what it was doing - I had gotten caught up in their way of thinking during the explanation, but when you ask for a by Month Sum +, it's literally adding up the results it receives for each day.   So if Day 1 is 2 hrs, Day 2 is 3 hrs and Day 3 is 6 hrs, then the by Month Sum + on Day 3 would be 11 hrs.   Which is exactly what they asked for, but not very useful.

I determined that any such sum wouldn't be very useful, so I went and changed it to a by Month Avg+ and added all the Sums for to the excluded time series for that indicator.   But after thinking about it for a bit, actually as I was documenting the solution, I realized that wasn't the right answer either.   Because again, it's only working with the products for the time series aggregations.   So in our example above, if Day 1 is 2 hrs, Day 2 is 3 hrs, and Day 3 is 6 hrs, then the by Month Avg + on day 3 would something close to 4hrs.   That's a lot more believable number, which is why I almost didn't catch it.

The problem when you do the Average of an Average, you lose the scale -   it works fine if every day is the same, but if Day 1 is 100 tickets, Day 2 is 100 tickets, and Day 3 is 1000 tickets, then the real average time is a lot closer to 6 than it is to 4.

So the right answer is to recreate a Formula indicator (insert and stay on the existing one) and name it to "<Indicator> Monthly Avg" then use the same indicators, but force the 'by Month Sum +' time series on each.   Now the results you get will be the most accurate.

[Daniel Oderbolz]

Dear Jason
Dear Josh

Thanks a lot for your swift answers!
We will try this approach using ATSTR.

Since we are not calculating an average in our case, the percentage issue should not come up.

Best
Daniel