Baseline Metrics

Overview

Baseline Metrics is a new set of metrics we have worked hard to develop that provide better usability and flexibility when compared to all other metrics. The meaning of the metrics is effectively identical, but the calculations are done at the lowest possible level. These metrics can be used in place of the previously distinct Space, Team, Neighborhood, Floor or Building metrics.

Benefits

The benefits of Baseline Metrics are:

1. Metrics you can use when you aren’t sure what metrics to use.

For example, When should I use Space Metrics vs Team Metrics vs Floor Metrics? This benefit is for all Insight Editors of all skill levels, if you aren’t sure which metrics to use, you can just use Baseline. This will save time, effort, and needing to understand the sometimes complex behavior of the metrics.

2. Metrics that are more flexible and allow for more types of filtering and dimensions.

For example, using Baseline you could now have sensible results for neighborhoods in dashboards that have filters on both Org Unit filter AND Space Type. Previously, having both of these filters would only make sense for non-neighborhood teams regardless of the metrics used.

How does Baseline Metrics work?

Baseline works by calculating metrics to the lowest possible level in the Location Hierarchy. This is usually (but not always) against a space, but depending on circumstances it can include teams, neighborhoods, zones and floors. Additionally, for spaces in Neighborhoods, the metrics are sub-divided and calculated per space per team in the neighborhood. The calculations themselves are somewhat complex, but their meaning is the same.

How are Baseline Metrics different?

Although the meaning of metrics is not different (occupied workpoints is still a count of workpoints that have a person assignment or a retention status, thus ‘occupied’), the exact calculations are a bit different.

1. First, metrics are now calculated at a decimal level and portioned. This is to allow values in neighborhoods to be more precise. For example, if a neighborhood contained 20 workpoints and a stacked team with 10 workpoints and 10 people assigned to it, the neighborhood would have 10 occupied workpoints. However, each individual workpoint would be 0.5 occupied. If you now imagine that half the neighborhood is ‘Sit-Stand’ and half is ‘Desk: Standard’, then it would be accurate to say the neighborhood has 5 ‘Desk: Sit-Stand’ occupied workpoints and 5 ‘Desk: Standard’ occupied workpoints.
2. Second, for floors with 0 spaces (i.e. no floorplan), the Insights calculates the specific Baseline value. This means currently, unlike the rest of metrics, all Baseline Metrics are expected to work correctly on floors with no floorplan.
3. Third, there are some minor differences in logic. Notably, wherever there are spaces in neighborhoods that are fixed, you can expect Baseline Metrics to differ from floor metrics in aggregate. By deciding to portion out spaces in neighborhoods (metrics-wise) to teams in the neighborhood, we had to make business logic decisions.  For example, imagine a neighborhood has 10 workpoints, 5 of which are marked as fixed but empty. Also in that neighborhood is a team stacked with 10 workpoints and 10 people. How many workpoints should be considered occupied? We decided that the answer to that above situation is '5' as the spaces that are fixed (and empty) are not shareable by anyone. If they were, they would be marked as fixed. Therefore, they are treated in a similar way to normal, unallocated, fixed workpoints.

Why is my result set different?

To facilitate these aggregations, the join for metrics to locations needed to change. Previously, if you asked, ‘What spaces belong to X org unit?’, you would ONLY get a list of spaces directly allocated to that org unit. For teams in neighborhoods with that org unit, you would get nothing. This is why using Space Metrics ‘Total Workpoints’ would be limited, as for teams in neighborhoods you would get nothing.

Now, with Baseline, you will get a value equal to what portion of physical workpoints they could get. If a neighborhood is not over-stacked or over-blocked, this will match their stacked workpoints. 

Since we had to edit the join, were you to list space names for that org unit, you would get every space in that neighborhood that team has a portion of. This can also lead to spaces appearing multiple times across multiple org units. Each space in that neighborhood has a join to each team in that neighborhood. You can prevent this behavior by using the Include Indirect? filter on the Baseline Metrics view. If you set this to no, you will get the same result set as you would previously, but Baseline Metrics will now function very similar to space metrics and not be portioned out to teams.

Are all metrics in the Baseline Metrics?

As of yet, no. Some metrics cannot be ever ported (such as people counts) as they need to remove duplicates. There are too many permutations to calculate and no way to portion it. Therefore, if you need such a metric its recommended you do this by counting person ids.

Other metrics we simply have not gotten to yet, as they are a lower priority. These gaps may be filled in at a later date. The most used metrics are all included.

Some of my results are wrong, what could the issue be?

First, check the Assignments (Data Quality) Dashboard. Just like with all other metrics, things like over-blocking, over-stacking, and other such exceptions can cause issues with Baseline Metrics. If you come across issues, check the Data Quality dashboard to correct any exceptions.

Another reason you may see differences is Baseline Metrics are calculated as decimals.  For example, previously, the Total Workpoints and Assignment Capacity metrics were exclusively integers.  Calculating as decimals allows for more precise values then previously shown.  This is true for derived ratios and, especially for shared spaces, as we’re now presenting, side-by-side, records apportioned to multiple groupings. For example, a team with 10 workpoints and a target ratio of 1.24 will have an Assignment Capacity of 12.4. It’s also necessary to do this as decimals to do proper portioning. These decimal places can lead to small differences in aggregate.