In the physical world, real-time monitoring and response is a big deal. To be clear, this isn’t really analytics. The problems that make real-time analytics useless in the digital world (lack of volume to establish significance, inability to read or react in near real-time to data, lack of any natural way to react) are present and usually much worse in people-measurement than in digital analytics.

Yet real-time measurement plays an outsized role in physical spaces for two reasons. First, the value of each visit is quite high relative to a digital property. Second, most locations have some ability to make operational changes that can help address problems or take advantage of conditions as they happen. In particular, the way a location allocates staff is incredibly important to operational efficiency and customer experience; there’s just no equivalent in the digital world (chat – pre AI – is probably the only close corollary).

Because real-time is so important, a people-measurement platform MUST support it. This is especially true since unlike broader reporting and analytics capabilities, most organizations lack a good real-time IT infrastructure and existing real-time monitoring capabilities. That means that a People-Measurement Platform often must meet most or all the required real-time functionality that an organization has. That’s almost never the case when it comes to reporting and analytics.

Basic Views

The most basic real-time capability is simply to show the people (and other tracked objects – cars, etc.) in the space right now.

When you start talking real-time, there’s always the open question of what exactly constitutes “real-time”. People-measurement sensors will often have a short delay baked into what they do. Sometimes that’s a processing delay and sometimes it’s simply a delay baked into the transmission of data. For lidar, the data from the Perception software is usually available within 1 or at most 2 seconds of real-time. For camera, the data is usually available within 1 second but it might also be grouped into batches of 5 seconds. A People-Measurement Platform shouldn’t add much to this (say another second) except where you are asking it to do track stitching. Good stitching often requires that data be delayed anywhere from 5-15 seconds.

Best case, then, is your real-time visualization will lag what’s happening by a second or less. Worst case, it might lag about 20 seconds (5 second batch and 15 seconds for stitching buffers). For most applications, anything in that range will be acceptable, but there are times where you’ll really need to be closer to the 1 second than 20 seconds. Fortunately, that’s nearly always achievable albeit with some loss of quality in stitching.

Occupancy

Seeing where people are and what they are doing is sometimes all that’s necessary. But in most cases, you want your People-Measurement Platform to provide basic counting as well. This comes in three forms: occupancy, usage, and queue metrics.

Occupancy is the number of people in an area (the whole location or any defined zone) right now. Usage is the number of people who have used an area over some specified period of time (like today) or since some event (like a cleaning). Queue metrics are a little more complicated and I’ll break them out separately.

You can see that in the real-time view above, the current occupancy is being tracked constantly. However, location-wide occupancy isn’t usually the most interesting thing. Typically, you’ll want to be able to track the real-time occupancy of defined areas in a view like this:

Queue Management

Managing lines is one of the most common and important areas of real-time people measurement. Real-time queue metrics include line depth, estimated wait times, stations open, and average processing times. Because queues are complicated, there may be a host of other metrics worth considering, but these four are the most common and the most important.

Line depth may just fall-out of basic occupancy measurement. The line depth can often be calculated as the number of people standing in an area defined as the line. There may, however, be complications. In retail (and some other scenarios), it can be quite important to measure line depth in terms of groups not individuals. Estimated wait times are always more complicated, They are typically a basic calculation of the number of people or groups in line divided by the number of stations processing the line times the average transaction time per person or group. Even this basic description probably suggests the wide range of complications and assumptions that often lie behind wait time measurement. The number of stations open is critical for that basic calculation but it’s also an important metric on its own. The main lever a manager has for managing lines is opening or closing stations; obviously, that means knowing how many stations are open/closed essential. Average processing times are sometimes an assigned value, sometimes an historically derived value (possibly with a weight average) and sometimes a calculated value (based, for example, on the group sizes in line). As a metric, however, it can help managers understand recent performance and help identify potential trouble spots.

Alerting

Providing basic metrics and monitoring on what’s happening right now is pretty much table-stakes in people measurement. Sometimes, these basic monitoring capabilities are all you will need. Usually, though, you’ll want to supplement monitoring with alerting.

A people-measurement alerting systems lets you trigger notifications in response to conditions in a location or with a specific shopper journey. There are two main dimensions for evaluating the alerting capabilities of a People-measurement platform. The first, and probably the most differentiated, is the range of rules that can be used to trigger notifications. The second is the range of delivery options available for a notification.

The most basic (and common) alerting triggers involve simple thresholds around key metrics in a space, the same metrics discussed above. It will often make sense to trigger alerts based on occupancy in an area, usage of an area, or core queue metrics like estimated wait time. More advanced alerting capabilities involve the use of journey metrics (dwells, enters, exits) to trigger alerts AND journey metrics to calculate the underlying triggering metric (STARs ratio, Previous Visit or Dwell).

Of these more advanced metrics, dwell time triggers are probably the most important and frequently used – in retail and in other verticals as well.

The most common alert delivery mechanisms are email and SMS. But you’ll also want a People-Measurement Platform to be able to deliver alerts inside the platform and (to be covered next) in ways that make it easy to integrate alerting into your own Apps or applications. This last is probably the single most common and important method of integrating alerting and it should not be overlooked.

Feeds

For all the same reasons (and more) that I listed in describing why the Distribution layer is so fundamental to people-measurement, you need to be able to get people-measurement data in real-time. Why not just take a real-time feed from the sensor? Because if you do that, you lose all the benefits of mapping and data cleaning in the people-measurement platform. That sucks. It also dramatically increases the amount of work involved in rolling out basic applications around queue or crowd management.

A good real-time feed should let you select the level of cleaning (and delay) you need. It should take advantage of the mapping baked into the People-Measurement Platform. And it should provide direct and easy access to derived metrics (like estimated wait times).

At a more advanced level, it’s awesome if the realtime feed extends the basic people-measurement functionality by including things like Associate detection, group detection, interaction detection, and zone-based segmentation. Delivering these capabilities in the feed just makes it easier for your dev teams to bake real-time people measurement data into whatever apps or applications they are trying to build.

From queue management to dynamic associate allocation, many of the highest ROI use-cases for people-measurement require real-time capabilities from your People-Measurement Platform. Those use-cases will almost always require basic tracking in near real-time, but will often require integration into the platforms underlying capabilities for mapping and cleaning as well. And because most organizations don’t have a robust real-time stack, the more extensive the People-Measurement Platform’s capabilities and the more turnkey it can make additional development, the easier it will be for you to capture the value from those use-cases.