Zum Hauptinhalt springen

Wie man die Verweildauer mit WiFi Location Analytics berechnet

Dieser Leitfaden bietet eine umfassende technische Referenz zur Berechnung der WiFi-Verweildauer mittels WiFi Location Analytics. Er deckt die gesamte Architektur ab, von der Erfassung von 802.11 Probe Requests über die RSSI-basierte Trilateration bis zur Analyse von Geofence-Zonen. Er richtet sich an IT-Manager, Netzwerkarchitekten und Betriebsleiter von Veranstaltungsorten, die präzise, skalierbare Standortinformationen in Einzelhandel, Gastgewerbe, Gesundheitswesen und im öffentlichen Sektor implementieren müssen. Die Leser erhalten umsetzbare Implementierungsanleitungen, Fallstudien aus der Praxis und einen klaren Rahmen für die Umwandlung von Rohdaten in messbare Geschäftsergebnisse.

📖 9 Min. Lesezeit📝 2,134 Wörter🔧 2 ausgearbeitete Beispiele3 Übungsfragen📚 10 Schlüsseldefinitionen

Diesen Leitfaden anhören

Podcast-Transkript ansehen
Welcome to the Purple Technical Briefing. I'm your host, and today we are diving deep into the mechanics of spatial intelligence. Specifically, we're looking at how to calculate dwell time using WiFi location analytics. If you're an IT director, a network architect, or managing operations for a large venue — be it a retail chain, a hospital, or a stadium — you know that understanding how people move through your space is critical. Dwell time is the foundational metric here. It's not just about knowing someone entered the building; it's about knowing they spent twelve minutes in the promotional aisle, or forty-five minutes in the triage waiting room. But getting accurate dwell time isn't as simple as just turning on a feature in your wireless controller. It requires a solid understanding of RF dynamics, network architecture, and data processing. So, let's get into the technical details. Fundamentally, calculating dwell time involves three steps: identifying a device, estimating its position, and tracking that position over time. Step one is device detection. Mobile devices are constantly sending out 802.11 probe requests to find networks. Your Access Points act as sensors, picking up these probes. The AP records the device's MAC address, a timestamp, and the Received Signal Strength Indicator — or RSSI. Now, a quick note on identification. Historically, the MAC address was a static identifier. But today, iOS and Android use MAC randomization for privacy when probing. If a device isn't connected to your network, its MAC address changes. This means passive tracking can inflate visitor counts and skew dwell times, because one device looks like multiple devices over time. To get deterministic, highly accurate data, you need the user to authenticate to your Guest WiFi. Once authenticated, you have a persistent identifier. Moving to step two: spatial estimation. How do we know where the device is? We use RSSI and trilateration. If one AP hears a device at minus sixty-five dBm, we can estimate it's roughly ten metres away. But it could be anywhere on a ten-metre circle around that AP. To get a location, we need at least three APs to hear that same probe request. This is what I call the Rule of Three. The analytics engine takes the RSSI from all three APs, calculates the estimated distances, and finds where those circles intersect. Advanced systems use weighted centroids and Kalman filters to smooth out the inevitable RF noise and multipath fading you get in complex environments — think metal shelving in a warehouse, or dense crowds in a stadium concourse. Finally, step three: the temporal calculation. Once we have a stream of location coordinates, we map them against geofenced zones you've defined in the platform. Dwell time is calculated by logging an Entry Event when the device enters the zone, and an Exit Event when it leaves. Crucially, you must configure a Dwell Threshold. If someone walks through the apparel section in ten seconds, they are a passerby, not a dweller. Setting a threshold of, say, thirty seconds filters out the noise and gives you clean engagement data. Now let's talk implementation. How do you actually deploy this successfully? First, assess your infrastructure. A network designed for basic coverage will not support accurate location analytics. You need density. You need APs positioned on the perimeter of your zones, not just down the middle of the hallway. As a rule of thumb, a device should be heard by at least three APs at any given location, with an RSSI of minus seventy-five dBm or better. If your current deployment doesn't meet that standard, you'll need to densify — particularly in the zones that matter most to your business. Second, define your zones carefully. Don't make them too small. If a zone is smaller than the accuracy tolerance of your network, devices will appear to bounce in and out, corrupting your dwell metrics. In a retail environment, a good starting point is zones of at least twenty to thirty square metres. Third, think about your data pipeline. Your wireless controller needs to forward location data to the analytics platform. This typically happens via API or secure syslog. Ensure this integration is configured correctly and that data flows in near real-time — anything over a thirty-second lag will degrade the quality of your live operational dashboards. Fourth, and this is often overlooked: calibrate regularly. The RF environment in a venue changes. New displays go up, seasonal stock changes the layout, crowds absorb signal differently than empty aisles. A site survey conducted at deployment will not remain accurate six months later. Build a calibration cadence into your operational schedule. Now, let's move to a rapid-fire Q&A based on common deployment issues I see in the field. Question one: Our location data is jumping all over the place in our warehouse. What's going on? Warehouses are RF nightmares. Metal racking causes severe signal reflection — what we call multipath fading. The signal bounces off the metal and arrives at the AP via multiple paths, distorting the RSSI reading. You likely need to densify your APs, consider directional antennas focused down specific aisles, and ensure your analytics platform has its smoothing algorithms tuned for high-interference environments. Question two: Our dwell times seem way too short, and our visitor counts are much higher than expected. You are almost certainly relying on passive data, and MAC randomization is breaking the sessions. Each time a device changes its MAC address, the platform sees it as a brand new visitor who only stays for a short time. The fix is to drive Guest WiFi authentication. When users log in, you get a persistent identifier that survives MAC randomization. Incentivise authentication — a simple splash page with a one-click social login is often enough. Question three: We've defined a zone around our checkout, but it keeps capturing people who are just walking past. This is a Dwell Threshold configuration issue. Increase your minimum dwell threshold for that zone. If your checkout queue typically takes two minutes, set the threshold to sixty or ninety seconds. Anyone who passes through in less time simply won't be counted as a checkout dweller. To summarise everything we've covered today: dwell time calculation transforms your physical space into a measurable, optimisable environment. It requires a dense AP deployment, a solid understanding of trilateration and RSSI, and smart configuration of geofences and dwell thresholds. The data you get back is genuinely powerful. It tells you which zones are performing, where bottlenecks are forming, and where your layout or staffing needs to change. When correlated with sales or operational data, it becomes one of the most actionable metrics in your entire analytics stack. For the next steps, I'd recommend starting with a focused pilot. Pick two or three high-value zones in your venue, ensure your AP density is sufficient, configure your zones and thresholds carefully, and run the pilot for four to six weeks before drawing conclusions. That gives you enough data to establish a baseline and identify meaningful trends. Thank you for joining this technical briefing from Purple. For more detailed implementation guides and to explore how Purple's hardware-agnostic analytics platform can work with your existing infrastructure, head to purple dot ai.

header_image.png

Zusammenfassung für die Geschäftsleitung

Für Unternehmensstandorte — von weitläufigen Einzelhandelsflächen bis hin zu riesigen Stadien — ist das Verständnis des Besucherverhaltens keine Marketing-Luxus mehr; es ist eine kritische betriebliche Anforderung. Die WiFi-Verweildauer, die Zeitspanne, die ein Gerät in einer definierten physischen Zone verbleibt, dient als grundlegende Metrik zur Messung der räumlichen Interaktion. Die genaue Berechnung der Verweildauer unter Verwendung der bestehenden drahtlosen Infrastruktur erfordert jedoch die Navigation in komplexen RF-Umgebungen, MAC-Randomisierung und variierenden Geräte-Probe-Frequenzen.

Dieser Leitfaden bietet erfahrenen IT-Fachleuten, Netzwerkarchitekten und Betriebsleitern eine definitive technische Referenz zur Berechnung der Verweildauer mittels WiFi Location Analytics. Wir untersuchen die Mechanismen der Geräteerkennung, die Rolle des Received Signal Strength Indicator (RSSI) und der Trilateration sowie wie Plattformen wie Purple rohe Probe Requests in umsetzbare Business Intelligence umwandeln. Durch die Nutzung Ihrer bestehenden Guest WiFi -Infrastruktur können Unternehmen skalierbare Analysen ohne kostspielige Overlay-Hardware-Netzwerke implementieren. Der ROI-Fall ist überzeugend: Standorte, die Standortanalysen implementieren, berichten durchweg über messbare Verbesserungen der Konversionsraten, der betrieblichen Effizienz und der Kundenzufriedenheit.


Technischer Deep-Dive: Die Mechanik der Verweildauer

Die Berechnung der Verweildauer ist im Grunde ein Problem der räumlichen und zeitlichen Auflösung. Sie erfordert die Identifizierung eines Geräts, die Schätzung seiner Position und die kontinuierliche Verfolgung dieser Position über die Zeit. Jede dieser drei Phasen bringt ihre eigenen technischen Herausforderungen mit sich, und eine robuste Lösung muss alle davon berücksichtigen.

1. Geräteerkennung und -identifikation

Der Prozess beginnt mit der passiven Erkennung von 802.11 Probe Requests. Mobile Geräte senden diese Management-Frames kontinuierlich aus, um verfügbare drahtlose Netzwerke zu entdecken. Access Points (APs), die als Sensoren fungieren, erfassen diese Frames, die die MAC-Adresse des Geräts, einen Zeitstempel und die Signalstärke am empfangenden AP (RSSI) enthalten.

Historisch gesehen lieferte die MAC-Adresse einen persistenten, hardwarebasierten Identifikator. Moderne mobile Betriebssysteme — iOS 14+, Android 10+ und Windows 10+ — implementieren jedoch die MAC-Randomisierung, um die Privatsphäre der Benutzer zu verbessern. Wenn ein Gerät nicht mit einem Netzwerk verbunden ist, verwendet es eine temporäre, randomisierte MAC-Adresse, die sich periodisch ändert. Dies stellt eine direkte Herausforderung für die passive Verweildauerberechnung dar, da ein einziges physisches Gerät innerhalb einer Sitzung als mehrere eindeutige Besucher erscheinen kann.

Um die Sitzungskontinuität für eine genaue Verweildauerberechnung aufrechtzuerhalten, müssen Analyseplattformen eine von zwei Strategien anwenden. Die erste ist das heuristische Fingerprinting, bei dem die Information Elements (IEs) innerhalb des Probe Request Frames — wie unterstützte Datenraten, Kanallisten und herstellerspezifische Felder — analysiert werden, um Probe Requests desselben Geräts probabilistisch zu verknüpfen, selbst wenn sich die MAC-Adresse ändert. Der zweite und weitaus zuverlässigere Ansatz besteht darin, sich auf authentifizierte Sitzungen zu verlassen. Wenn ein Benutzer sich explizit mit dem Guest WiFi -Netzwerk verbindet, erhält die Plattform die echte Hardware-MAC-Adresse des Geräts und kann diese mit einem persistenten Benutzerprofil verknüpfen. Diese deterministische Identifikation ist der Goldstandard für genaue, langfristige Verweildauermetriken.

2. Räumliche Schätzung: RSSI und Trilateration

Sobald ein Gerät erkannt wird, muss das System seinen physischen Standort bestimmen. Der am weitesten verbreitete Ansatz verwendet die RSSI-basierte Trilateration, eine Technik, die im Leitfaden Die Mechanik der WiFi-Wegfindung: Trilateration und RSSI erklärt ausführlich erläutert wird.

Das Prinzip ist einfach: RSSI nimmt mit der Entfernung gemäß dem Free-Space Path Loss (FSPL)-Modell vorhersehbar ab. Durch die Messung der Signalstärke an mehreren APs kann das System die Entfernung vom Gerät zu jedem AP schätzen. Wenn drei oder mehr APs denselben Probe Request erkennen, kann die Analyse-Engine die Position des Geräts berechnen, indem sie den Schnittpunkt von Kreisen (oder Kugeln in einer 3D-Mehrstockumgebung) findet, deren Radien den geschätzten Entfernungen von jedem AP entsprechen.

dwell_time_architecture_overview.png

In der Praxis sind HF-Umgebungen weit entfernt vom idealisierten Freiraummodell. Mehrwegeausbreitung, verursacht durch Signalreflexionen an Wänden, Metallregalen und menschlichen Körpern, führt zu erheblichen RSSI-Schwankungen. Um dies zu mindern, wenden Analyse-Engines in Produktionsqualität mehrere Techniken an:

Technique Purpose Typical Gain
Gewichteter Schwerpunkt-Algorithmus Weist APs mit stärkeren RSSI-Werten ein höheres Gewicht zu Reduziert den Positionsfehler um 15–30 %
Kalman-Filterung Glättet Standortschätzungen über die Zeit, um vorübergehendes Rauschen zu entfernen Reduziert Jitter bei der Echtzeit-Verfolgung
Fingerprint-Mapping Kartiert RSSI-Signaturen an bekannten Standorten zur Kalibrierung vor Verbessert die Genauigkeit in komplexen HF-Umgebungen
Multi-AP-Mittelung Mittelt RSSI über mehrere Abtastintervalle Reduziert die Auswirkungen momentaner Interferenzen

Für eine zuverlässige Trilateration gilt die Drei-AP-Regel: Ein Gerät muss von mindestens drei APs gleichzeitig mit einer Signalstärke von -75 dBm oder besser empfangen werden. Netzwerke, die rein auf Abdeckung ausgelegt sind — bei denen ein einzelner AP ein Signal über einen großen Bereich bereitstellt — unterstützen keine genaueStandortanalysen bewerten. Dies ist eine entscheidende architektonische Unterscheidung, die vor der Bereitstellung berücksichtigt werden muss.

3. Zeitliche Berechnung: Definition und Berechnung der Verweildauer

Mit einem Strom von Standortkoordinaten ordnet die Analyse-Engine die Gerätepositionen den innerhalb der Plattform definierten Geofenced Zones zu. Ein Geofence ist ein virtuelles Polygon, das über einen Grundriss gezeichnet wird und einen bedeutsamen physischen Bereich darstellt, wie z. B. eine Kassenschlange, eine Werbefläche oder eine Hotellobby.

Die Verweildauer ist nicht einfach die Differenz zwischen dem ersten und letzten beobachteten Zeitstempel. Eine robuste Berechnung muss Geräteschlafzyklen, kurze Zonenabgänge und das inhärente Rauschen in Standortschätzungen berücksichtigen. Die Standardberechnungslogik definiert drei Schlüsselparameter:

Eintrittsereignis: Die geschätzte Position des Geräts tritt in eine definierte Geofenced Zone ein und verbleibt dort für eine Mindestdauer – den Dwell Threshold – um Passanten herauszufiltern. Ein gängiger Schwellenwert für Einzelhandelsumgebungen beträgt 30 Sekunden; für Wartebereiche im Gesundheitswesen können 60 Sekunden angemessener sein.

Austrittsereignis: Die Position des Geräts bewegt sich außerhalb der Zonengrenze, oder das Gerät wird für eine definierte Timeout Period (typischerweise 3–5 Minuten) von keinem AP erkannt. Das Timeout behandelt Geräte, die in den Schlafmodus wechseln oder in einer Tasche abgelegt werden, und verhindert eine vorzeitige Beendigung der Sitzung.

Dwell Duration: Die Differenz zwischen dem Zeitstempel des Eintrittsereignisses und dem Zeitstempel des Austrittsereignisses, abzüglich eines Timeout-Puffers. Dies ist die Metrik, die im WiFi Analytics Dashboard gemeldet wird.


Implementierungsleitfaden

Die Bereitstellung einer robusten WiFi-Standortanalyse-Lösung erfordert sorgfältige Planung und Abstimmung zwischen Netzwerkarchitektur und Geschäftszielen. Die folgenden Schritte stellen ein herstellerneutrales Bereitstellungs-Framework dar, das für jede Unternehmens-WLAN-Umgebung anwendbar ist.

Schritt 1: Infrastrukturbewertung und Verdichtung

Führen Sie eine gründliche HF-Standortuntersuchung durch, um Ihre bestehende WLAN-Bereitstellung anhand der Anforderungen an Standortdienste zu bewerten. Die Schlüsselfrage ist, ob Ihre aktuelle AP-Platzierung die Rule of Three in allen Zielzonen unterstützt. Verwenden Sie ein Tool wie Ekahau oder iBwave, um die AP-Abdeckung zu modellieren und Lücken zu identifizieren. Wenn Ihr Netzwerk ausschließlich auf Durchsatz und Abdeckung ausgelegt war, müssen Sie die Bereitstellung fast sicher verdichten, insbesondere in hochwertigen Zonen. Planen Sie zusätzliche APs und Verkabelung als Teil des Projektumfangs ein.

Schritt 2: Zonen-Definition und Geofencing

Ordnen Sie Ihren physischen Raum innerhalb der Analyseplattform logischen Zonen zu. Importieren Sie Ihre Grundrisse und definieren Sie Geofenced Areas, die Ihren Geschäftsfragen entsprechen. In einer Retail -Umgebung umfassen typische Zonen den Eingang, spezifische Produktkategorien, Werbebereiche und den Kassenbereich. In einem Hospitality -Umfeld könnten relevante Zonen die Lobby, das Restaurant, die Bar, Konferenzsuiten und den Poolbereich umfassen. Stellen Sie sicher, dass die Zonen angemessen dimensioniert sind – ein Minimum von 20–30 Quadratmetern ist eine praktische Untergrenze für WiFi-basierte Standortanalysen.

Schritt 3: Controller-Integration und Datenpipeline

Integrieren Sie Ihren Wireless Controller (Cisco, Aruba, Meraki, Ruckus oder Äquivalent) in die Analyseplattform. Dies beinhaltet typischerweise die Konfiguration des Controllers, um RTLS (Real-Time Location System)-Datenströme oder Standort-API-Updates an die Analyse-Engine weiterzuleiten. Stellen Sie sicher, dass die Datenpipeline für eine nahezu Echtzeit-Bereitstellung konfiguriert ist – Latenzzeiten über 30 Sekunden beeinträchtigen die Qualität von Live-Betriebs-Dashboards. Die gesamte Datenübertragung muss während der Übertragung verschlüsselt sein (mindestens TLS 1.2) und den GDPR sowie allen anwendbaren Datenschutzbestimmungen entsprechen.

Schritt 4: Schwellenwertkonfiguration und Basislinien-Etablierung

Konfigurieren Sie Dwell Thresholds und Timeout Periods für jede Zone basierend auf dem erwarteten Verhalten in diesem Bereich. Betreiben Sie das System mindestens vier bis sechs Wochen lang, bevor Sie Schlussfolgerungen ziehen, um eine statistisch robuste Basislinie zu etablieren. Diese Basislinie ist unerlässlich, um aussagekräftige Abweichungen zu identifizieren – ein plötzlicher Rückgang der Verweildauer an einer Werbefläche kann beispielsweise auf ein Merchandising-Problem oder einen Personalengpass hinweisen.

dwell_time_heatmap_infographic.png


Best Practices

Die folgenden Empfehlungen spiegeln branchenübliche Ansätze zur Bereitstellung von WiFi-Standortanalysen in großem Maßstab wider.

Kalibrieren Sie die HF-Umgebung regelmäßig. Die physische Umgebung eines Veranstaltungsortes ändert sich kontinuierlich – neue Displays, saisonale Bestände, Menschenmengen – all dies verändert die HF-Ausbreitung. Eine bei der Bereitstellung durchgeführte Standortuntersuchung bleibt sechs Monate später nicht mehr genau. Bauen Sie einen vierteljährlichen Kalibrierungszyklus in Ihren Betriebsplan ein und kalibrieren Sie sofort nach jeder signifikanten physischen Änderung des Raumes neu.

Segmentieren Sie passive und authentifizierte Analysen. Informieren Sie die Stakeholder über den Unterschied zwischen passiven Analysen (nicht authentifizierte Geräte, die der MAC-Randomisierung unterliegen) und authentifizierten Analysen (Benutzer, die sich beim Guest WiFi angemeldet haben). Passive Daten liefern zuverlässige Trenddaten in großem Maßstab; authentifizierte Daten bieten deterministisches Tracking auf individueller Ebene. Verwenden Sie passive Daten für die Makro-Ebene der Besucherfrequenz und Zonenpopularitätsanalyse und authentifizierte Daten für die Konversionszuordnung und personalisierte Interaktion.

Korrelieren Sie mit Betriebsdaten. Die Verweildauer isoliert betrachtet ist eine Metrik, keine Einsicht. Der Wert wird freigesetzt, wenn räumliche Daten mit Point of Sale (PoS)-Daten, Personalplänen oder Service-Lieferprotokollen korreliert werden. Eine hohe Verweildauer an einer Kassenschlange ist beispielsweise nur dann umsetzbar, wenn sie mit Transaktionsvolumen und Personalbestand korreliert wird. Diese Korrelation ist die Grundlage für den ROI-Fall von Standortanalyse-Investitionen.

Halten Sie die Datenschutz- und Compliance-Anforderungen ein. Stellen Sie sicher, dass Ihre Bereitstellung den GDPR (in das Vereinigte Königreich und die EU) sowie alle branchenspezifischen Vorschriften, die für Ihre Branche relevant sind. In Gesundheitseinrichtungen können Patientendaten zusätzlichen Datenschutzanforderungen unterliegen. Implementieren Sie Grundsätze der Datenminimierung – erfassen Sie nur das Notwendige, anonymisieren Sie wo möglich und legen Sie klare Datenaufbewahrungsrichtlinien fest.


Fehlerbehebung und Risikominderung

Die folgende Tabelle fasst die häufigsten Fehlerquellen bei der Implementierung von WiFi-Verweildauer-Messungen und die empfohlenen Abhilfemaßnahmen zusammen.

Fehlermodus Wahrscheinliche Ursache Abhilfemaßnahme
Überhöhte Besucherzahlen, kurze Verweildauern MAC-Randomisierung bei nicht authentifizierten Geräten Förderung der Guest WiFi-Authentifizierung; Verwendung heuristischer Fingerprinting-Methoden für passive Daten
Unregelmäßige Standortdaten (Geräte springen zwischen Zonen) Unzureichende AP-Dichte oder Mehrwegeausbreitung APs verdichten; Glättungsalgorithmen anpassen; HF-Modell neu kalibrieren
Zonen erfassen Passanten Verweildauerschwelle zu niedrig eingestellt Mindestverweildauerschwelle für die betroffene Zone erhöhen
Kassenbereich erfasst Eingangsbereich Überlappende oder überdimensionierte Zonen-Definitionen Geofence-Grenzen straffen; sicherstellen, dass Zonen sich nicht überlappen
Veraltete oder verzögerte Dashboard-Daten Latenz der Datenpipeline oder API-Ratenbegrenzung Controller-Integration überprüfen; API-Abfragefrequenz erhöhen
Geringe Genauigkeit in Umgebungen mit mehreren Etagen 2D-Trilateration auf 3D-Raum angewendet Implementierung einer Etagen-Diskriminierung mittels AP-Höhendaten

ROI und Geschäftsauswirkungen

Die Implementierung von WiFi-Standortanalysen verwandelt physische Räume in messbare, optimierbare Umgebungen. Das Geschäftsmodell basiert auf drei Dimensionen: Umsatzgenerierung, betriebliche Effizienz und Kundenerlebnis.

Auf der Umsatzseite ermöglichen Verweildauerdaten evidenzbasierte Merchandising-Entscheidungen. Das Wissen, dass eine bestimmte Kopfplatzierung eine durchschnittliche Verweildauer von 9,2 Minuten generiert – im Vergleich zu 1,6 Minuten am Eingang – ermöglicht es Category Managern, margenstarke Produkte in Zonen mit hoher Kundenbindung zu priorisieren. Für Transport -Betreiber beeinflusst das Verständnis der Verweildauermuster in Einzelhandelskonzessionen direkt Mietverhandlungen und Umsatzbeteiligungsvereinbarungen.

Auf der operativen Seite ermöglichen Echtzeit-Verweildaueranalysen eine dynamische Personalplanung. Ein Warteschlangenmanagementsystem, das eine Personalwarnung auslöst, wenn die Verweildauer an der Kasse einen definierten Schwellenwert überschreitet, kann Wartezeiten reduzieren, ohne die Kosten einer dauerhaften Überbesetzung zu verursachen. Dies trägt direkt zur Verbesserung der Kundenzufriedenheit bei – ein Thema, das ausführlich in Wie Sie die Gästezufriedenheit verbessern: Das ultimative Playbook behandelt wird.

Auf der Erlebnisseite ermöglicht Standortintelligenz eine kontextuell relevante Interaktion. In Kombination mit der WiFi Analytics -Plattform von Purple können Verweildauerdaten personalisierte Benachrichtigungen auslösen – zum Beispiel ein Rabattangebot an einen Kunden, der mehr als fünf Minuten in der Schuhabteilung verbracht hat. Diese Fähigkeit wird zunehmend relevanter, da Veranstaltungsorte passwortlose Zugangsmodelle erforschen, die die Authentifizierungsreibung reduzieren und gleichzeitig die Datenqualität erhalten.

Für Organisationen des öffentlichen Sektors und Smart-City-Initiativen liefern Verweildaueranalysen die Datengrundlage für Infrastrukturinvestitionsentscheidungen – sie zeigen, wie Bürger öffentliche Räume, Verkehrsknotenpunkte und öffentliche Gebäude nutzen. Purples wachsende Kompetenz im öffentlichen Sektor, wie sie in der Ernennung von Iain Fox zum VP Growth for Public Sector hervorgehoben wird, spiegelt die steigende Nachfrage nach dieser Art von räumlicher Intelligenz in Regierungs- und kommunalen Umgebungen wider.

Die Gesamtbetriebskosten für eine WiFi-Standortanalyse-Implementierung sind in der Regel gering im Verhältnis zum generierten operativen Wert, insbesondere wenn die Analyseschicht über einer bestehenden WLAN-Infrastruktur eingesetzt wird. Die Grenzkosten bestehen hauptsächlich aus der Lizenz für die Analyseplattform und dem technischen Aufwand für Integration und Kalibrierung – und nicht aus einer Greenfield-Hardwareinvestition.

Schlüsseldefinitionen

Wifi Dwell Time

The measured duration a WiFi-enabled device remains within a defined physical zone, calculated from the delta between an entry event and an exit event as detected by the wireless infrastructure.

The primary metric for spatial engagement analytics. Used by retail operators, venue managers, and healthcare administrators to understand how people use physical spaces.

Received Signal Strength Indicator (RSSI)

A measurement of the power level of a received radio signal, expressed in decibels relative to one milliwatt (dBm). Values typically range from 0 dBm (maximum signal) to -100 dBm (minimum detectable signal).

The raw input for distance estimation in WiFi location analytics. RSSI of -75 dBm or better at three or more APs is the minimum requirement for reliable trilateration.

Trilateration

A mathematical technique for determining the position of a point by measuring its distance from three or more known reference points. In WiFi analytics, the reference points are Access Points and the distances are estimated from RSSI readings.

The core positioning algorithm used by WiFi location analytics platforms. Distinct from triangulation, which uses angles rather than distances.

MAC Randomization

A privacy feature implemented in modern mobile operating systems (iOS 14+, Android 10+) where a device uses a temporary, randomized MAC address when probing for networks, rather than its permanent hardware address.

The primary technical challenge for passive WiFi analytics. Causes a single physical device to appear as multiple unique visitors, inflating footfall counts and fragmenting dwell time sessions. Mitigated by encouraging Guest WiFi authentication.

Geofencing

The creation of a virtual geographic boundary — defined as a polygon on a floor plan — that triggers analytical events (entry, exit, dwell) when a tracked device crosses the boundary.

Used within the analytics dashboard to define specific areas for localized dwell time measurement. Zone size and placement are critical configuration decisions that directly impact data quality.

Dwell Threshold

The minimum duration a device must remain within a geofenced zone before the analytics platform registers an entry event and begins counting dwell time.

Essential for data quality. A threshold that is too low will count passersby as dwellers; a threshold that is too high will miss genuine short-duration engagements. Must be tuned per zone based on expected behaviour.

Multipath Fading

A phenomenon where a radio signal reaches a receiving antenna via two or more paths — direct line-of-sight and one or more reflected paths — causing constructive or destructive interference that distorts the received signal strength.

The primary source of RSSI inaccuracy in complex indoor environments such as warehouses, retail stores, and hospitals. Mitigated through AP densification, smoothing algorithms, and RF fingerprinting.

Probe Request

An 802.11 management frame broadcast by a client device to discover available wireless networks. Contains the device's MAC address (which may be randomized), supported data rates, and other capability information.

The fundamental data packet captured by APs to detect the presence of devices in a venue. The raw input for all passive WiFi location analytics.

Deterministic Identification

The ability to identify a specific device or user with certainty, typically achieved through an authentication event where the device's true hardware MAC address is revealed to the network.

Achieved when a user authenticates to the Guest WiFi network. Enables accurate long-term dwell tracking that is immune to MAC randomization, and allows spatial data to be tied to a known user profile for conversion attribution.

Free-Space Path Loss (FSPL)

The attenuation of radio signal strength that occurs as the signal propagates through free space, increasing with distance and frequency according to a logarithmic model.

The theoretical basis for RSSI-to-distance conversion in trilateration. Real-world environments deviate significantly from the FSPL model due to obstacles and reflections, which is why calibration and smoothing algorithms are essential.

Ausgearbeitete Beispiele

A national retail chain with 150 stores wants to measure the effectiveness of a new end-cap promotional display. The marketing team needs to know how long shoppers are stopping at the display, and whether high dwell time correlates with increased sales of the promoted SKU.

Step 1 — Zone Creation: Define a tight geofence (approximately 4m x 3m) around the end-cap display within the Purple analytics dashboard, distinct from the broader aisle zone. Step 2 — Threshold Configuration: Set a minimum dwell threshold of 20 seconds to filter out customers simply walking past the aisle end. Step 3 — Baseline Period: Run the analytics for two weeks before the promotion launches to establish a baseline dwell time for that zone. Step 4 — Promotion Period Measurement: Activate the promotion and monitor dwell time daily. Export the dwell time data via the analytics API. Step 5 — Correlation: Join the dwell time dataset with PoS transaction data for the promoted SKU, segmented by time of day and day of week. Calculate the Pearson correlation coefficient between average zone dwell time and hourly SKU sales volume. Step 6 — Reporting: Present the correlation data to the category management team with a recommendation to replicate the display format in high-footfall stores.

Kommentar des Prüfers: The critical design decision here is the tight geofence around the specific display, rather than the broader aisle. This isolates the behaviour of interest. The 20-second threshold is appropriate for a retail browsing context — short enough to capture genuine engagement, long enough to exclude transit. The correlation with PoS data is what transforms the dwell metric into a business insight. Note that if the store relies entirely on passive analytics, MAC randomization may undercount repeat visitors; correlating with loyalty card data or encouraging Guest WiFi authentication would improve the precision of the individual-level analysis.

A large NHS trust needs to monitor patient wait times in the Emergency Department triage area to ensure compliance with the four-hour SLA target. The IT team has an existing Cisco Meraki deployment but no current analytics capability.

Step 1 — Infrastructure Audit: Conduct an RF site survey of the triage waiting area. Verify that a minimum of three Meraki APs hear devices in all seating areas at -70 dBm or better. The ED environment typically has high RF interference from medical equipment; densify if necessary. Step 2 — Meraki Location API Integration: Enable the Meraki Scanning API on the relevant APs and configure it to POST location data to the Purple analytics platform endpoint at 30-second intervals. Step 3 — Zone Definition: Define the triage waiting area as a distinct zone within Purple. Set the dwell threshold to 60 seconds and the timeout to 10 minutes (to account for patients who may be briefly taken to a side room). Step 4 — Real-Time Alerting: Configure a webhook alert to notify the duty charge nurse via the hospital's operational messaging system (e.g., Microsoft Teams or Vocera) if the average dwell time in the triage zone exceeds 45 minutes. Step 5 — Reporting: Generate weekly dwell time reports segmented by time of day and day of week to identify peak pressure periods for staffing optimisation.

Kommentar des Prüfers: In healthcare, dwell time directly impacts patient outcomes and regulatory compliance. The critical step is the infrastructure audit — location accuracy must be sufficient to distinguish the waiting area from adjacent clinical corridors, which may be separated by only a few metres. The 10-minute timeout is deliberately generous to account for the non-linear movement patterns of patients in an ED. Real-time alerting is what transforms retrospective analytics into a proactive operational tool. Data governance is paramount in this context: ensure all location data is processed in compliance with NHS data protection policies and UK GDPR, and that patient data is anonymised at the point of collection.

Übungsfragen

Q1. You are deploying location analytics in a large warehouse with high metal racking throughout. Initial tests show device locations jumping erratically between aisles, and average dwell times are inconsistent. What is the most likely root cause and what remediation steps would you recommend?

Hinweis: Consider how the physical structure of the environment affects RF signal propagation, and what this means for the reliability of RSSI-based distance estimation.

Musterlösung anzeigen

The erratic location data is caused by severe multipath fading. Metal racking reflects and scatters RF signals, meaning the RSSI values received by APs are heavily distorted by reflected paths rather than representing true line-of-sight distances. This makes the trilateration engine's distance estimates unreliable. Recommended remediation: (1) Densify the AP deployment, positioning APs at the end of each aisle to maximise line-of-sight coverage down the aisle length. (2) Consider directional antennas focused down specific aisles to reduce cross-aisle interference. (3) Implement RF fingerprinting — pre-map RSSI signatures at known grid points throughout the warehouse to create a calibrated location model that accounts for the specific RF characteristics of the environment. (4) Tune the analytics platform's Kalman filter smoothing parameters to reduce the impact of transient RSSI spikes on the location estimate.

Q2. A retail operations director reports that the analytics platform is showing total daily visitor counts that are three times higher than the manual door counter, and average dwell times of under two minutes across all zones. The deployment relies entirely on passive probe request monitoring. What is the architectural issue and how would you resolve it?

Hinweis: Think about what happens to a device's identifier over the course of a one-hour shopping visit on a modern smartphone.

Musterlösung anzeigen

The issue is MAC randomization. Modern smartphones rotate their randomized MAC address periodically — in some cases every few minutes. Because the platform is relying entirely on passive probe requests, each new MAC address is interpreted as a new, unique visitor. A single shopper who spends an hour in the store may generate ten or more unique MAC addresses, each appearing as a separate visitor with a short dwell time. The resolution is twofold: (1) Implement a Guest WiFi authentication flow to drive users onto the network, providing a persistent hardware MAC address and a known user identity. Even a 30–40% authentication rate will significantly improve data quality. (2) For the remaining passive data, implement heuristic fingerprinting to probabilistically link probe requests from the same device based on Information Element patterns, reducing (though not eliminating) the inflation caused by MAC rotation. Communicate clearly to stakeholders that passive visitor counts are trend indicators, not absolute figures.

Q3. You have deployed location analytics in a shopping centre and defined a zone around a specific food court seating area. The data shows that the zone has an unusually high average dwell time of 45 minutes, but the food court operator reports that most customers are only seated for 15–20 minutes. What configuration issue might explain this discrepancy?

Hinweis: Consider how the analytics platform handles devices that stop sending probe requests while remaining physically present in the zone.

Musterlösung anzeigen

The most likely cause is an incorrectly configured Timeout Period. When a customer finishes eating and puts their phone in their pocket or bag, the device may enter a low-power state and stop broadcasting probe requests. If the Timeout Period is set too long — for example, 30 minutes — the platform will continue the dwell session for 30 minutes after the last detected probe, even if the customer has already left. This artificially inflates the reported dwell time. The fix is to reduce the Timeout Period to a value that reflects the typical gap between probe broadcasts in the environment — usually 3–5 minutes is appropriate for a busy public venue. Additionally, review whether the geofence boundary for the food court zone is inadvertently capturing adjacent areas (e.g., a corridor or queue) where customers may linger after leaving the seating area.