How to handle duplicate badge scans without deleting real second conversations

The stand manager for a 400 square metre booth rang the show office on the Thursday afternoon of a three day event. His team had scanned, by their own tally on the lead retrieval app, more than 1,600 badges. The exhibitor portal was showing 1,340. He wanted the missing 260 back.

Nothing was missing. The 260 were duplicate badge scans by the definition of a rule written years earlier by somebody who had since left the business, which collapsed every repeat scan of the same badge by the same exhibitor into one row. Some of those 260 were the same visitor read twice because the handheld had not confirmed the first scan. Some were a plant engineer who came back on day two to talk pricing after speaking to a junior sales rep on day one. The rule could not tell the difference, so it treated both the same way.

That is the whole problem with badge scan deduplication. It is usually implemented as hygiene, it is usually applied once and never revisited, and it quietly deletes the rows an exhibitor would most want to see.

Why does the same badge appear twice in a scan log?

Pull the raw scan table for one exhibitor and sort it by badge id, then by timestamp. Repeat rows fall into a small number of causes, and they are separable if you have kept enough columns.

Device retries. The handheld or the phone app reads the badge, the network call times out or the confirmation does not appear, the staffer taps again. Two rows, same device, seconds apart. This is a capture artefact and says nothing about the visitor.

Staff testing the scanner. Somebody scans a colleague or their own badge at stand build, or first thing on show open to check the thing works. Same device, and the same small set of badge ids often appears across many different exhibitors.

Kiosk and passive readers. Where a stand runs an unattended scanner at a demo station or a prize draw entry, the same badge gets read every time its owner wanders past. Same device, gaps of a few minutes, clustered in the busy hours.

Second conversations. A visitor comes back. Different staffer, different device, several hours or a day later. This is the most valuable row in the table and the one most commonly thrown away.

The first three are noise. The fourth is the thing an exhibitor pays for, and it looks exactly like the third if the only columns you keep are badge id, exhibitor id and a timestamp.

Borrowing the session idea, and where it does not transfer

Web analytics solved a version of this decades ago by defining a session and giving it a timeout. Google's Analytics 4 documentation sets the default session timeout at 30 minutes of user inactivity and lets an administrator adjust it. The principle is the useful part: activity inside the window belongs to one visit, activity after it starts a new one.

The default value does not transfer. A stand conversation is a physical event with a natural length of two to fifteen minutes, and a 30 minute window would swallow the case where a visitor collects a brochure, walks the aisle, and comes back with a colleague twenty minutes later. That second interaction is a real one and an exhibitor would want it.

One detail from the same documentation is worth inverting. Google notes that GA4 sessions, unlike the older Universal Analytics behaviour, do not automatically expire at midnight. For a show floor you want the opposite. A day boundary is a hard boundary, because coming back tomorrow required the visitor to decide to come back, and no dedup window should ever span two show days regardless of how the clock arithmetic works out.

The rule, written out

The version I would ship collapses a repeat scan into the previous one only when all of these hold:

• same exhibitor id
• same badge id
• same capture device id
• same show day
• gap of ten minutes or less since the previous scan on that device

Change any one of those and the row survives as a separate visit. Different device means a different staffer, which almost always means a different conversation. A gap of more than ten minutes on the same device means the visitor left and returned. A new show day means a new decision, and what a return on another day says about intent is E13's subject.

Requiring the device id match is the part organisers skip, and it is the part that does most of the work. Device retries and kiosk re-reads are single-device phenomena by construction. A genuine return visit to a busy stand almost never lands on the same handheld.

Working the numbers on 4,120 scans

Take one large exhibitor across a three day show. The raw table holds 4,120 scan rows. Distinct badge ids across those rows: 3,180. So 940 rows are repeats of a badge the exhibitor had already scanned at least once.

The naive rule deletes all 940 and reports 3,180 leads. Now sort the 940 by the gap since the previous scan of that badge on that device and look at where they fall.

• under 60 seconds: 210
• 1 to 10 minutes: 130
• 10 minutes to 2 hours: 190
• 2 hours to end of the same show day: 145
• on a later show day: 265

That adds to 940. The windowed rule removes the first two bands, 210 plus 130, so 340 rows go. Every one of them shares a device with the scan it duplicates and sits inside ten minutes of it, which is the fingerprint of a retry or a passive reader.

The remaining 600 rows survive. Retained scan events: 4,120 minus 340, so 3,780. Unique badges: still 3,180, because deduplication never changes that figure. The 600 surviving repeats are spread across 470 distinct badges, which means 470 of 3,180 unique visitors, or 14.8 per cent, had more than one conversation with that stand.

That 14.8 per cent is a number the stand manager can act on. The 3,180 on its own is a number he can only compare to last year. How a unique count drifts away from a raw scan total over an edition is its own reporting problem, which E10 owns, and the relationship between 4,120 and 3,180 is a separate diagnostic with its own healthy range, covered by the scan to unique lead ratio in E12.

The near duplicate rate is also worth publishing back to the exhibitor: 340 of 4,120, or 8.3 per cent. An exhibitor running at 25 per cent near duplicates has a scanning problem, usually an unattended reader nobody mentioned when they ordered the kit, and that is a conversation worth having before the next edition.

How long should the dedup window be?

Ten minutes is a defensible starting point and it is not a law. The way to set it for your show is to build the gap histogram above from a previous edition and look for the trough.

Almost every scan file I have seen has the same shape. A large spike under 30 seconds, which is unambiguously device behaviour. A thinner band out to a few minutes. Then a dip, then a broad hump somewhere in the hours, which is people. The window belongs in the dip.

Where the dip sits depends on the show. A three hour drinks reception with 40 stands has a different shape from a four day machinery exhibition with 900. Halls with heavy demo scheduling push the hump left, because visitors return for a session that starts at the top of the hour. If your histogram has no dip at all, that usually means device ids are missing or being reused, and the window is the wrong tool until that is fixed.

Set it once per show, write the number in the methodology note that goes out with the exhibitor report, and keep it stable between editions. A window that changes year to year makes the year on year comparison meaningless, and somebody will eventually notice.

Never delete, always flag

Deduplication should be a column on the scan row, and the rows it collapses should stay in the table.

Keep every raw scan row exactly as captured, add a boolean for suppressed and a reference to the row it was collapsed into, and build every downstream aggregate off a view that filters on the flag. This costs almost nothing in storage and it buys three things: you can change the window and rerun without reingesting, you can answer an exhibitor who disputes a count by showing them precisely which rows were suppressed and why, and you can audit the rule when somebody claims it is eating their leads.

CEIR's 2015 study on Exhibitor ROI and Performance Metric Practices found that lead generation ranks as the most popular and important objective for exhibiting, with brand awareness and reinforcement second, and that exhibitors struggle with closing the loop on what becomes of their leads. An organiser who cannot explain the difference between an exhibitor's on-device count and the portal figure is adding a layer of doubt to a metric the exhibitor already treats as their main reason for being there, and that doubt spreads to the rest of your exhibitor analytics.

Where this stops

The rule leans on the device id, and plenty of lead retrieval deployments do not give you a reliable one.

Where an exhibitor uses a single shared handheld passed between staff, every genuine second conversation looks like a same-device repeat, and the ten minute window will collapse some of them. Where an exhibitor uses a phone app with a per-user login, you get something better than a device id, but the two exhibitors either side of them may not, and now your suppression rate is inconsistent across the floor for reasons that have nothing to do with visitor behaviour.

Badge sharing breaks it in the other direction. One badge, two people from the same company taking turns, produces repeat scans on different devices at wide intervals that are indistinguishable from an engaged returning visitor. There is no signal in the scan table that separates those cases, and anyone who tells you otherwise is guessing.

The honest response is to report the suppression rate per exhibitor alongside the lead count, and to say in the methodology note that device level attribution is only as good as the capture kit. An exhibitor who knows the rule can argue with it. An exhibitor who does not know the rule assumes you lost their leads.

CEIR's 2026 Marketing Spend Decision Report found that sales metrics dominate how exhibitor management evaluates exhibition ROI, with lead volume and post-show closed deals ranking highest as measurement priorities. Lead volume is the figure a dedup rule moves, which makes an unpublished rule a quiet edit to the number the exhibitor's own leadership is looking at.

Pull last edition's raw scan table for your ten largest exhibitors, compute the gap in seconds between consecutive scans of the same badge by the same exhibitor, and put those gaps in buckets. The shape of that one histogram tells you what your current dedup rule is deleting, and it takes about an hour.