An event attendance total should be explainable from a ledger of authorized admissions. Scanning a code is an input signal, not the final attendance fact.
This guide is part of the NexisHub Event Technology desk. It connects practical engineering, research, and product decisions to the wider NexisHub platform.
The operating idea
Imagine 500 tickets issued, 430 successful scans, 19 retries, 8 rejected entries and 12 staff overrides. Which number should the organizer call attendance? A system that answers '469 scans' without defining these categories is not a reliable record.
This is a hypothetical worked example for event product architecture. The figures are teaching inputs, not NexisHub operating statistics or a report about a real client.
NexisHub separates verified platform documentation, repeatable observation, and inference. No optimization can guarantee selection or citation by an external system.
Worked tally: scans are not people
Start with an append-only scan event table. Each event has an event ID, credential reference, gate, device, request ID, time and outcome. The event table may contain a successful admission followed by several retries. Count the authorized, unique admission transitions, not the number of rows in the scan log.
If 430 successful scan records include 19 idempotent retries, the accepted admission count may be 411 before considering re-entry and any valid overrides. The exact number depends on whether retries were included in the reported success group and whether the event policy allows multiple admissions. Do not infer the unique count from aggregated labels when the underlying events are unavailable.
A safe reconciliation report
An organizer's report should expose issued registrations, active ticket eligibility, distinct admitted credentials, manual entries, rejected attempts, offline conflicts and unresolved exceptions. Every number should have a query definition and a timestamp so a reviewer can reproduce it.
Keep identity data out of broad summary views by default. The public dashboard may need only counts and trends, whereas individual admissions should be limited to authorized event staff with a recorded operational purpose. Aggregate carefully for small groups where attendance itself could disclose sensitive facts.
Privacy and retention are design inputs
QR codes should not embed a person's name, date of birth or phone number just because it simplifies a scan screen. Prefer a short opaque identifier or a properly scoped signed token. Expose only the data required to make the admission decision.
Define retention separately for attendance proof, payment reconciliation, fraud investigation and optional engagement analysis. Obtain the organizer's actual privacy and contractual requirements; do not claim that a generic retention period satisfies every jurisdiction.
Core principles
- Keep a unique event ledgerRecord raw scan attempts separately from successful admission state transitions.
- Document metric definitionsEvery chart should specify its numerator, denominator, filters and time range.
- Minimize exposed identityGate displays should reveal only data needed to resolve admission.
- Make corrections auditableStaff overrides and reversals need reasons, roles and timestamps.
A practical implementation workflow
Apply the work in a controlled sequence. Keep a baseline, name an owner, and define the evidence that will show whether each step was completed.
- 1. Define admission and re-entryDocument how transfers, re-entry, cancellations and manual admissions count.
- 2. Design scan event fieldsInclude an event identifier, credential reference, device and outcome code.
- 3. Apply transactional acceptanceAllow one authorized transition per required admission unit despite concurrency.
- 4. Produce reproducible aggregatesGroup by distinct accepted transitions and report unresolved exceptions separately.
- 5. Exercise privacy and export controlsTest role isolation, least-privilege exports, retention and deletion pathways.
Common mistakes
Counting every scan as attendance
Retries and rejected credentials inflate apparent turnout.
Embedding identity in the QR code
Anyone who sees or photographs the code may read unintended personal information.
Editing past events silently
Untracked manual changes make reports impossible to reconcile.
How to measure it responsibly
Test that repeated requests with the same idempotency key preserve one admission and a stable outcome; then test distinct concurrent keys targeting the same ticket.
Reconcile the aggregate report with the underlying accepted-transition ledger and ensure role-based exports cannot expose unauthorized attendee records.
Keep observed outputs, diagnostic scores, inferred causes, and business outcomes in separate fields. A modelled score is not a citation, and correlation is not proof of cause.
What comes next
Reliable attendance analytics can later inform queue staffing, venue operations and event planning, but predictive claims need verified historical data and clear uncertainty boundaries.
The durable response is to build pages that are accessible, semantically explicit, useful outside their original layout, and backed by evidence a reader can inspect.
Key takeaways
01A scan attempt and an admitted attendee are different units.
02Metrics need reproducible definitions and timestamps.
03Opaque credentials reduce accidental identity exposure.
04Corrections should preserve traceability instead of rewriting history.
Frequently asked questions
Should a rejected scan count toward attendance?
No. It may be counted in operational diagnostics, but it should not be counted as an authorized admission.
Do 430 successful scan events prove 430 people attended?
Not necessarily. Re-entry and retries may produce multiple events. Deduplicate using the event's explicit admission rules.
Can organizers export all attendee data?
Exports should require authorization, purpose checks and the event's privacy and retention rules.
References and further reading
Turn a useful idea into a maintainable product.
Nexis Studio helps organisations move from problem definition to product design, engineering, launch, and long-term support with clear technical and commercial boundaries.
Explore Nexis Studio