How is running show floor occupancy calculated?

Reset a counter to zero each morning, add every entry read and subtract every exit read in timestamp order, and the counter is running occupancy. Peak occupancy is that counter's maximum during open hours. The calculation is trivial, and its accuracy depends entirely on whether exits are captured as reliably as entries.

Why does occupancy drift upward through the day?

Exit reads are missed far more often than entry reads, because entry is enforced by access control and departure is not. Every missed exit leaves a phantom person in the hall for the rest of the day. On a day with 12,700 entries and 8,900 recorded exits, the counter finishes at 3,800 when the true figure is close to zero.

How do you correct occupancy drift from missed exit scans?

Start with a close-of-day reconciliation, which forces the counter to zero after the hall clears and gives you an exit capture rate. Where an independent count is available during the day, combine it with the running figure using a Kalman update, weighting each by its variance so the corrected estimate sits between them.

Calculating peak show floor occupancy from entry and exit scans

Attendee analyticsUpdated 2026-08-187 min read

In short

Peak show floor occupancy is the highest value of running occupancy during an open day, where running occupancy is the cumulative count of entries minus exits since the hall opened. Missed exit reads push the series upward through the day, so reconcile it against a close-of-day value of zero and against hall capacity before reporting a peak.

At 16:00 on day two the show office dashboard says there are 9,100 people in hall one. The hall's licensed capacity is 6,500. Nobody in the room believes the figure, the safety officer asks a pointed question, and the dashboard loses its credibility for the rest of the show.

Peak show floor occupancy is the simplest calculation in on-site analytics and one of the easiest to get wrong. Running occupancy is a cumulative sum: reset to zero each morning, add an entry, subtract an exit, and read the counter. The arithmetic behaves perfectly. What breaks it is that entries and exits get measured with very different care, and the gap between them accumulates all day.

The cumulative sum, and the moment it becomes impossible

Day two, hall one. The access control system logs 12,700 entry reads and 8,900 exit reads across the open day.

Run the cumulative sum and by 16:00 the counter has taken 11,800 entries and 2,700 exits, giving 9,100. At close it has taken all 12,700 entries and all 8,900 exits, giving 3,800.

Two of those numbers are impossible. The hall holds 6,500, so 9,100 cannot have been inside it. And the hall was empty by 18:40, so the close-of-day figure has to be zero rather than 3,800. Both impossibilities have the same cause and the same sign, which is the useful part: the error only ever pushes the figure up.

That directional property is worth stating to anyone who reads the dashboard. A running occupancy built from unreconciled scans is an upper bound. It is never too low.

How big is the drift, exactly?

Divide. Recorded exits over recorded entries is 8,900 divided by 12,700, which is 0.701. So 70.1 per cent of departures were captured and 29.9 per cent were not.

That ratio is the single most useful diagnostic you can produce from an access control export, and almost nobody computes it. It tells you the exit side of your gate configuration is missing three departures in ten, which will show up in dwell time, in reentry classification and in every occupancy figure the show produces.

The reason is structural. Entry is enforced because there is a turnstile, a badge check and a queue. Departure has nothing enforcing it: people leave through a fire door, walk out beside a reader that only scans on the inbound side, or leave in a group where one badge opens the gate for four people. Fixing the ratio is a hardware and stewarding job, and it is worth costing before you spend anything on modelling around it.

A close-of-day reconciliation, and where it runs out

The obvious correction uses the fact you already have. If occupancy must be zero at close, then 3,800 exits went unrecorded, and every recorded exit can be inflated by 12,700 divided by 8,900, which is 1.427.

Apply that factor and the 16:00 figure becomes 11,800 minus 2,700 times 1.427, which is 11,800 minus 3,853, or 7,947. The close-of-day figure becomes zero by construction.

The 16:00 figure is still above the hall's 6,500 capacity, by 1,447. The single global factor has not saved it, and the residual is informative rather than embarrassing. It says the unrecorded exits were concentrated earlier in the day than the recorded ones, which is exactly what happens when stewards prop the gates open during the busiest period and stop enforcing anything at all.

So a flat multiplier is a first pass. It removes the end-of-day nonsense and leaves the mid-afternoon nonsense in place.

Treating occupancy as a state you estimate

The better framing is to stop treating running occupancy as a measurement and treat it as an estimate of a hidden quantity, with a known tendency to drift and an uncertainty that grows the longer it goes without a correction.

That is the problem Kalman set out in the ASME Journal of Basic Engineering in 1960, and the structure transfers directly. There is a state, which is the true number of people inside. There is a process model, which says today's occupancy is yesterday's plus entries minus exits, with noise. There are measurements, each with its own error. Faragher's 2012 derivation in IEEE Signal Processing Magazine is the clearest short account of why the update takes the form it does, and it needs nothing beyond multiplying two Gaussians together.

The update is one line of arithmetic. Suppose at 16:00 the filter's prediction is 7,947 with a standard deviation of 900, so a variance of 810,000. A steward sweep counts the hall independently and reports 6,100 with a standard deviation of 400, so a variance of 160,000.

The gain is the prediction variance over the sum of the two variances: 810,000 divided by 970,000, which is 0.835.

The corrected estimate is the prediction plus the gain times the difference: 7,947 plus 0.835 times minus 1,847, which is 7,947 minus 1,542, or 6,405.

The corrected variance is one minus the gain, times the prediction variance: 0.165 times 810,000, which is 133,650, a standard deviation of 366.

Read what the gain did. The manual count was far more precise than the drifting cumulative sum, so the filter moved most of the way toward it and finished with an uncertainty smaller than either input on its own. Two hours later, with no further corrections and the drift accumulating again, the variance will have grown and the next manual count will pull harder.

You do not need a library for this. One steward sweep at 11:30 and one at 15:30, each entered into a spreadsheet with an honest error estimate, will do more for the credibility of your occupancy figure than any amount of sensor procurement.

What is the peak, and when should you report it?

Report the peak as a bin rather than an instant, and always with the window attached.

An instantaneous maximum of a scan-driven series is dominated by whichever second had the largest burst of reads, and it is not reproducible. Smooth to five-minute bins, take the maximum of the smoothed series, and say so: peak occupancy of 6,405 in the five minutes from 15:55, corrected against a steward count. Anyone can then ask a sensible question about it.

Report the capacity alongside it, every time. A peak occupancy without the hall's capacity next to it invites the reader to supply their own, and they will get it wrong. The pair of numbers is what the safety officer, the venue and the insurer all want, and it turns a curiosity into a document.

Say what the figure covers in the same sentence you report it. Peak occupancy is a maximum concurrent count, and it carries no information about how many distinct people attended across the day. Those are separate metrics with separate definitions and separate owners.

Where this stops

Everything above assumes the entry count is right, and it is the assumption most likely to fail quietly. Doorway counting accuracy falls exactly when a crowd arrives as a tight group, which is when the peak happens, so the error budget on the counting device itself belongs in the same report and belongs to C19.

The method also assumes a hall is a closed volume with instrumented boundaries. Halls connected by a concourse, a mezzanine link or a hotel bridge are one volume for the purposes of safety and several volumes for the purposes of scanning, and any door that is not counted appears as an entry that never leaves or an exit that never arrived. Inventory the doors before you argue about the arithmetic.

The last limit is the most important one for how you use the figure. Peak occupancy is a hall-level number and hall-level numbers hide everything operational, because a hall at 60 per cent of capacity can have an aisle at Fruin level E in the middle of it. The occupancy figure will look comfortable while a steward is calling for help, which is why density measured over a defined aisle area in C11 belongs on the same screen, and why the shape of the day matters more than its maximum, which is decomposing the traffic pattern in C12. Read together, the three of them give the attendee analytics view a show office can actually work from.

This week, take last edition's access control export and compute one number: recorded exits divided by recorded entries, per day and per door. If any door comes back under 50 per cent, that door is producing phantom occupancy all day and no correction applied afterwards will fully clean it. Fix the reader before the next edition and you will have removed most of the problem at source.

Questions people ask about peak show floor occupancy

How is running show floor occupancy calculated?: Reset a counter to zero each morning, add every entry read and subtract every exit read in timestamp order, and the counter is running occupancy. Peak occupancy is that counter's maximum during open hours. The calculation is trivial, and its accuracy depends entirely on whether exits are captured as reliably as entries.
Why does occupancy drift upward through the day?: Exit reads are missed far more often than entry reads, because entry is enforced by access control and departure is not. Every missed exit leaves a phantom person in the hall for the rest of the day. On a day with 12,700 entries and 8,900 recorded exits, the counter finishes at 3,800 when the true figure is close to zero.
How do you correct occupancy drift from missed exit scans?: Start with a close-of-day reconciliation, which forces the counter to zero after the hall clears and gives you an exit capture rate. Where an independent count is available during the day, combine it with the running figure using a Kalman update, weighting each by its variance so the corrected estimate sits between them.