Cisco Meraki Standortanalysen: Was Sie integriert erhalten und wo die Grenzen liegen

Cisco Meraki Access Points enthalten Standortanalysen ohne separate Lizenz. Sie erhalten Übersichten zu Annäherung, Engagement und Treue, eine Gebäudegrundriss-Heatmap sowie die Scanning API für Rohbeobachtungen. Es zählt anonyme Geräte, keine Personen. MAC-Randomisierung schwächt die Zahlen zu wiederholten Besuchen ab, die Ansichten sind pro Netzwerk begrenzt und ohne Captive Portal erhalten Sie keine identifizierten Besucher.

Was sind Cisco Meraki Standortsanalysen?

Cisco Meraki Standortanalysen sind die in Meraki MR Access Points und das Meraki Dashboard integrierten Anwesenheitsberichte. Ihre Access Points erfassen Geräte in der Nähe, einschließlich deren Probe Requests und Datenverkehr. Das Dashboard wandelt diese Erkennungen in Anzahlen, Verweildauern und Muster von Wiederholungsbesuchen für jedes Netzwerk um.

Cisco beinhaltet diese Funktion in Meraki Wireless. Das macht sie zur ersten Anlaufstelle für die meisten Meraki-Umgebungen, die nach Besucherstromdaten suchen. Standardmäßig erhalten Sie vier Funktionen.

Die Ansichten für Annäherung, Engagement und Treue

Das Dashboard gliedert Anwesenheitsdaten in drei Ansichten:

• Annäherung (Proximity) unterteilt erkannte Geräte in Passanten, Besucher und Verbundene. Passanten werden nur kurz oder mit geringer Signalstärke erfasst. Besucher werden nah und lange genug gesehen, um als innerhalb des Gebäudes zu gelten. Verbundene Geräte nutzen Ihr WiFi.
• Engagement teilt Besucher nach Verweildauer ein: 5 - 20 Minuten, 20 - 60 Minuten, 1 - 6 Stunden und 6+ Stunden.
• Treue (Loyalty) gruppiert Besucher nach der Häufigkeit von Wiederholungsbesuchen: Erstbesucher, täglich, wöchentlich und gelegentlich.

Die Dokumentation zu den Standortanalysen von Cisco definiert die Signal- und Zeitgrenzwerte hinter jeder Kategorie. Lesen Sie diese Definitionen, bevor Sie Ihrer Geschäftsführung Zahlen präsentieren.

Die Meraki Standort-Heatmap

Platzieren Sie Ihre Access Points genau auf hochgeladenen Gebäudegrundrissen, zeigt das Dashboard die Gerätedichte im gesamten Bereich an. Es schätzt die Position anhand des RSSI (Received Signal Strength Indicator), der Signalstärke, mit der jeder Access Point ein Gerät erfasst. Die Schätzungen verbessern sich, wenn mehrere Access Points dasselbe Gerät gleichzeitig erfassen.

Die Meraki Scanning API

Die Scanning API überträgt Rohdaten der Gerätebeobachtungen von Ihren Access Points an einen von Ihnen betriebenen Server. Dies ist der Weg aus dem Dashboard heraus in Ihre eigene Daten-Pipeline. Wir erklären unten, wie das funktioniert.

Warum sind Meraki Anwesenheitsdaten für Ihren Standort wichtig?

Anwesenheitsdaten beantworten Fragen, die Kassen und Ticketscanner nicht beantworten können. Wie viele Personen sind am Eingang vorbeigegangen, ohne hineinzugehen? Wie lange sind sie geblieben? Welche Zonen waren am Dienstag um 15:00 Uhr leer?

Teams im Einzelhandel nutzen das Verhältnis von Passanten zu Besuchern als Indikator für die Konvertierung der Schaufensterfront. Hotels nutzen die Verweildauer in der Lobby-Bar oder im Spa, um zu sehen, wo Gäste ihre Abende verbringen. Gebäudemanagement-Teams im Gesundheitswesen können Wartebereiche anhand der tatsächlich beobachteten Besuchermengen statt rein nach Terminlisten dimensionieren.

Der Vorteil liegt auf der Hand. Die Daten werden bereits auf der Hardware erfasst, die Sie besitzen. Die entscheidende Frage ist, wie weit sie Sie bringt, bevor Sie mehr benötigen.

Wie funktioniert die Standort-Analytics von Meraki?

Aktivierung der Funktion

Standort-Analytics ist eine netzwerkweite Einstellung im Meraki-Dashboard. Sie aktivieren sie pro Netzwerk und platzieren dann jeden Access Point auf dem entsprechenden Gebäudeplan. Ohne eine genaue Platzierung sind Heatmaps und Koordinatenschätzungen reine Spekulation. Befolgen Sie für die konkreten Schritte die aktuelle Dokumentation von Cisco, da sich Dashboard-Menüs zwischen Versionen verschieben können.

Zwei Prüfungen, bevor Sie Zahlen vertrauen:

1. Bestätigen Sie, dass jeder Access Point auf der richtigen Etage und an der richtigen Position verankert ist.
2. Sammeln Sie Daten über einige Wochen als Baseline, bevor Sie Zeiträume oder Standorte vergleichen.

Die Dichte der Access Points für die Ortung ist eine Designentscheidung, kein einfacher Schalter. Ein rein auf Abdeckung ausgelegtes Netzwerk kann dazu führen, dass Geräte nur von einem einzigen Access Point erfasst werden. Das liefert zwar eine Anzahl, aber eine schlechte Positionsbestimmung. Unser Leitfaden Netzwerk Best Practices für Veranstaltungsorte und Unternehmen im Jahr 2026 behandelt Platzierung und Dichte.

Die drei Ansichten verstehen

Proximity (Nähe). Achten Sie auf die Verhältnisse, nicht auf die reine Zahl der Passanten. Zu den Passanten gehören auch Geräte, die durch Wände und Fenster erfasst werden, und die MAC-Randomisierung treibt die Zahl in die Höhe, wie unten erläutert. Die Zahlen zu Besuchern und verbundenen Geräten sind stabiler.

Engagement (Verweildauer). Dies ist die zuverlässigste Ansicht für betriebliche Entscheidungen, insbesondere bei verbundenen Geräten. Ein verbundenes Gerät behält in der Regel während des gesamten Besuchs eine einzige private Adresse in Ihrem Netzwerk. Geräte, die sich nie verbinden, wechseln ihre Probe-Adressen, was einen einzigen langen Besuch in mehrere kurze aufteilen kann. Vergleichen Sie denselben Zeitraum Woche für Woche, um zu beurteilen, ob eine Grundrissänderung die Menschen länger gehalten hat.

Loyalty (Treue). Behandeln Sie diese Ansicht mit der größten Vorsicht. Sie basiert darauf, dasselbe Gerät an einem späteren Tag wiederzuerkennen - und moderne Smartphones sind genau so konzipiert, dass sie das verhindern. Der Abschnitt über Einschränkungen erläutert diesen Effekt.

Nutzung der Meraki Scanning API

Über die Meraki Scanning API erhält Ihr Datenteam Rohdaten für die eigene Pipeline. Die Dokumentation der Scanning API von Cisco beschreibt die aktuelle Version und das Payload-Schema. Im Überblick:

• Sie registrieren eine Empfänger-URL im Dashboard. Meraki sendet eine Validierungsanfrage, und Ihr Server muss den Validierungs-String zurückgeben, den das Dashboard anzeigt.
• Meraki überträgt dann JSON-Payloads von Beobachtungen in Batches, laut Cisco-Dokumentation etwa einmal pro Minute.
• Jede Payload enthält ein von Ihnen festgelegtes Shared Secret, sodass Ihr Empfänger alles ablehnen kann, was nicht aus Ihrem Netzwerk stammt.
• WiFi- und Bluetooth Low Energy (BLE)-Beobachtungen treffen als getrennte Streams ein.
• Jede Beobachtung enthält die Client-MAC-Adresse, den Hersteller und den nächstgelegenen Access Point mit dessen RSSI. Verbundene Geräte melden zudem die SSID.
• Standortschätzungen treffen als x/y-Koordinaten sowie Breitengrad/Längengrad ein, zusammen mit einem Abweichungswert, der angibt, wie verlässlich die Schätzung ist.

Die API gibt Ihnen die Kontrolle. Sie legen Ihre eigene Besucherdefinition fest und nutzen dafür Schwellenwerte für RSSI und Mindestverweildauer, die zu Ihrem Gebäude passen. Sie können Positionen verwerfen, deren Abweichung zu groß ist, um nützlich zu sein. Sie können MAC-Adressen beim Empfang hashen, sodass rohe Kennungen niemals Ihr Data Warehouse erreichen.

Sie überträgt Ihnen auch die Verantwortung. Sie hosten den Empfänger, halten ihn verfügbar, fangen Schemaänderungen zwischen API-Versionen ab und tragen die GDPR-Pflichten für Gerätekennungen. Planen Sie dafür Entwicklungszeit ein, nicht nur für den initialen Aufbau.

Wie fügt sich das in Ihre bestehende Infrastruktur ein?

Die nativen Meraki-Ansichten und die Scanning API messen beide Geräte. Ein Captive Portal misst Personen, die sich aktiv identifiziert haben. Ein Captive Portal ist die Webseite, die ein Gerät sieht, bevor es Internetzugang erhält, und auf der sich der Besucher anmeldet oder die Bedingungen akzeptiert. Beide beantworten unterschiedliche Fragen, weshalb die meisten ausgereiften Netzwerke beides nutzen.

Purple betreibt Captive Portal und WiFi Analytics als Cloud-Overlay auf Ihren bestehenden Meraki Access Points. Purple ist hardwareunabhängig und funktioniert über Cisco Meraki, HPE Aruba, Ruckus, Juniper Mist, Ubiquiti UniFi, Cambium, Extreme Networks und Fortinet hinweg.

Funktion	Meraki Dashboard-Ansichten	Meraki Scanning API	Purple auf Meraki
Was gemessen wird	Anonyme Gerätezahlen, Verweildauer und Wiederkehrfrequenz	Rohe Beobachtungen pro Gerät in Batches etwa einmal pro Minute	Angemeldete Besucher mit Profil und Einwilligungshistorie
Umfang	Ein Netzwerk zur gleichen Zeit	Jedes Netzwerk, das Sie auf Ihren Empfänger ausrichten	Jede Location in einer zentralen Übersicht
Historie	Ciscos veröffentlichte Speicherfrist für Standortdaten	Was auch immer Ihr eigener Speicher aufbewahrt	Im Purple Platform gespeichert (ISO 27001-zertifiziert)
Auswirkung von MAC-Randomisierung	Treue und Passanten verzerrt	Gleiche Verzerrung, aber Sie können sie modellieren	Wiederkehrende Besuche werden dem Anmeldeprofil zugeordnet
Identifiziert den Besucher	Nein	Nein	Ja, durch bewusste Opt-ins
Marketing-Einwilligung	Nicht erfasst	Nicht erfasst	Bei der Anmeldung erfasst
Betriebsaufwand	Pro Netzwerk aktivieren, Access Points auf Gebäudeplänen platzieren	Empfänger, Speicher und Datenmodell aufbauen, hosten und warten	Captive Portal auf Meraki konfigurieren, keine neue Hardware
Kosten	In Meraki Wireless enthalten	Enthalten, zuzüglich Ihrer Hosting- und Entwicklungszeit	Purple Abonnement neben Ihrer Meraki Lizenz

Wo liegen die Grenzen der Meraki Standort-Analytics?

Speicherfristen

Das Dashboard ist für aktuelle operative Ansichten ausgelegt, nicht für mehrjährige Historien. Cisco veröffentlicht die Speicherfristen in der Meraki-Dokumentation zur Datenspeicherung. Überprüfen Sie den aktuellen Wert, bevor Sie jemandem einen Jahresvergleich versprechen.

Wenn Sie eine lange Historie benötigen, streamen Sie die Daten vom ersten Tag an über die Scanning API in Ihren eigenen Speicher. Die API überträgt Beobachtungen nahezu in Echtzeit. Sie gibt keine historischen Daten erneut wieder - was Ihr Empfänger verpasst hat, ist verloren.

Ihr eigener Speicher bringt eigene Verpflichtungen mit sich. Das Speicherbegrenzungsprinzip der GDPR, Artikel 5(1)(e), verlangt, dass Sie personenbezogene Daten nicht länger als nötig aufbewahren. Legen Sie eine Speicherfrist fest, dokumentieren Sie diese und löschen Sie die Daten planmäßig.

Aggregation auf Standortebene

Die nativen Ansichten sind um ein einzelnes Netzwerk herum aufgebaut, was in der Regel einen einzelnen Standort bedeutet. Ein Bestand von 60 Filialen wird so zu 60 Diagrammsätzen. Ein standortübergreifender Vergleich bedeutet, dass Sie Netzwerk für Netzwerk exportieren oder eine eigene Pipeline über die Ortungs-API aufbauen müssen.

Die nativen Ansichten können Ihnen auch nicht mitteilen, dass ein Käufer in derselben Woche Ihre Filialen in Leeds und Manchester besucht hat. Jedes Netzwerk sieht nur seine eigenen Geräte, und randomisierte Adressen verhindern jeden Versuch eines Abgleichs über mehrere Standorte hinweg.

MAC-Randomisierung und Treuesegmente

Dies ist die Einschränkung, die für einen Analytics-Experten am schwersten wiegt. Seit iOS 14 und Android 10 verwenden Smartphones standardmäßig eine private, randomisierte MAC-Adresse für jedes Netzwerk. Probe-Requests von Geräten, die sich nie verbinden, nutzen schon viel länger randomisierte, sich häufig ändernde Adressen. Sowohl Apple als auch Google dokumentieren dieses Verhalten.

Die Auswirkungen auf die Meraki Präsenzdaten sind vorhersehbar:

• Passanten werden aufgebläht. Ein einziges Smartphone, das sich nie verbindet, kann als mehrere Geräte erscheinen, wenn sich seine Probe-Adresse ändert.
• Erstbesucher werden aufgebläht. Ein wiederkehrendes Smartphone, das sich nicht verbindet, zeigt eine neue Adresse, sodass das Dashboard einen Fremden registriert.
• Tägliche und wöchentliche Treue sinken. Wiederholte Besuche werden aus demselben Grund nicht gezählt.

Verbundene Geräte schneiden besser ab, da die vergebenen privaten Adressen pro Netzwerk auf Ihrer SSID in der Regel bestehen bleiben. Neuere Apple-Releases bieten eine Rotationsoption, die selbst diese Adresse im Laufe der Zeit ändert. Es ist zu erwarten, dass die gemessene Treue verbundener Geräte mit zunehmender Nutzung weiter abnimmt.

Die Faustregel: Berichten Sie Treue als Trend für verbundene Geräte, niemals als absoluten Anteil wiederkehrender Besucher. Präsentieren Sie sie dem Unternehmen niemals als "Wiederholungskunden".

Keine identifizierte Besucherebene

Native Analytics weiß nie, wer eine Person ist. Es gibt keinen Namen, keine E-Mail-Adresse, keinen Einwilligungsnachweis und keine Verknüpfung zu Ihrem CRM- oder Immobilienverwaltungssystem. Sie können sehen, dass die Verweildauer in einer Zone um 12% gestiegen ist. Sie können diesen Besuchern jedoch nichts senden oder messen, wie viel sie ausgegeben haben.

Diese Ebene erfordert ein Captive Portal, in dem Besucher sich aktiv identifizieren. Guest WiFi von Purple erfasst First-Party-Daten über bewusste Opt-ins und lässt sich in CRM- und Marketingplattformen integrieren. Wiederholte Besuche werden dann dem Profil zugerechnet, mit dem sich ein Besucher anmeldet, und nicht nur der Geräteadresse allein. Purple hat im Jahr 2024 440 Millionen Anmeldungen in über 80.000 aktiven Standorten verarbeitet (Purple Daten).

Wie sich Meraki Standort-Analytics an realen Standorten auswirkt

Die folgenden zwei Szenarien sind anschauliche Rechenbeispiele. Die Zahlen zeigen die Methodik, nicht die Ergebnisse eines namentlich genannten Standorts.

Szenario 1: Ein Modehändler mit 60 Filialen im Filialvergleich

Ausgangslage. Das Analytics-Team benötigte ein wöchentliches Ranking der Filialen nach Verweildauer der Käufer. Jede Filiale betrieb ihr eigenes Meraki Netzwerk. Die Erstellung des Berichts bedeutete, 60 Dashboards zu öffnen und Interaktionszahlen in eine Tabelle zu kopieren, was jede Woche etwa einen Arbeitstag in Anspruch nahm.

Umsetzung. Das IT-Team richtete einen Scanning-API-Empfänger ein und steuerte alle 60 Netzwerke darauf aus. Es hashte MAC-Adressen bei Eingang, wandte einen einheitlichen RSSI-Schwellenwert für das gesamte Gebäude an und verwarf Beobachtungen mit hoher Varianz. Es legte eine Aufbewahrungsfrist von 13 Monaten fest, die in den GDPR-Aufzeichnungen dokumentiert wurde.

Ergebnis. Der wöchentliche Bericht wurde zu einer automatisierten Abfrage, die alle 60 Filialen abdeckte. Das Team bestätigte auch, was die Treue-Kategorien verbargen. In Filialen mit geringer WiFi-Nutzung registrierten sich mehr als 80 % der Besucher als Erstbesucher, verglichen mit einer weit niedrigeren Zahl in den eigenen App-Daten des Einzelhändlers. Die Treue-Metrik wurde aus den Vorstandsunterlagen entfernt und durch Verweildauer sowie das Verhältnis von Besuchern zu Passanten ersetzt.

Szenario 2: Ein 200-Zimmer-Hotel auf der Suche nach Wiederholungsgästen

Ausgangslage. Das kaufmännische Team nutzte die Meraki Treue-Ansicht als Maßstab für Wiederholungsgäste. Die Ansicht zeigte die meisten Geräte als Erstbesucher an. Dies widersprach dem Reservierungssystem, das einen hohen Anteil an Wiederholungsbuchungen auswies.

Umsetzung. Das Team akzeptierte, dass Treue-Kategorien Geräteadressen messen und keine Gäste. Es fügte ein Purple Captive Portal auf den bestehenden Meraki Access Points hinzu, mit expliziten Opt-ins für Marketing bei der Anmeldung. Die Meraki Interaktionsansicht für die Verweildauer in den Bereichen Bar, Restaurant und Spa wurde beibehalten.

Ergebnis. Wiederholungsgäste wurden nun bei der Anmeldung identifiziert, anstatt aus Adressen abgeleitet zu werden. Gäste mit Opt-in flossen für Angebote vor der Anreise in das CRM. Die Interaktionsdaten dienten weiterhin als Orientierung für die Personalplanung in der Bar. Wenn Sie dies für einen neuen Vertrag spezifizieren, listet unsere Checkliste für Hotel-WiFi-Ausschreibungen: Authentifizierung, Inhaltsfilterung und Gästemarketing die zu stellenden Fragen auf.

Was sollten Sie als Nächstes tun?

Entscheiden Sie zunächst, welche Frage Sie beantworten möchten. Gerätezählungen und identifizierte Besucher sind unterschiedliche Produkte.

Ihre Situation	Was zu verwenden ist
Ein Standort, betriebliche Fragen zu stark frequentierten Zonen und Zeiten	Meraki Dashboard-Ansichten und die Standort-Heatmap
Viele Standorte, ein Datenteam, Bedarf an langer Historie	Meraki Scanning-API in Ihr eigenes Warehouse
Notwendigkeit, vertretbare Wiederholungsbesuche zu melden	Captive Portal mit Logins, keine Gerätetreue-Kategorien
Notwendigkeit, Besucher zu kontaktieren oder Besuche mit Ausgaben zu verknüpfen	Purple Guest WiFi und WiFi Analytics auf Meraki
Begrenzte Entwicklungskapazitäten, viele Standorte	Purple WiFi Analytics anstelle einer selbst aufgebauten Pipeline

Gehen Sie dann vier Schritte durch:

1. Überprüfen Sie die Platzierung auf dem Grundriss in jedem Netzwerk, bevor Sie einer Heatmap vertrauen.
2. Entfernen Sie Treuezahlen aus dem Executive Reporting, bis Sie diese angemeldeten Besuchern zuordnen können.
3. Legen Sie Ihre Aufbewahrungsfrist fest und streamen Sie jetzt über die Scanning-API, wenn Sie eine Historie benötigen.
4. Fügen Sie über ein Captive Portal eine Identifikationsebene hinzu, wenn Sie Personen und nicht nur Geräte erfassen möchten.

Für nichts davon sind neue Access Points erforderlich. Unser Blogbeitrag Why your next WiFi upgrade doesn't need new hardware erklärt den Overlay-Ansatz auf Meraki.

Häufig gestellte Fragen

Ist Cisco Meraki Location Analytics in der Meraki-Lizenz enthalten?

Ja, Location Analytics und die Scanning-API sind ohne zusätzliche Kosten in Meraki Wireless enthalten. Sie zahlen nichts extra, um die Näherungs-, Engagement- und Treueansichten oder die Standort-Heatmap zu aktivieren. Die Scanning-API ist ebenfalls enthalten. Sie tragen jedoch die Kosten für das Hosten eines Empfängers, das Speichern von Beobachtungen und die Wartung der Pipeline. Bei einem Netzwerk mit mehreren Standorten ist dieser Engineering-Aufwand in der Regel der größere Kostenfaktor.

Kann mir Meraki Location Analytics sagen, wer meine Besucher sind?

Nein, Meraki Location Analytics zählt anonyme Geräte, keine identifizierten Personen. Es zeichnet Geräteadressen, Signalstärke und die geschätzte Position auf - ohne Namen, E-Mail-Adresse oder Einwilligungsnachweis. Um Besucher zu identifizieren, benötigen Sie ein Captive Portal, über das sie sich aktiv anmelden. Purple fügt diese Ebene auf Ihren bestehenden Meraki Access Points hinzu, erfasst First-Party-Daten durch bewusste Einwilligungen und verknüpft Besuche mit einem Profil.

Wie lange speichert Meraki Location-Analytics-Daten?

Meraki bewahrt Standortdaten für den Zeitraum auf, der in der veröffentlichten Dokumentation von Cisco zur Datenaufbewahrung für Meraki festgelegt ist. Überprüfen Sie dort die aktuellen Angaben, bevor Sie Vorjahresberichte planen. Wenn Sie eine längere Historie benötigen, streamen Sie Beobachtungen vom ersten Tag an über die Scanning-API in Ihren eigenen Speicher. Die API gibt vergangene Daten nicht erneut aus. Ihr eigener Speicher muss dann den GDPR-Grundsatz der Speicherbegrenzung einhalten.

Sind Meraki-Präsenzdaten personenbezogene Daten gemäß GDPR?

Ja, MAC-Adressen können gemäß GDPR als personenbezogene Daten gelten, da sie sich auf ein Gerät beziehen, das von einer identifizierbaren Person getragen wird. Das britische ICO hat dies in seinen Leitfäden zur WiFi-Standortanalyse bestätigt. Hash- oder verkürzen Sie Adressen beim Eingang, dokumentieren Sie Ihre Rechtsgrundlage, legen Sie eine Aufbewahrungsfrist fest und bringen Sie eine klare Beschilderung an. Ein Captive Portal ergänzt die explizite Einwilligung für Marketingzwecke.

Wie genau sind die Besucher-Treuedaten von Meraki?

Die Treuedaten von Meraki sind als absolutes Maß aufgrund der MAC-Randomisierung unzuverlässig. Seit iOS 14 und Android 10 verwenden Smartphones zufällige Adressen, wodurch wiederkehrende Geräte wie neue Geräte aussehen. Die Zahl der Erstbesucher wird künstlich erhöht und die Zahl der Wiederholungsbesuche verringert. Verbunden Geräte liefern stabilere Werte, da deren netzwerkspezifische Adresse in der Regel bestehen bleibt. Nutzen Sie Treuedaten nur als Trend für verbundene Geräte und zählen Sie Wiederholungsbesucher über die Anmeldungen.

Funktioniert Purple mit meinen bestehenden Cisco Meraki Access Points?

Ja, Purple läuft auf Ihren bestehenden Cisco Meraki Access Points als Cloud-Overlay. Sie konfigurieren das Captive Portal auf Meraki und behalten Ihre aktuelle Hardware und Lizenzen. Purple ist hardwareunabhängig, sodass derselbe Ansatz auch auf HPE Aruba, Ruckus, Juniper Mist, Ubiquiti UniFi, Cambium, Extreme und Fortinet funktioniert. Umgebungen mit verschiedenen Herstellern werden über eine einzige WiFi Analytics-Ansicht ausgewertet.\n\n### Sollte ich auf der Meraki Scanning API aufbauen oder eine Analytics-Plattform nutzen?\n\nBauen Sie auf der Scanning API auf, wenn Sie ein Datenteam haben und die volle Kontrolle über Definitionen und Speicherung wünschen. Wählen Sie eine Plattform, wenn Ihnen die Entwicklungskapazitäten fehlen oder Sie identifizierte Besucher benötigen. Die API liefert nur rohe Gerätebeobachtungen, sodass Sie nach wie vor mit MAC-Randomisierung konfrontiert sind und keine Einwilligungserklärung vorliegt. Viele Umgebungen nutzen beides: die API für die Geräateverweildauer und Purple für angemeldete Besucher.