How do you track who attended which session at a conference?

Three different questions, one word

“Session tracking” means at least three things, and they need different equipment, different staffing and different budgets.

Most organisers describe the third and budget for the first.

The three are not a progression you can retrofit. If you install single-direction readers at twenty doors and later decide you want dwell time, you do not have a data problem — you have a hardware problem, and the conference has already happened.

Decide which question you are answering before you order anything.

Entry is easy, exit is not

An attendee walking into a session has every reason to cooperate. They want the seat. Scanning is the price of entry and they pay it without being asked twice.

Walking out, they have no reason at all. The talk ended, they are already thinking about coffee, and the person with the scanner is behind them.

Three ways to deal with this. They are not equally good.

Enforce it physically. Turnstiles configured as in-and-out pairs. Nobody leaves without passing a reader. This gives clean dwell data and it is the only approach that does. It is also the most expensive, needs the most floor space, and needs a manual lane beside it for people the gate rejects.

Give people a reason to be counted. This is the approach worth more attention than it gets. If something an attendee wants is gated on dwell — a gift they collect after the session, a certificate, a prize draw among people who stayed — then being counted becomes their interest rather than yours.

Two patterns that work:

Early arrival. Among attendees who accumulate thirty minutes in the room, take the first ten by entry time and notify them to collect something. Rewards arriving on time, which fixes the second-biggest session problem after capacity.

Stayed to the end. Attendees who accumulate an hour can redeem at a desk near the exit once the session closes. The redemption is the exit scan.

The second is the elegant one: you are not asking people to scan out, you are giving them a thing to collect on the way out, and the collection produces the data. Notify by whatever channel your attendees actually read, and say plainly what they qualified for and where to go.

Estimate. Entry scan plus session end time, minus people who obviously left early. It is not measurement and you should not report it as one. If dwell only informs your own planning, it is fine. If it goes to a sponsor or onto a certificate, it is not.

Name your collection points properly

This is the smallest section with the largest consequence.

A device at a door is recording into something. If the operator cannot tell what, and it is the wrong session, nothing looks broken — scans succeed, the screen says success, and the data lands in the wrong bucket. You find out in the debrief, and by then it is unfixable.

Encode enough into the collection point name that an operator holding the device can confirm it against the door they are standing at:

Then bind the device in two steps: a login code that establishes the day and the operator, and a second code that binds this specific device to this specific point. Two scans, ten seconds, and it removes the single most expensive silent failure in the whole operation.

Print the point name large enough to read from a metre away and tape it to the desk. The operator checks the screen against the sign before the first attendee arrives. That is the whole procedure.

Sizing a session door

Registration arrivals spread over hours. Session arrivals do not. Most of a room fills in the ten minutes before the start, and if three parallel tracks start at the same time, all three doors peak simultaneously with the same staff pool.

Size on those ten minutes.

Working ratios for a room of a few hundred:

Gated doors

2–3 in-and-out pairs per room

Manual lane

At least one wherever gates are used

Staff

One per gate pair plus one for the manual lane

Network

~10 Mbps symmetric per room; ~20 Mbps for the largest rooms

Main entrance

Roughly 10 gate pairs, plus 2 manual lanes, for a venue-wide entry point

Queue barriers

~6 per room door; 10+ at a main entrance

Symmetric network matters for the same reason it does at registration: every scan is an upload.

When two rooms share an entrance, and they will, put the shared gates on the busier session and run the other room on a manual lane with a larger team. Do not split gates evenly between two doors that peak at the same minute.

Staff at session doors need a different brief from registration staff. There is no printing, no materials, no queue management to speak of — but there is a refusal, and refusals happen in front of a queue of the person's peers. Give them the words:

This session is invitation-only — let me take you to the organiser's desk.

Never “you're not allowed in.” The volunteer is not the one deciding, and should not sound like they are.

Closed-door sessions

Closed sessions have two viable patterns and one that always fails.

• In the system with an access list. The reader knows who may enter and refuses everyone else. Clean, auditable, and the refusal is impersonal — the device says no, not the volunteer. Needs the list to be right, and it will change on the day.
• Off the system entirely. A printed list and a person who knows the room. Appropriate for genuinely small, genuinely sensitive sessions where the attendee list itself is the confidential thing and should not sit in a system that a hundred volunteers can search.
• What fails: on the system, but with the list not maintained, so the volunteer starts waving people through because refusing is uncomfortable. Now you have a closed session with no access control and a data set that says it was enforced. Worse than either alternative.

Pick one deliberately, per session, and write down which.

The same data plans next year's rooms

Expected size drives room assignment and seating layout, and the only reliable source for expected size is what actually happened last time.

Capture these alongside the attendance data, because they are what make it usable a year later:

• Expected versus actual headcount
• Room capacity and seating layout — theatre, classroom, lounge each hold very different numbers in the same square metres
• Whether the session was open or closed
• Whether it was streamed, and how many watched
• Who ran it — internal team, co-hosted, external organisation

That last one matters more than it looks. Sessions run by outside organisations behave differently: their attendees arrive later, register through different channels, and their headcount forecast is usually optimistic. Knowing which sessions were externally run is what lets you discount the forecast next year instead of over-provisioning the room.

A note on biometrics

Face recognition at session doors is fast and it is available. Before specifying it, check where your event is.

In the EU and UK, facial recognition used to identify people is biometric data under GDPR Article 9. It needs an Article 9 condition — in practice, explicit consent — and consent obtained at a door someone has to pass through is difficult to argue was freely given. Several other jurisdictions have their own rules and they do not agree with each other.

The practical position: make a non-biometric route the primary one — a code on the badge, or a code on the phone — and treat anything biometric as an opt-in alternative in markets where it is clearly permitted, never as the only way in. This is not tax or legal advice; check your own position with a qualified adviser.

Whatever you use, attendance data is personal data. Decide before the event how long you keep it, who can export it, and what a sponsor actually receives — aggregate counts, or names.

What actually goes wrong

The line that belongs on every session-door briefing: capture only exists while someone is standing there. A door with no operator produces no data, and the session looks unattended in the report.

What the data is actually worth

Three things, in rough order of value:

• Sponsor reporting. “Four hundred people attended your session” is a claim. “Four hundred and twelve people entered, average dwell thirty-one minutes, here is the breakdown by attendee category” is a renewal conversation. This is the single strongest commercial argument for doing session capture properly, and it only works if you solved exit.
• Credit and certification. Professional bodies that award credit for attendance need duration, verifiable, per person. Estimated dwell does not qualify.
• Next year's floor plan. The room you undersized and the room you oversized are both expensive, and both are avoidable with one year of real numbers.

Where software actually helps

Four places, and no more:

• One attendee record across registration, session doors and everything else. Deduplication across parallel doors is impossible without it, and it is what makes “already scanned somewhere” a meaningful message rather than a bug.
• Access rules the door can enforce. Session permissions that live with the ticket category, so the refusal is a system decision rather than a volunteer's.
• Live counts per room. Knowing a room is at capacity while the session is filling is the only time that information is useful.
• Offline tolerance. Twenty doors on venue Wi-Fi will have a dropout. The scan has to keep working and reconcile afterwards.

Everything else on this page is naming conventions, floor plans and people standing where they said they would. Those are what determine whether the data exists at all.