Dwell Time, Capture Rate, Conversion: What Each Retail Metric Really Counts

Dwell time, capture rate and conversion rate are the three core metrics produced by WiFi and Bluetooth Low Energy (BLE) based retail and mall foot-traffic analytics, and each one measures a distinct stage of a visitor's physical interaction with a store or shopping centre. Dwell time counts how long a device is detected inside a defined zone. Capture rate counts what share of nearby passers-by actually enter. Conversion rate counts what share of entrants complete a transaction. Confuse these three and a leasing negotiation, a staffing model, or a GDPR filing can all go wrong in different, expensive ways.

The confusion is not accidental. All three metrics are typically generated from the same underlying signal — probe requests, association events, or BLE beacon pings captured by access points and sensors scattered through a mall or store — and vendors routinely blend the terms in marketing copy. The mechanics of capture differ from the mechanics of interpretation, and getting the second part wrong is where most operational and legal risk sits.

This piece works through what each metric actually counts, how the underlying WiFi/BLE signal gets collected, and where EU data protection law — led by France, Germany, Switzerland, Belgium and the Netherlands, with other markets handled differently — sets the real boundaries on what retailers and mall operators can do with it.

What Exactly Does Dwell Time Count?

Dwell time refers to the interval between the first and last signal a sensor receives from a given device identifier while that identifier stays within a defined detection zone. In practice, that means time from first probe request or BLE ping to the last one recorded before the signal drops below a set RSSI threshold or a timeout window closes. Industry guides describe it simply as a measure of how long visitors stay, used as a proxy for engagement Dwell Time: How long visitors stay, indicating engagement , but the simplicity hides a measurement problem.

Consider a shopper who browses a store for eleven minutes but drifts in and out of two overlapping access-point zones — one at the entrance, one near the fitting rooms. If the system treats each zone independently, that single visit can register as two shorter, disconnected dwell events rather than one continuous eleven-minute session, unless the platform explicitly stitches device identifiers across zones. This is the same stitching problem that makes customer journey mapping, not just dwell time, dependent on consistent identifier continuity across the whole venue Retailers use sensors, cameras, WiFi signals, or other technologies to capture visitor data, then turn those raw numbers into insights about customer behavior .

Dwell time says nothing about whether a visit led to a purchase and nothing about how many people walked past without entering at all. It only describes what happened once a device was already inside the zone being measured. Treating dwell time as a proxy for engagement is reasonable; treating it as a proxy for conversion is not a measurement choice but a category error.

How Does Capture Rate Differ From Conversion Rate?

Capture rate and conversion rate are frequently used interchangeably in retail reporting, and that habit obscures a real structural difference in what each ratio divides. Capture rate measures the share of nearby pass-by traffic that enters a specific location, calculated as store visitors divided by passer-by traffic capture rate measures how effective your storefront, signage, and window displays are at pulling in foot traffic. How to calculate: Capture Rate = (Store Visitors ÷ Passerby Traffic) × 100 . Conversion rate measures the share of people who were already inside who completed a transaction, calculated as transactions divided by visitors The percentage of visitors who make a purchase... Conversion Rate = (Number of Transactions ÷ Number of Visitors) × 100 .

The distinction matters because the two numbers diagnose entirely different problems. A location with strong capture but weak conversion has a merchandising or staffing issue once people are inside. A location with weak capture but strong conversion has a storefront, signage, or co-tenancy problem that never gets a chance to show up in sales data at all Capture rate is similar to conversion rate, and the two terms are often used interchangeably, though there is a subtle difference. While a "conversion" can be any type of desired action defined by you, a "capture" is typically a specific type of action—namely, entering a particular location. Capture rate can be useful in understanding how often foot traffic near your physical location translates into actual visits .

Metric	What it measures	Formula	Data required beyond foot traffic
Dwell time	Duration a device stays inside a defined zone	Last signal timestamp minus first signal timestamp per zone	None — signal timing only
Capture rate	Share of pass-by traffic that enters	Store visitors ÷ passer-by traffic	An external, uncaptured pass-by count
Conversion rate	Share of entrants who transact	Transactions ÷ visitors	POS transaction data

Foot traffic without a sales overlay cannot tell you whether a revenue decline is a traffic problem or a conversion problem A store with declining sales but stable traffic has a conversion problem. One with strong conversion but falling traffic has a different challenge entirely. Without foot traffic data, you cannot tell the difference . Capture rate versus conversion rate is the same split one level earlier in the funnel: it separates a storefront problem from an in-store problem, and the two require different fixes.

How Is the Underlying Signal Actually Captured?

Both WiFi and BLE methods rely on devices broadcasting identifiers that nearby receivers can log without the device ever joining a network. On WiFi, phones periodically send probe requests while scanning for known networks, and each probe carries a MAC address, signal strength, and timestamp that an access point or dedicated sensor can record passively, without pinging the device Inpixon Pod sensors passively scan your Wi-Fi environment, which means you can experience device detection and positioning that doesn't ping individual devices or make noisy transmissions throughout your airwaves . Associated devices — those actually joined to guest WiFi — produce a steadier, more reliable signal than unassociated probe-only traffic, because the network already has a persistent session to track.

Beyond simple presence detection, the IEEE 802.11mc amendment (commonly branded Wi-Fi RTT or Fine Timing Measurement) lets a device and an access point exchange round-trip timing signals to estimate distance directly, rather than inferring it from signal strength alone Specified in the IEEE 802.11-2016 standard, Wi-Fi RTT enables devices to measure the distance between devices with the round trip time it takes for a signal to travel between the devices. This calculation is based on the path traveled by the signal and determined using the transmission speed of the electromagnetic wave and the speed of light. This can be used for ranging between two devices or for indoor positioning using multiple APs or sensors with multilateration . Later amendments push accuracy further: 802.11az brings typical ranging accuracy from the 1-2 metre range down below one metre, and the newer 802.11bk amendment targets sub-10-centimetre "product on shelf" accuracy in controlled conditions 802.11az improves FTM's 1 m to 2 m accuracy to below 1 m. The IEEE 802.11 Working Group recently completed the IEEE 802.11bk amendment, which allows measurements in 320 MHz channels, which will further improve accuracy, below 0.1 m . BLE beacons work on a parallel but simpler logic: fixed beacons broadcast an identifier, and a phone's BLE radio (or a venue's own BLE receivers) picks it up, which is also the mechanism behind in-store push notifications Beacons are also used for MLA purposes and they work with Bluetooth. Through this technology, they are also able to send push notifications .

For a packet-level walkthrough of how probe requests, association events, and BLE advertisements actually flow through a sensor network, our companion piece Probe Requests, MAC Randomisation, and What Retail Analytics Can Still Measure goes deeper into the wire format itself. Here, the relevant point is simpler: the raw capture layer is passive and standards-based, which is exactly why the handling of the identifier it captures — not the radio technique — is where GDPR exposure concentrates.

Why Did MAC Randomisation Break the Naive Headcount?

Early WiFi analytics assumed one MAC address meant one device meant one visitor. That assumption stopped holding once manufacturers started randomising MAC addresses by default: Apple added the feature in iOS 8, and Android followed from version 6 onward Apple added a MAC randomization feature to iOS v8, installed on iPhone 4s and iPad 2 and newer devices. Android also added MAC randomization starting at Android v6 . Under randomisation, a single phone can rotate its broadcast identifier repeatedly during one visit, with some devices generating as many as twenty distinct MAC addresses inside a forty-minute shopping session Using this feature, phones will randomly change MAC addresses, some as many as 20 times in a 40 minute shopping session .

The practical effect is straightforward: a sensor network that counts raw unique MACs will systematically overcount visitors, sometimes badly, and the degree of overcount depends on handset mix rather than anything the retailer controls as the MAC address is changed by their device, the tracker device or access point will recognize the same person as multiple new customers, inflating the customer-count statistic and producing an ineffective data set for retailers . Only a minority of shoppers resolve this by actually joining guest WiFi, where a stable session identifier exists for the duration of the connection; average connection rates to in-store WiFi networks sit around ten percent More accurate metrics are also derived when a customer connects to a store's Wi-Fi network, however only 10% of customers on average connect to in-store Wi-Fi networks . Vendors handle this gap with probabilistic de-duplication — clustering bursts of rotating MACs by timing, signal pattern and physical plausibility into a single inferred visit — but that correction is itself a modelling layer sitting on top of the raw capture, not a property of the capture itself. Accounting for MAC rotation is not a stylistic choice in a methodology document; it is a structural requirement for any count that claims to represent unique visitors.

What Legal Basis Covers This Collection Under GDPR?

The starting legal fact is settled and has been for years: a MAC address, including a hashed one, is personal data under GDPR if it can single out a device belonging to an identifiable natural person. This follows the CJEU's 2016 reasoning in Breyer v Germany on dynamic IP addresses, extended by regulators and legal commentary to device identifiers more broadly On 19 October 2016, the Court of Justice of the European Union published its judgment in Case 582/14 – Patrick Breyer v Germany. This judgement concludes that dynamic IP addresses are to be seen as personal data, and following the same logic, MAC addresses of personal devices are therefore certainly to be seen as personal data . The Article 29 Working Party said much the same in its 2017 opinion on this exact use case, concluding that WiFi tracking is likely either subject to consent or restricted to genuinely anonymised data WiFi-tracking, depending on the circumstances and purposes of the data collection, such tracking under the GDPR is likely either to be subject to consent, or may only be performed if the personal data collected is anonymised . The UK's ICO, operating under the parallel UK GDPR regime post-Brexit, frames the same test functionally: if an individual can be identified from a MAC address or singled out and treated differently because of it, the data is personal data, regardless of whether the business knows that person's name If an individual can be identified from that MAC address, or other information in the possession of the network operator, then the data is personal data. Additionally, even if the business does not know the name of the individual, using a MAC address to track a device with the purpose of singling out that individual or treating them differently means the data is also personal data .

Consent is rarely workable for passive capture of random pedestrians — there is no practical mechanism to ask someone's permission before their phone emits a probe request — which pushes most operators toward legitimate interest as the operative legal basis instead. That basis is available to commercial operators, such as a mall lessor with a genuine business interest in footfall-by-store data over time, but it requires an explicit balancing test against the interests of the people being counted the basis to "ask permission from the data subject" usually does not provide a good basis for WiFi tracking, because in practice it is difficult to ask permission in advance from random pedestrians or shoppers. The promotion of the legitimate interest of the organisation can also serve as a basis for processing MAC addresses in WiFi tracking. This basis is not suitable for administrative bodies when carrying out a public task, but it is suitable for companies. For example, a lessor of retail space may have a legitimate interest in collecting business economic information about the number of visitors per store over time. However, the organisation must weigh this interest against the interests of the shop visitors and passers-by . The Netherlands offers a documented working example: national rail operator NS discloses its WiFi-tracking mechanics publicly, hashing the MAC address, adding a daily-rotating salt, and truncating the result so it cannot be traced back to a device or individual The MAC address is immediately 'hashed' – converted into a series of characters. This series is then sent to a server, where we add extra random characters and hash the series again. The extra characters differ per day, and are not stored on a computer. We then 'cut out' some of the characters, so that there is no way that the series can be traced to an individual .

Jurisdiction	Regulator	Framework	Notable posture on location/WiFi tracking
France	CNIL	GDPR + French Data Protection Act	Established SSID/MAC as personal data as early as its 2011 Google Street View decision; now runs a simplified sanction procedure with active low-threshold enforcement
Netherlands	Autoriteit Persoonsgegevens	GDPR	Public sector examples (e.g. NS) document hashing-plus-salt as the accepted anonymisation technique
Germany	BfDI + 16 state authorities	GDPR + BDSG	Fragmented regional enforcement; legitimate-interest balancing tests applied at state level
Belgium	Autorité de protection des données	GDPR	Follows EDPB-level guidance closely; no WiFi-specific statute beyond GDPR
Switzerland	FDPIC	Revised Federal Act on Data Protection (2023)	Not GDPR, but tracks its consent and legitimate-interest logic closely for non-EU-establishment cases

CNIL's own enforcement history underlines how long this has been settled doctrine, not a new interpretation. Its 2011 decision against Google concluded that SSID network names combined with MAC addresses could identify individuals when combined with other collected location data In its March 17 decision, CNIL reached the conclusion that Google Inc. was processing personal information. First, CNIL considered that the SSID information and MAC addresses allowed to identify individuals if used in combination with other location data collected by the Google cars . More recently, CNIL's simplified sanction procedure — introduced in 2022 for cases "without particular difficulty" — has produced ten separate enforcement decisions since January 2025 alone, including findings on excessive geolocation tracking CNIL announced that it had imposed 10 enforcement decisions since January 2025... CNIL highlighted issues such as excessive geolocation tracking, unjustified video surveillance, poor password management, and inadequate data breach notifications . Outside the EU and UK, requirements diverge sharply — the US has no federal equivalent, and state-level laws such as the CCPA treat device identifiers differently — which is why jurisdiction has to be the first design question for any multi-market WiFi/BLE deployment, not an afterthought.

Does Hashing Actually Anonymise the Data?

Hashing a MAC address is necessary but not, by itself, sufficient to exit GDPR's scope. A hashed MAC is still a pseudonym: the same input always produces the same output, so it can still be used to single out and re-identify one specific device over time, which is exactly what GDPR's pseudonymisation provisions address rather than exempt While alternatives for MAC addresses, such as hashed or encrypted versions, can be stored and processed, these would still be considered pseudonymous if they can uniquely single out a single device belonging to a natural person. Pseudonymising data does not move it out of scope of the GDPR as the data can still be linked back to a natural person, with the use of extra information . One widely cited vendor figure puts the brute-force search space for a hashed MAC at 281 trillion possible combinations, intended to illustrate practical infeasibility of reversal rather than legal exemption It is nearly impossible to match a hashed value from 281 trillion combinations of MAC addresses . That figure addresses computational difficulty, not legal classification — a hashed identifier that is never salted, rotated, or aggregated can still be treated as personal data if it functions as a stable tracking key.

True anonymisation, in the GDPR sense, requires something closer to aggregation: once individual-level data is combined into a figure — footfall by hour, by zone, by day — at a scale where no single device can be isolated or re-linked to a person, the result falls outside GDPR's scope entirely Once data is truly anonymized, and it can no longer be related back to a single data subject, it will be out of scope of the GDPR and can be further used . Getting from raw probe capture to that aggregated state still requires a valid legal basis for the initial collection step, even if the output later qualifies as anonymous Nevertheless a valid legal base will be required for the initial collection of any personal data . This is also why serious platforms build a documented compliance layer — retention limits, consent management, and anonymisation routines — as a first-class part of the stack, not a bolt-on, and why large-scale profiling or persistent location tracking typically triggers a mandatory Data Protection Impact Assessment If your WiFi analytics involve large-scale profiling or location tracking, you likely need a DPIA documenting the privacy risks and mitigations . Treating hashing as a compliance finish line rather than one step in a longer chain is not a technical shortcut; it is a structural misunderstanding of what the regulation actually tests.

Why Do Public and Aggregated Datasets Fall Short for Mall-Level Operations?

Macro-level foot traffic data — telco panels, GSM records, GPS-based mobility panels — is genuinely useful for market sizing, site selection, and competitive benchmarking, but it is built on a different sampling logic than in-venue sensing, and that logic leaves gaps. Telco data inherits the customer base of whichever operator supplies it, which means wide geographic coverage but a built-in skew toward networks with strong local penetration Telco and GSM data comes from a mobile network operator. The coverage is wide, but the sample is tied to that one operator's subscribers, so it skews toward wherever that network is strong and misses everyone on rival networks. You get a big number with a built-in bias . GPS-panel data has the opposite shape: it never observes every device in an area, only a sample, and every figure reported is an extrapolation from that sample rather than a direct count A GPS panel never sees everyone. It sees a subset of devices in a given area. The platform then extrapolates .

Neither method can resolve zone-level dwell time inside a specific store, or a genuine capture rate for one storefront against the pedestrian flow passing its specific frontage, because neither was built to see indoors at that resolution. That is precisely the gap that an operator's own WiFi/BLE sensor network fills: fixed access points and dedicated sensors positioned to create distinct detection zones, calibrated against the mall's own floor plan, which is also the level of ground truth behind what a mall operator's own digital twin typically needs — a topic our piece on What a Shopping Mall Digital Twin Actually Contains covers in more detail. One of Teampl's own earliest field programs ran exactly this kind of operational WiFi signal scanning at scale, covering thousands of scans a day across Germany, France and the Benelux region, which is the throughput level this kind of zone-resolution data actually demands — a market-wide panel simply is not built to produce it. Public and proprietary data are not competitors here; a market panel tells you whether a trade area is growing, and an in-venue sensor network tells you which specific storefront inside it is converting that growth into visits.

How Should These Metrics Be Benchmarked in Practice?

Physical retail still carries the overwhelming majority of consumer spending — roughly eighty-three cents of every retail dollar is still spent somewhere other than an online order — which is the underlying reason foot traffic metrics keep mattering even as e-commerce grows Roughly 83 cents of every retail dollar is still spent somewhere other than an online order, and for most retailers that somewhere is a store with a door . Conversion rate benchmarks vary meaningfully by category, and published figures should be read as a starting range rather than a target, since methodology and store format shift the baseline considerably.

Retail vertical	Typical conversion rate range
Specialty retail (furniture, jewellery)	20–30%
Apparel	15–25%
Electronics	10–20%

These ranges come from aggregated industry reporting across store formats Specialty retail averages 20-30%... Apparel averages 15-25%. Electronics averages 10-20% , and the more useful discipline is tracking a location's own trailing baseline rather than chasing a published number that was never calculated against your floor plan, staffing model, or customer mix A 20% to 40% range is the figure most often quoted for physical retail, but published benchmarks disagree and none of them know your store. Your own trailing baseline is the only benchmark worth managing against . Capture rate benchmarks are far more location-specific still, since they depend on pedestrian volume, storefront visibility, and co-tenancy — comparing a mall kiosk's capture rate to a high-street flagship's tells you less about performance than about the two locations being structurally different businesses.

Where This Leaves the Reader Running the Program

None of the three metrics is complicated on its own. Dwell time is a duration. Capture rate is a ratio of passers-by to entrants. Conversion rate is a ratio of entrants to buyers. What makes the topic genuinely hard is everything sitting underneath those three numbers: rotating identifiers, hashing that only partially solves the privacy problem, a legal basis that has to be argued and documented rather than assumed, and a sensor deployment that has to be calibrated zone by zone before any of the ratios mean what they claim to mean. Getting that right is less a software question and more an operations question. Someone has to place the sensors correctly, validate the de-duplication logic against ground truth, document the legal basis, and keep the whole pipeline honest as handsets, OS versions, and regulatory guidance all keep moving. Your next hire isn't a vendor. It's a data team.

Frequently Asked Questions