How are Breakdown Aggregations calculated?

[Chris W1]

Hi Everyone,

I have been working through the conversion of some manual reporting coworkers have been doing and ran into a new use case (for me) - showing the aggregated value of multiple breakdown elements instead of separate values. 

I have:

• created multiple formula indicators that calculate a percentage scores for various participation metrics, having replicated some excel formulas in the formulas. 
• Added widgets to a dashboard that leverage these formula indicators
• Added breakdowns to the indicators and to the dashboard

Users are then selected as a breakdown elements on the dashboard to see, depending on use cases either:

1. individual scores (elements shown separately) or
2. wrapped up scores across multiple users (elements aggregated)

However, I am finding that the aggregated value that the indicators are providing is not aligned with the expected outcome from the manual reports which is the mean average. (Aggregation is also not providing the median either)

EDIT: just to note that the automated indicators are collecting the expected data and the formulas work at a per-user level, the issue is only seen when aggregating, hence why I am trying to understand what/how the aggregation works.

Can anyone provide some background/context on what the expected mathematical outcome is when using an aggregation of multiple breakdown elements please?  Or perhaps I've made an error that I have overlooked?

[jeffrubinoff]

Could you be seeing the difference between applying the aggregation to the result of the formula versus applying the aggregation to each contributing indicator and then calculating the formula? These two approaches are not mathematically equivalent. Please see https://docs.servicenow.com/bundle/vancouver-now-intelligence/page/use/performance-analytics/concept...

[Chris W1]

Hi @jeffrubinoff , in reviewing the details in the link you provided (thankyou!) that appears to be for when using a default time series within the indicators, which I am not doing. I am just doing a simple widget with month-by-month time series column chart. And again, the scores are correct when multiple elements are set to separate but incorrect when set to aggregate.

In the interest of thoroughness, I went into a sub-production instance and checked that box for all of my indicators but the scores did not change.

Is there any kind of explanation that shows how the aggregation is calculated? Should it be an average of the elements? Could it be broken (and be a support case?)

[jeffrubinoff]

Chris,

From the doc:
"This option applies to any time series aggregation you apply to the indicator in Core UI Performance Analytics widgets and Analytics Hub, or in Data visualizations in configurable workspaces. This option also applies to the default time series if one is set on the indicator."

[jeffrubinoff]

Ok, there are a lot of things called an "aggregation." Do you mean the aggregate view of multiple elements on a widget? That is a simple sum of the elements. I am surprised you get meaningful results at all. I would think the answer you need is not to show aggregate of elements but to have another indicator that is not broken down by user. That can show you the total for all users.

[Chris W1]

Hi @jeffrubinoff ,

Thanks for the further responses, they are very much appreciated. 

To answer your question: yes I mean the aggregate view of multiple elements on a widget. Thanks to that image, I am now disabused of the notion that I should expect a mathematically meaningful answer from that aggregation, which is unfortunate, but I guess makes sense.

To your suggestion about having indicator that is not broken down by user, that indicator exists and is accurate. The use case here is that the data is being collected for multiple users across multiple teams and the intent of the aggregation widget was to show a wrapped up version for each team by selecting users on that team as breakdown elements.

This was to avoid having to create one or many indicator sources and/or indicators that use people's names in hard coded in their conditions as that is a known bad practice, as people come and go and these conditions would require updates over time.

Does anyone have other ideas of how to solve for this use case?