As mentioned in the Average Person Count definition, VergeSense generally aggregates metrics at the hourly level. While sensor data is typically collected much more frequently, rolling up these reports to a standardized period of time allows us to easily compute metrics across larger time windows, different hardware types or sources (such as Wi-Fi data), and varied spaces.
In the simplest of cases, the Peak Person Count is just the maximum number of people observed in a given time period. This is what we are reporting at the lowest level - specifically:
- Individual spaces (e.g., a single meeting room, desk, office, etc)
- Individual sets of spaces (e.g., a single building, floor, a floor's Space Type, a floor's Space Group)
While this calculation is easy to follow for a single space, it's more complicated for two or more spaces. Consider the following example of the hourly data model for a floor with two spaces:
| Floor 1 | ||
| Space | Hour | Peak Person Count |
| Conference Room A | 8am - 9am | 2 |
| Conference Room B | 6 | |
| Conference Room A | 9am - 10am | 8 |
| Conference Room B | 0 | |
| Conference Room A | 10am - 11am | 5 |
| Conference Room B | 4 | |
It's easy to determine the Peak Person Count for Conference Room A (8 people, during the 9am hour) and for Conference Room B (6 people, during the 8am hour). But the Peak Person Count for the entire floor is more complex.
One approach might be to sum the Peak Person Counts by hour to determine that 9 is the correct answer (5+4, during the 10am hour). However, this may in fact not be the case if the peaks (5 and 4) didn't actually occur at the same time. It's possible that 5 people had a meeting in Conference Room A from 10am until 10:25am, while the 4 people in Conference Room B didn't show up until a meeting at 10:30am. For all we know, the 4 people in the later meeting might even be the same people who just wrapped up a meeting in the prior room. In this example, clearly it would be wrong to claim that 9 people were present on Floor 1 at any point in time.
To handle this, (in almost all cases*), we have computed the hourly peak person counts down to the second, specifically to avoid the error in the above example. For instance, if we zoom in to the start of the 8am hour in our Floor 1 example, we might see something like this:
| Floor 1 | |||
| Space | hh:mm:ss | Person Count | Floor Person Count |
| Conference Room A | 8:00:00 | 0 | 6 |
| Conference Room B | 6 | ||
| Conference Room A | 8:00:01 | 1 | 7 |
| Conference Room B | 6 | ||
| Conference Room A | 8:00:02 | 1 | 6 |
| Conference Room B | 5 | ||
| Conference Room A | 8:00:03 | 2 | 5 |
| Conference Room B | 3 | ||
| ... | |||
Bear in mind that this is a simplified example over a shortened period of time, but grounded in a real scenario in which a meeting in Conference Room B has just finished and has people filing out of the room at the same time that a meeting in Conference Room A is just getting underway.
Zooming back out to the hourly level, we might now see the following data for Peak Person Count for the floor:
| Floor 1 | |||
| Space | Hour | Peak Person Count | Floor Peak Person Count |
| Conference Room A | 8am - 9am | 2 | 7 |
| Conference Room B | 6 | ||
| Conference Room A | 9am - 10am | 8 | 8 |
| Conference Room B | 0 | ||
| Conference Room A | 10am - 11am | 5 | 6 |
| Conference Room B | 4 | ||
Using this method, it's easy to see that the Peak Person Count for Floor 1 was 8 people, which occurred during the 9am hour.
*You might be wondering why we can't use this technique in 100% of cases. In short, it's computationally difficult to line up second-by-second data for a set of spaces, so while this logic is applied in the vast majority of queries, there are instances where we revert to a more basic model. Specifically, this simplified logic applies to metrics spanning two or more buildings, floors, space types, space groups or spaces.
Updated
Comments
0 comments
Article is closed for comments.