Heatmapping vs Presence Analytics: Differenze Tecniche
Questa guida tecnica autorevole illustra in dettaglio le differenze strutturali e operative cruciali tra il WiFi heatmapping e la presence analytics per i gestori di grandi spazi aziendali. Fornisce ai leader IT, ai progettisti di rete e ai direttori operativi schemi di implementazione pratici, scenari applicativi reali e best practice indipendenti dai fornitori per massimizzare il ROI dall'infrastruttura wireless esistente.
Ascolta questa guida
Visualizza trascrizione del podcast
執行摘要
對於管理複雜實體場域的企業 IT 團隊而言，理解 WiFi 熱圖（heatmapping）與存在分析（presence analytics）之間的區別已不再是可有可無的選項。雖然這兩者在行銷文獻中經常被混為一談，但它們在根本上是服務於不同營運任務的截然不同的技術。
WiFi 熱圖是一種以基礎設施為中心的診斷工具，旨在測量射頻（RF）訊號傳播、識別覆蓋盲點並優化存取點（AP）的配置。存在分析則是一個商業智慧層，它利用相同的網路基礎設施來追蹤裝置移動、計算停留時間，並繪製訪客在實體空間中的行為軌跡。
本指南對這兩種方法進行了嚴謹的技術比較。我們將探討在零售、旅宿和大型公共環境中有效部署這些系統所需的底層架構、數據收集方法和實作框架。透過將這些功能對接至 Purple 的 Guest WiFi 和 WiFi Analytics 平台，我們為您提供了一套藍圖，幫助您從現有的網路硬體中榨取最大的投資報酬率（ROI）——而無需對實體基礎設施進行全面汰換。
技術深挖：架構與方法論
WiFi 熱圖：RF 診斷層
WiFi 熱圖的核心是依賴接收訊號強度指示（RSSI）測量值來構建網路覆蓋範圍的視覺化呈現。此過程對於網路規劃、故障排除和持續的效能驗證至關重要。
數據收集機制分為三類。主動調查（Active surveys）涉及裝置主動與 AP 關聯，以測量吞吐量、封包遺失率和延遲以及 RSSI——從用戶端視角提供網路效能視圖。被動調查（Passive surveys）使用掃描器在不關聯的情況下監聽所有頻道上的信標訊框（beacon frames）和探測回應（probe responses），提供包括同頻干擾和惡意 AP 檢測在內的整體 RF 環境視圖。預測建模（Predictive modelling）則在實際部署前，利用軟體根據平面圖、牆壁衰減值和 AP 天線圖形來模擬覆蓋範圍，實現部署前的驗證。
關鍵技術指標包括訊噪比（SNR），這對於確定特定區域內可實現的實際數據傳輸速率至關重要，且比單純的 RSSI 原始值更能可靠地反映品質。頻道重疊識別（Channel overlap identification）則能揭示相鄰 AP 在重疊頻率上運作的區域，這種情況會導致破壞性干擾，即使在訊號強度看似充足的情況下也會降低吞吐量。
存在分析：行為智慧層
存在分析將焦點從網路基礎設施轉移到穿梭其中的裝置上。它主要依賴擷取探測請求（probe requests）——智慧型手機和平板電腦在搜尋已知網路時發射的管理訊框——以便在不需要未關聯裝置進行連線的情況下對其進行追蹤。
數據收集架構分為三個階段。首先，AP 或專用感測器攔截包含裝置 MAC 位址和訊號強度的未關聯探測請求。其次，為了符合包括 GDPR 和 CCPA 在內的隱私框架，MAC 位址在傳輸到分析引擎之前，會立即在邊緣端進行雜湊處理（使用 SHA-256 或同等演算法）——確保沒有任何個人識別資訊（PII）以原始格式跨網路傳輸。第三，三邊測量（trilateration）引擎比較單一裝置在三個或更多 AP 上的 RSSI，以計算該裝置的大致 X/Y 座標。欲深入瞭解此機制，請參閱我們的指南： WiFi 定位機制解析：三邊測量與 RSSI 詳解 。
關鍵區別：覆蓋範圍 vs. 情境資訊
企業部署中最常見的誤解是，認為提供充足覆蓋範圍的網路就自動做好了進行存在分析的準備。這是錯誤的。覆蓋範圍僅要求裝置能從一個 AP 接收到可用訊號。而用於存在分析的精確三邊測量，則要求裝置必須同時被至少三個 AP 偵測到，且訊號強度需達到 -75 dBm 或更佳。這種根本性的差異導致了完全不同的 AP 密度和配置需求。
| 維度 | WiFi 熱圖 | 存在分析 |
|---|---|---|
| 主要數據源 | 來自 AP 信標的 RSSI | 來自用戶端裝置的探測請求 |
| 基礎設施需求 | 標準覆蓋密度 | 高密度（每個區域 ≥3 個 AP） |
| 數據更新率 | 接近即時（5–15 秒調查） | 即時（10–30 秒更新） |
| 隱私合規性 | 不收集 PII | 透過 MAC 雜湊符合 GDPR/CCPA |
| 主要應用場景 | 網路規劃與優化 | 訪客行為與商業智慧 |
| 關鍵輸出指標 | 訊號強度 (dBm), SNR | 停留時間、客流量、區域轉換率 |
實作指南：策略性部署
部署這些技術需要採取分階段的方法，平衡技術限制與業務目標。試圖在未針對存在分析設計的網路上部署該技術，是專案失敗最常見的單一原因。re。
階段 1：透過熱圖進行基礎設施評估。 在實施存在感分析之前，必須先驗證底層網路。進行全面的被動熱圖調查，以建立基準 RF 效能。識別訊號覆蓋盲區、同頻干擾區域以及高多路徑干擾區域（這在設有金屬貨架的零售環境中很常見）。此調查數據將直接為階段 2 所需的 AP 密度與部署位置決策提供依據。
階段 2：針對三邊測量進行網路重新設計。 根據熱圖數據，以存在感分析為考量重新設計 AP 的部署位置。將 AP 移至場域的周邊，而不是走廊中央——這能將三邊測量計算向外拉，並顯著提高空間精確度。確保每個目標區域都至少有三個 AP 覆蓋，且訊號強度達到 -72 dBm 或更高。在高干擾環境（如倉庫、具有金屬結構的體育場）中，可使用 BLE (Bluetooth Low Energy) 信標來輔助 WiFi 三邊測量，將空間解析度提升至 1-2 公尺。
階段 3：平台整合。 將分析引擎與您現有的硬體整合。Purple 的硬體相容平台透過標準 API 連接到包括 Cisco、Aruba、Ruckus 和 Meraki 在內的主要廠商——提取匿名化的存在感數據，而無需專有的覆蓋感測器或完整的硬體更換週期。
階段 4：區域配置與校準。 在分析平台內定義邏輯區域，以對應到實體業務區域（例如：「結帳區」、「大廳」、「女裝區」、「入口漏斗」）。將這些區域與熱圖階段中識別的實體 AP 覆蓋模式對齊。在正式上線前，進行校準測試以驗證區域邊界是否精確。
企業環境的最佳實踐
持續校準是不可妥協的。 RF 環境是動態變化的。零售業的庫存量、活動中的臨時結構，甚至人體都會吸收 RF 訊號。定期每季安排被動熱圖調查，以確保存在感分析引擎在精確的基準數據上運作。零售環境中季節性的賣場陳設調整，可能會在一夜之間使數個月的校準數據失效。
主動應對 MAC 隨機化。 現代作業系統（iOS 14+、Android 10+）會輪替 MAC 地址以防止被動追蹤。先進的分析平台必須採用啟發式演算法（分析訊號模式和探測時間）來拼接碎片的連線階段，以確保在 MAC 輪替的情況下仍能精確計算停留時間。然而，最有效的緩解措施是透過 Captive Portal 鼓勵裝置進行關聯。正如在 How a wi fi assistant Enables Passwordless Access in 2026 中所討論的，現代驗證方法可在登入時將匿名的 MAC 地址無縫轉換為已知的 CRM 個人檔案，從而提供確定性而非機率性的追蹤。
實施角色型數據存取。 存在感分析數據即使在裝置層級進行了匿名化，也可能透露敏感的營運模式。實施與 IEEE 802.1X 驗證標準一致的角色型存取控制 (RBAC)，以確保只有授權人員才能存取原始分析數據，同時將彙整的儀表板提供給營運團隊。
將區域定義與業務 KPI 對齊。 區域配置的細緻度應直接反映您的業務問題。如果您需要衡量特定端架陳列的轉換影響，請在該細緻度層級定義一個區域。如果您只需要了解部門之間的大致人流量，較粗略的區域可以減少計算開銷並簡化報表。
疑難排解與風險緩解
故障模式：定位數據不精確（裝置跳躍）
症狀： 在分析儀表板中，裝置似乎在區域之間傳送，其移動路徑在物理上是不可能的。
根本原因： AP 密度不足或多路徑干擾——訊號從金屬表面反射，產生虛假的訊號讀數，導致三邊測量引擎混淆。
緩解措施： 重新進行熱圖調查，重點關注 SNR（信噪比）而非僅僅是 RSSI。某個區域可能顯示出足夠的訊號強度，但由於反射訊號而導致 SNR 較差。考慮在高干擾區域部署 BLE 信標，以更可靠的短距離訊號來增強 WiFi 定位數據。
故障模式：入口處停留時間異常偏高
症狀： 分析儀表板顯示場域入口附近的訪客計數和停留時間異常偏高，使整體客流量指標虛高。
根本原因： 入口附近的 AP 正在擷取來自場域邊界外街道或停車場裝置的探測請求。
緩解措施： 調整分析平台中的 RSSI 閾值。排除 RSSI 弱於 -80 dBm 的裝置數據，以過濾掉外部流量。此外，定義一個專門的「入口緩衝」區域，並將其排除在轉換率計算之外。
故障模式：MAC 隨機化導致連線階段碎片化
症狀： 不重複訪客計數顯著高於預期，且平均停留時間異常短暫。
根本原因： iOS 和 Android 的 MAC 隨機化正在將單個訪客的連線階段碎片化為多個虛擬裝置。
緩解措施： 部署 Captive Portal 以鼓勵裝置進行關聯。啟用分析平台的連線階段拼接演算法，該演算法利用訊號模式的連續性和時間啟發式方法來重構碎片的連線階段。對於顧客 WiFi 使用率高的 零售 環境，這通常可以解決 70-80% 的碎片化問題。
投資報酬率與業務影響
從基本網路建置到智慧化營運的轉變 收集從根本上改變了 IT 部門在組織內的價值定位。
零售營運代表了最明確的 ROI 案例。藉由將區域停留時間與銷售點（POS）數據進行關聯，IT 可以直接證明網路基礎設施如何對店面佈局優化和提高轉換率做出貢獻。一家擁有 50 家分店的零售商，如果透過 Presence 數據分析引導的佈局調整，使端架停留時間提高 5%，就能產生直接歸因於網路投資的可衡量營收增長。如需特定產業的部署指南，請參閱我們的 Retail 部門解決方案。
旅宿業部署可提供雙重 ROI。熱圖分析可確保整個物業內語音通話（Voice-over-WiFi）的 802.11r 快速 BSS 切換順暢無阻，直接減少顧客投訴。同時，Presence 數據分析可識別利用率低的設施（如 SPA、餐廳、商務中心），從而能透過 Captive Portal 進行精準的場域內行銷。如需更廣泛的顧客體驗策略，請參閱 How To Improve Guest Satisfaction: The Ultimate Playbook 。
公共部門與智慧城市部署正越來越多地利用 Presence 數據分析進行人群管理、交通樞紐優化和資源分配。正如我們在 Purple Appoints Iain Fox as VP Growth – Public Sector to Drive Digital Inclusion and Smart City Innovation 公告中所強調的，強大的數據分析是智慧城市倡議的基石，能為基礎設施投資和服務部署提供數據驅動的決策支援。
醫療保健環境可受益於 Presence 數據分析以優化患者分流，減少急診室和門診診所的瓶頸。結合 Purple 的 Healthcare 平台功能，去識別化的停留數據可以直接為人力配置模型和檢傷分類協定提供資訊，而無需處理任何患者的 PII。
透過將熱圖分析視為基礎診斷，並將 Presence 數據分析視為商業智慧層，IT 領導者可以將其無線網路從成本中心轉變為策略資產，直接為整個組織的商業和營運決策提供支援。
Definizioni chiave
RSSI (Received Signal Strength Indicator)
Una misurazione del livello di potenza di un segnale radio ricevuto, tipicamente espressa in dBm (decibel rispetto a un milliwatt). I valori variano da circa 0 dBm (più forte) a -100 dBm (più debole), con -65 dBm o valori superiori considerati eccellenti per le installazioni aziendali.
La metrica fondamentale sia per la mappatura termica (determinazione della qualità della copertura) che per l'analisi delle presenze (calcolo della distanza per la trilaterazione). I team IT riscontrano l'RSSI negli strumenti di indagine, nelle console di gestione degli AP e nelle piattaforme di analytics.
Trilaterazione
Il processo di determinazione della posizione di un punto misurando la sua distanza da tre o più punti di riferimento noti (access point), utilizzando la geometria dei cerchi sovrapposti. Si distingue dalla triangolazione, che utilizza gli angoli anziché le distanze.
L'algoritmo principale utilizzato dai motori di analisi delle presenze per calcolare le coordinate X/Y di un dispositivo su una planimetria. Richiede un minimo di tre AP con letture RSSI affidabili per produrre una stima accurata della posizione.
Probe Request
Un frame di gestione 802.11 inviato da un dispositivo client wireless per rilevare le reti disponibili. Le probe request vengono trasmesse su tutti i canali e contengono l'indirizzo MAC del dispositivo e, in alcuni casi, gli SSID delle reti precedentemente connesse.
La fonte di dati primaria per l'analisi passiva delle presenze. I dispositivi emettono probe request anche quando non sono connessi a nessuna rete, consentendo alle piattaforme di analytics di tracciare i visitatori non associati.
Randomizzazione MAC
Una funzione di privacy implementata nei sistemi operativi moderni (iOS 14+, Android 10+) in cui un dispositivo utilizza un indirizzo MAC temporaneo e generato casualmente durante la ricerca di reti, anziché il suo indirizzo hardware permanente (OUI).
La sfida tecnica più significativa per l'analisi passiva delle presenze. Fa sì che le singole sessioni dei visitatori appaiano come molteplici dispositivi distinti, gonfiando il conteggio dei visitatori unici e riducendo i tempi di permanenza. Mitigata dall'autenticazione tramite Captive Portal.
Interferenza Multipath
Un fenomeno per cui un segnale radio raggiunge l'antenna ricevente attraverso due o più percorsi di propagazione, tipicamente a causa della riflessione sulle superfici. I segnali riflessi arrivano con diversi ritardi di fase, causando interferenze costruttive o distruttive che distorcono le letture RSSI.
Una delle cause principali di dati di localizzazione imprecisi nell'analisi delle presenze, in particolare in ambienti retail con scaffalature metalliche o magazzini con sistemi di stoccaggio. Identificata durante i rilievi di mappatura termica tramite letture SNR anomale.
Indagine Passiva
Una tecnica di mappatura termica in cui lo strumento di indagine ascolta tutto il traffico RF su tutti i canali senza connettersi a nessuna rete specifica. Acquisisce dati da tutti gli AP, comprese le reti vicine e i dispositivi non autorizzati.
Essenziale per identificare le interferenze co-canale, gli AP non autorizzati e l'intero ambiente RF prima di implementare l'analisi delle presenze. Offre una panoramica più completa rispetto alle indagini attive, che acquisiscono solo i dati della rete di destinazione.
Tempo di Permanenza
La durata totale in cui un dispositivo monitorato rimane all'interno di una zona fisica definita, calcolata dalla prima probe request o evento di associazione fino all'ultimo segnale rilevato prima che il dispositivo lasci la zona.
Una metrica aziendale chiave derivata dall'analisi delle presenze. Utilizzata per misurare il coinvolgimento dei clienti nel retail (tempo trascorso davanti a un espositore), i tempi di attesa nella sanità (durata della coda in pronto soccorso) e la partecipazione alle sessioni in contesti congressuali.
Risoluzione Spaziale
The degree of accuracy to which a presence analytics system can determine a device's physical location, typically expressed as a radius in metres (e.g., accurate to within 3 metres). Determined by AP density, AP placement geometry, and environmental RF characteristics.
Determines the granularity of presence analytics insights. Higher spatial resolution enables zone definitions at the level of individual displays or fixtures, while lower resolution only supports department-level or room-level analysis.
Signal-to-Noise Ratio (SNR)
The ratio of the desired signal power to the background noise power in a given location, expressed in dB. A higher SNR indicates a cleaner signal environment. An SNR of 25 dB or above is generally required for reliable high-throughput WiFi.
A more reliable indicator of WiFi quality than RSSI alone. An area can show strong RSSI but poor SNR due to interference, resulting in degraded throughput and unreliable location data. Always review SNR alongside RSSI in heatmapping surveys.
Esempi pratici
Un magazzino di vendita al dettaglio di 50.000 piedi quadrati riscontra dati di presence analytics imprecisi: i percorsi dei visitatori appaiono irregolari e i tempi di sosta sono fortemente falsati. La rete attuale è stata progettata esclusivamente per la connettività di base dei lettori di codici a barre del personale, con gli AP posizionati lungo le corsie centrali.
Eseguire un'indagine di heatmapping passiva per stabilire una baseline di RSSI e SNR in tutta l'area. Prestare particolare attenzione al degrado del SNR in prossimità delle scaffalature metalliche, che rappresentano la principale fonte di interferenza multipath in questo ambiente.
Riprogettare il layout degli AP. Spostare gli AP dalle posizioni nelle corsie centrali alle pareti perimetrali. Ciò migliora notevolmente la geometria della trilaterazione garantendo che i dispositivi vengano "attratti" verso i bordi del calcolo, riducendo l'ambiguità angolare che causa rilevamenti di posizione fantasma.
Aumentare la densità degli AP per garantire che ogni metro quadrato sia coperto da almeno tre AP a -72 dBm o superiore. In uno spazio di 50.000 piedi quadrati con scaffalature alte, ciò richiede in genere dal 20% al 30% di AP in più rispetto a una progettazione di copertura di base.
Configurare la piattaforma di analytics per applicare una soglia minima di RSSI di -78 dBm, filtrando i segnali deboli che contribuiscono a calcoli di posizione errati.
Implementare un Captive Portal che offra Guest WiFi gratuito per incoraggiare i visitatori a connettersi, aggirando la randomizzazione del MAC a livello di sistema operativo per i dispositivi associati e fornendo dati di tracciamento deterministici.
Un grande centro congressi ha l'esigenza di tracciare il flusso dei partecipanti tra una sala plenaria da 2.000 posti e otto sale riunioni secondarie, al fine di ottimizzare il servizio di catering e la pianificazione della capienza delle sessioni. Dispongono di un ambiente WiFi legacy multi-vendor con AP Cisco nella sala principale e AP Aruba nelle sale secondarie.
Implementare una piattaforma di analytics indipendente dall'hardware (ad esempio, la piattaforma di Purple) in grado di importare simultaneamente i dati syslog e RTLS standard sia dai controller Cisco che da quelli Aruba tramite le rispettive API, normalizzando i dati in un flusso di analytics unificato.
Eseguire un'indagine di heatmapping focalizzata in particolare sulle pareti divisorie tra le sale secondarie. Le pareti divisorie sottili sono altamente permeabili ai segnali WiFi, causando una significativa sovrapposizione di zona (bleed) in cui un dispositivo nella Sala A sembra trovarsi nella Sala B.
Definire precise zone poligonali all'interno della piattaforma di analytics corrispondenti a ciascuna sala specifica e sala secondaria. Impostare soglie limite di RSSI (in genere -70 dBm) per evitare interferenze tra le pareti divisorie.
Integrare l'API di occupazione della zona risultante con la dashboard operativa del team di catering per ricevere avvisi in tempo reale, ad esempio attivando una notifica quando una sala secondaria raggiunge l'80% della capienza.
Correlare i dati sull'occupazione delle zone con i programmi delle sessioni per creare modelli predittivi per la pianificazione degli eventi futuri.
Domande di esercitazione
Q1. Your retail operations director wants to measure the conversion rate of a new end-cap display in a specific aisle. The IT team confirms there is strong WiFi coverage throughout the store — all devices connect reliably and throughput is excellent. Is the network ready to deliver accurate presence analytics for this specific display?
Suggerimento: Consider the difference between 'strong coverage' (one AP providing a usable signal) and the trilateration requirements for accurate zone-level location data.
Visualizza risposta modello
Not necessarily. Strong coverage and reliable connectivity only prove that devices can associate with the network. To accurately track dwell time at a specific end-cap display, the analytics engine needs to trilaterate the device's position to that specific zone — which requires the device to be simultaneously audible to at least three APs at -75 dBm or better. A store designed for coverage may achieve this with only one or two APs in that aisle. Before confirming readiness, run a heatmapping survey specifically to validate that the end-cap zone meets the three-AP trilateration threshold. If it does not, additional AP deployment or repositioning is required before the presence analytics data will be reliable.
Q2. A hospital A&E department is deploying presence analytics to track patient wait times. After one week of operation, the data shows that average dwell times are 8 minutes — far lower than the known average of 45 minutes — and unique visitor counts are 4x higher than actual patient throughput. What is the most likely cause and how should it be resolved?
Suggerimento: Consider what modern smartphone operating systems do to MAC addresses when devices are not connected to a network.
Visualizza risposta modello
The most likely cause is MAC Randomisation. iOS 14+ and Android 10+ devices rotate their MAC addresses when sending probe requests, causing a single patient's device to appear as multiple distinct devices over the course of their visit. This fragments the 45-minute session into multiple apparent 8-minute sessions, inflating unique visitor counts and deflating dwell times. The recommended resolution is to implement a captive portal for the Healthcare guest WiFi network. Once a patient or visitor authenticates, the analytics platform tracks the persistently associated device MAC address, bypassing OS-level randomisation. For patients who do not connect, enable the platform's session-stitching algorithm, which uses signal pattern continuity and timing heuristics to reconstruct fragmented sessions. This typically resolves 70–80% of fragmentation in environments with high WiFi uptake.
Q3. Durante un aggiornamento programmato della rete, il fornitore dell'infrastruttura propone di sostituire 60 AP omnidirezionali 802.11ax con 40 AP direzionali ad alto guadagno per migliorare la velocità di trasmissione e ridurre l'interferenza co-canale in un grande atrio di uno stadio. Il progetto viene approvato. Qual è l'azione obbligatoria richiesta per proteggere l'attuale implementazione della presence analytics e qual è il rischio se questa azione non viene intrapresa?
Suggerimento: Think about the two key factors that determine presence analytics accuracy: the number of APs and the RF propagation patterns they create.
Visualizza risposta modello
È obbligatorio eseguire un'indagine di heatmapping post-implementazione completa e una ricalibrazione dell'analytics. Il rischio di non intraprendere questa azione è significativo: ridurre il numero totale di AP da 60 a 40 riduce il numero di punti dati simultanei disponibili per la trilaterazione, facendo potenzialmente scendere alcune zone al di sotto della soglia dei tre AP richiesta per dati di localizzazione accurati. Inoltre, la sostituzione delle antenne omnidirezionali con antenne direzionali altera radicalmente i modelli di propagazione RF nell'atrio — le impronte di copertura cambiano forma e dimensione, invalidando tutti i confini di zona precedentemente calibrati nella piattaforma di analytics. Senza ricalibrazione, il motore di presence analytics produrrà dati di localizzazione sistematicamente imprecisi, attribuendo potenzialmente in modo errato le posizioni dei visitatori alle zone adiacenti. L'indagine di heatmapping deve essere completata prima che la piattaforma di analytics venga riattivata dopo l'aggiornamento.
Q4. Un operatore di un hub di trasporto desidera implementare la presence analytics in un aeroporto multi-terminal utilizzando un mix di access point Cisco, Aruba e Ruckus esistenti nei vari terminal. Il team operativo desidera un'unica dashboard unificata che mostri il flusso di passeggeri in tutti i terminal. Quale decisione sull'architettura della piattaforma è più critica per il successo di questa implementazione?
Suggerimento: Considera le implicazioni dell'implementazione di una soluzione di analytics a fornitore unico in un ambiente hardware multi-vendor.
Visualizza risposta modello
La decisione più critica è la scelta di una piattaforma di analytics indipendente dall'hardware (hardware-agnostic) in grado di acquisire dati da tutti e tre i controller dei fornitori simultaneamente tramite le rispettive API (Cisco DNA Spaces, Aruba Central, Ruckus Analytics). L'implementazione di una soluzione di analytics a fornitore unico — ad esempio, gli strumenti di analytics nativi di Cisco — fornirebbe visibilità solo sugli AP gestiti da Cisco, lasciando i terminal Aruba e Ruckus come punti ciechi nella dashboard unificata. Una piattaforma hardware-agnostic normalizza i dati provenienti dai flussi di tutti e tre i fornitori in un unico livello di analytics, consentendo una visibilità del flusso passeggeri davvero unificata in tutti i terminal. Questo salvaguarda anche l'implementazione in vista di futuri cicli di aggiornamento dell'hardware — se un terminal passa a un quarto fornitore, il livello di analytics può continuare a funzionare senza interruzioni. L'architettura della piattaforma di Purple è progettata specificamente per questo modello di implementazione multi-vendor.