Nutzerbindung und Asset-Sichtbarkeit

1. Lernziele

steuernde, identifizierende, gemessene und abgeleitete Variablen unterscheiden
Nutzerbindung als Location-Analytics-Begriff einordnen
Dwell-Grenzen und Erfassungszeiten sicher konfigurieren
Named Assets und BLE-Filter skalierbar gestalten
RSSI, Last Seen, Count und Rollenlabels korrekt interpretieren
Änderungen, Datenschutz und Datenqualität gemeinsam steuern

Leitfrage: Verändert eine Variable die Erfassung, die Identität, die Berechnung – oder nur die sichtbare Auswahl?

2. Vier Ebenen

Steuernd

Feature-Schalter, Dwell-Min/Max, Tage, Uhrzeiten, RSSI-Schwelle, Scope.

Identifizierend

MAC, Asset Name, UUID, Major/Minor, Namespace/Instance, Herstellerdaten.

Gemessen

RSSI, Last Seen, Timestamp, AP, Floorplan, Zone und Batterie.

Abgeleitet

Visit, Dwell, Wait, Client-Kategorie, Journey, Occupancy und Heatmap.

Konfiguration + Identität + Beobachtung → Analyse

Eine Änderung an einer frühen Ebene wirkt auf alle folgenden. Ein Dashboardfilter verändert dagegen meist nur die Ansicht.

3. Signal- und Datenfluss

Nutzerbindung

Wi-Fi/BLE/SDK→AP→Zone & Zeit→Visit/Dwell

Asset-Sichtbarkeit

BLE-Tag→APs→RSSI/Beam→Asset/Zone

Beim Asset Tracking sendet der Tag und der AP empfängt. Bei vBLE Engagement sendet der AP Beams an eine SDK-App.

4. Site-Schalter und Senderate

Variable	Wirkung
Engagement Analytics	aktiviert die Engagement-Erfassung der Site
vBLE Engagement	AP sendet gerichtete BLE-Beams
Asset Visibility	AP empfängt BLE-Assets
App Wakeup	Super Beacon für SDK-App

Juniper dokumentiert als Cloud-Senderate: nur Engagement jede Sekunde, nur Asset Visibility alle zwei Sekunden, beide gemeinsam alle zwei Sekunden. Das ist nicht automatisch die Aktualisierung jedes Dashboards.

5. Dwell-Grenzen und Zeitplan

Jede frei definierte Kategorie erhält Minimum und Maximum in Sekunden. Der maximal eingebbare Wert beträgt laut Juniper 86.400 Sekunden.

Variable	Wirkung	Risiko
`min_dwell`	untere Aufenthaltsgrenze	zu niedrig macht Vorbeigehende zu Besuchen
`max_dwell`	obere Aufenthaltsgrenze	Lücken oder Überlappungen
Kategoriename	Label des Zeitintervalls	wird fälschlich als Identität gelesen
Start/Ende je Tag	Erfassungsfenster	Datenlücke außerhalb des Fensters

12:00 AM–12:00 AM bedeutet kontinuierliche Erfassung. Der Plan wirkt auf alle zonenbasierten Locationdaten, darunter Occupancy und Zone-Event-Webhooks.

Keine Rollenprüfung: Ein Gerät mit langem Dwell ist dadurch kein bestätigter Mitarbeiter oder Asset.

6. Quellen und Entitäten

Quelle	Stärke	Grenze
Wireless Client	ohne Tag nutzbar	Randomisierung; Gerät ≠ Person
BLE Client	passiv sichtbar	wechselnde Identität und Advertising
Named Asset	priorisiert, benannt, History	statische Zuordnung und Tagqualität
SDK Client	aktive Experience, Kontinuität	Consent, Permissions, App-Lifecycle

7. Scope, Zeitraum und Metriken

Scopes: Organisation, Site, Floorplan, AP und Zone. Zeit: Stunde, Tag, Woche, Monat oder benutzerdefiniert.

Metrik	Lesart	Nicht automatisch
Count	beobachtete Entitäten nach Dashboardlogik	Menschen
Visit	erkannter Aufenthalt im Scope	Kauf oder Interaktion
Dwell	abgeleitete Aufenthaltsdauer	Absicht oder Produktivität
Wait	Analytics-Wartezeitmetrik	bestätigte Servicewartezeit
Occupancy	geschätzte gleichzeitige Entitäten	amtliche Personenzählung

Vergleiche brauchen identischen Scope, Zeitraum, Zeitzone, Erfassungsplan und Definitionen.

8. Standard und Premium

Funktion	Standard	Premium
Dwell-Segmentierung, Visitor Trends	ja	ja
Dwell/Visits nach Site, Floor, AP, Zone	ja	ja
Occupancy Heatmap	ja	ja
Bewegungspfade/Zone Flows	nein	ja
Drittanbieter-Occupancy	nein	ja

Passerby <10 minVisitor 10 min–2 hLoyalty: Besuch in 30 TagenEmployee 2–8 hAsset >8 h

Diese dokumentierten Premium-Standardlabels sind von frei definierten Site-Dwell-Kategorien zu unterscheiden. „Employee“ ist ein Zeitlabel, keine verifizierte Beschäftigtenrolle.

9. Zonen und RSSI-Schwelle

Variable	Einfluss
Name/ID	Reports, Webhooks und Integrationen
Geometrie	Entry, Exit, Dwell und Occupancy
Überlappung	Mehrdeutigkeit und Flattern
Änderungszeit	Vergleichbarkeit historischer Daten

RSSI ≥ Threshold→in_event·RSSI < Threshold→out_event

Eine niedrige Schwelle vergrößert die Proximity-Zone; eine hohe verkleinert sie und kann Flattern fördern. Für Events muss das Webhook-Thema „Proximity Zones“ aktiv sein.

10. Named Assets und Variablen

Variable	Funktion	Beispiel
`[ctr]`	fortlaufender Zähler	`Wheelchair_[ctr]`
`[ctr.3]`	dreistelliger Zähler	`Pumpe_001`
`[site]`	Site im Namen	`[site]_Scanner_[ctr.3]`

Der Zähler macht Mehrfachzuordnungen eindeutig; [site] ist für mehrere Sites sinnvoll. Weitere im Portal angebotene Platzhalter werden dort geprüft und hier nicht erfunden.

CSV-Import benötigt exakt Asset Name,MAC Address. Juniper priorisiert Named Assets gegenüber unbenannten BLE Clients, was deren Location Accuracy verbessern kann.

11. Asset-Filter

Pro Filter können laut Juniper bis zu sechs Filtertypen und Werte kombiniert werden.

Typ	Variablen	Zweck
iBeacon	UUID 128 Bit, Major/Minor je 16 Bit	Gruppe und Instanz
Eddystone UID	Namespace 80 Bit, Instance 48 Bit	Flotte und Tag
Eddystone URL	URL	URL-Beacons
Eddystone TLM	Spannung, Temperatur	Telemetrie; mit UID/URL identifizieren
Service UUID	128 Bit	anwendungsspezifische Gruppe
MFG Data	Hersteller-ID und Daten	herstellerspezifische Erkennung

Zu breite Filter erfassen Fremdgeräte; zu enge verlieren gültige Firmware- oder Payloadvarianten.

12. Physische Tagvariablen

Variable	Richtwert/Einfluss	Trade-off
Advertising Interval	1000–100 ms	häufiger = aktueller, aber weniger Batterie
Transmit Power	0 dBm	Reichweite gegen Energie
MAC	statisch	Randomisierung verhindert Zuordnung
Montage	nicht durch Metall/Körper abgeschirmt	Material und Lage ändern RSSI
Batterie/Firmware	Alter, Temperatur, Payload	Update kann Filter brechen

13. Messwerte, Aktualität und Genauigkeit

Wert	Aussage	Grenze
RSSI	Signalstärke am AP	keine direkte Meterangabe
Beam 1–9	empfangender BLE-Beam	kein fertiges X/Y
Last Seen	letzte Beobachtung	nicht letzte reale Bewegung
AP/Map/Site ID	technischer Kontext	benötigt lesbares Mapping
Timestamp	Zeit der Beobachtung	Zeitzone/Latenz beachten

Für Named Assets nennt Juniper zonale Genauigkeit von etwa 3–5 Metern, nicht garantierte Punktgenauigkeit. Neben „Wo?“ braucht der Betrieb immer „Wie alt darf Last Seen sein?“

14. Raw RSSI und Location Webhooks

Raw RSSI enthält Beobachtungsdaten, aber keine berechnete Client-X/Y-Position. Dafür ist ein Location-Webhook erforderlich.

Feldgruppe	Beispiele
Funk	`rssi`, `beam`
Identität	`mac`, `is_asset`, UUID, Major, Minor
Payload	`mfg_company_id`, `mfg_data`
Kontext	`device_id`, `map_id`, `site_id`, `org_id`
Zeit/Ort des AP	`timestamp`, `ap_loc`

Integrationen benötigen Deduplizierung, Retry, Zeitsynchronisation, ID-Mapping und die Trennung von Rohbeobachtung und errechneter Location.

15. Datenqualität

Störgröße	Folge	Kontrolle
randomisierte MAC	ein Gerät erscheint mehrfach	Counts aggregiert lesen; Assets statisch
mehrere/keine Geräte pro Person	Personenzahl über-/unterschätzt	keine 1:1-Gleichsetzung
Zonenänderung	Zeitreihe nicht vergleichbar	Version und Zeitpunkt protokollieren
Filter zu breit/eng	Fremdgeräte oder fehlende Tags	Positiv- und Negativtest
alte Position	plausibel, aber nicht aktuell	Freshness-Grenzwert

beobachtete Geräte ≠ eindeutige Geräte ≠ Menschen ≠ bestätigte Rollen

16. Variablendesign

1. Aussage
Asset finden, Belegung oder Besuchertrend präzise definieren.

2. Entität
Wireless, BLE, SDK oder Named Asset samt Lebenszyklus wählen.

3. Erfassung
Schalter, Zeitplan, Dwell, Zonen und RSSI pilotieren.

4. Qualität
Freshness, Coverage, Accuracy, Batterie und Lücken messen.

5. Governance
Scope, Rollen, Export, Löschung und Change Log festlegen.

Beispiel: [site]_Wheelchair_[ctr.3], statische MAC, spezifischer Filter, Asset Visibility 24×7, Zonen je Funktionsbereich und dokumentierter Freshness-Grenzwert.

17. Fehlersuche

Symptom	Zuerst prüfen
keine Daten zu einer Uhrzeit	Schedule und Zeitzone
Asset fehlt	Feature, MAC, Filter, Last Seen, Batterie
falsches Asset benannt	CSV, Rebinding, MAC-Duplikat
Position springt	AP-X/Y/Rotation, Floorplan, RSSI, Montage
Proximity flattert	RSSI-Schwelle und Umgebung
Count zu hoch	Randomisierung, Scope, Zeitraum, Quellen
Webhook ohne X/Y	Raw-RSSI statt Location-Webhook

Reihenfolge: Erst Erfassung und Identität, dann Location-Metadaten, zuletzt Analysefilter.

18. Datenschutz und Governance

Objekt	Frage
Asset Name	Enthält er unnötige Personen-/Kundendaten?
MAC/UUID	Wer darf stabile Identifikatoren sehen?
Zone History	Wie lange ist Einzelhistorie erforderlich?
SDK-Identität	Welche Information, Einwilligung und Widerrufslogik gilt?
Webhook/API	Wer erhält welche Felder zu welchem Zweck?
Dwell-Label	Verhindert der Name falsche Rollenannahmen?

Zweck und Rechtsgrundlage dokumentieren
Zone statt Koordinate, Aggregat statt Historie bevorzugen
Portal, API und Exporte rollenbasiert trennen
Aufbewahrung und Löschung testen
Schedule-, Kategorien-, Filter- und Zonenänderungen freigeben

19. Produktionscheckliste

Vor Go-live

Use Case und Erfolgskriterium
Subscription und Featurestatus
Zeitzone und Schedule
lückenlose Dwell-Kategorien
Floorplan, Zonen und RSSI-Test
Tagpilot und Filter-Negativtest
eindeutige Namen

Im Betrieb

Freshness-Grenze
Batterie-/Tagwechsel
Zone-/Filter-Change-Log
Dashboarddefinition
Webhook-Monitoring
Count-Plausibilität
Rollen und Löschung

Häufige Fehlannahmen

Behauptung	Bewertung	Einordnung
„Employee ist bestätigt.“	Falsch	Dwell-basiertes Analyselabel.
„Schedule betrifft nur ein Dashboard.“	Falsch	Auch zonenbasierte Daten und Webhooks.
„RSSI ist Meter.“	Falsch	Umgebung und Antennen beeinflussen RSSI.
„Raw RSSI enthält X/Y.“	Falsch	Location-Webhook erforderlich.
„Count ist Personenzahl.“	Falsch	Geräteanzahl und Randomisierung begrenzen die Aussage.

Offizielle Grundlagen

Stand: August 2026. Portalbezeichnungen, Subscriptions, APIs und Funktionen können sich ändern; produktiv gelten aktuelle Juniper-Dokumentation, eigenes Portal und anwendbare Datenschutzvorgaben.