HPE Aruba Central 存在感分析：設定、匯出與限制

Aruba Central presence analytics 能夠計算您的 HPE Aruba 無線基地台偵測到的裝置數量。接著，它會根據您為每個場域設定的 RSSI 閾值與停留時間界限，將其分類為路過者與訪客。您可以在每個場域單獨啟用此功能、在現場校準閾值，並透過 Central REST API 匯出彙總數據。它僅計算裝置數量，絕不會識別個人身分。

Aruba Central presence analytics 實際測量什麼？

每支開啟 WiFi 功能的手機都會發送探測請求，這是用來詢問附近有哪些網路的簡短訊框。無論手機最後是否加入您的網路，都會發送這些訊框。您的 Aruba 無線基地台會接收這些訊框，並將每個裝置的 MAC 位址和訊號強度回報給 Central。接著，Central 會套用您所控制的兩項規則。

第一項規則是訊號強度。RSSI（接收訊號強度指標）以 dBm 為單位進行測量，數值越接近零代表裝置距離無線基地台越近。超過您設定之 RSSI 閾值的裝置會被計算為進入場域內；而在該閾值以下的裝置則被視為路過者。

第二項規則是停留時間。在超過閾值的裝置中，Central 使用停留時間界限來區分短暫偵測與真正的造訪。接著，它會將訪客依停留時長進行分組。

輸出結果是每個場域的彙總 Aruba 人流量數據：路過者、訪客以及停留時間分佈。它解答了「這裡有多少台裝置，以及停留了多長時間」。它無法解答「他們是誰」，而這個限制決定了本指南後半部分的所有內容。

Purple 自己的存在感應模型也基於相同的物理原理。Presence (Legacy) 說明文件 描述了如何計算未經身分驗證，但因距離無線基地台足夠近而能記錄其 MAC 位址並發出「ping」訊號的裝置。RSSI 做為鄰近度的訊號。持續時間則測量場域內任何無線基地台偵測到該裝置的時間長度。如果您理解了其中一種模型，就能理解這兩種模型。

在 Aruba Central 中啟用 presence analytics 之前，您需要準備什麼？

五件事，而最後一件事往往是團隊最常忽略的。

1. 包含 presence analytics 的 Central 訂閱。 Presence analytics 並非包含在所有的 Central 授權級別中。請對照每個場域中 AP 所分配的訂閱，確認 HPE 目前的授權文件。
2. 將 AP 分配給場域，而不僅僅是群組。 Central 使用群組進行設定，並使用場域進行定位和報表。Presence 數據是以場域為單位進行彙總，因此未分配場域的 AP 無法提供任何有用的數據。
3. 標有物理邊界的樓層平面圖。 標記出門口、店面玻璃、露台、停車場以及與鄰近單位共用的牆壁。在這些地方，您的閾值最容易出錯。
4. 您可以識別的測試裝置。 現代的 iOS 和 Android 版本會隨機化裝置顯示的 MAC 位址，因此請停用測試手機上的私有位址設定，或記錄其使用的位址。
5. 隱私立場。 MAC 位址是裝置識別碼。GDPR 的前言第 30 條將裝置提供的線上識別碼列為可以識別個人的資訊。在開始收集之前，請完成資料保護影響評估並在入口處張貼告示。英國 ICO 已針對基於裝置訊號的定位分析發布了指南，其中涵蓋了這兩個要點。

對於 API 工作，您還需要在 Central 中擁有一個可以建立 API Gateway 用戶端的管理員角色，以及資料的目的地：資料倉儲、資料庫或 BI 工具。

如何設定 Aruba Central 存在分析（presence analytics）？

步驟 1：為每個站點啟用服務

在 Central 中啟用站點層級的存在分析。確切的功能表路徑在傳統 Aruba Central 與較新的 HPE Aruba Networking Central 介面之間有所不同。請遵循 HPE 針對您版本的最新說明文件，而非參考舊版本的螢幕截圖。在做出任何評估之前，請先讓第一批資料進行填補，並預期首日的數據在校準完成前看起來會有些異常。

步驟 2：校準 RSSI 閾值

Aruba 沒有通用的 RSSI 閾值來計算訪客數量。正確的數值取決於 AP 安裝高度、天線圖案、牆壁材質、玻璃窗以及 AP 距離邊界的遠近。從其他場所複製過來的數值會誤判您場所中的裝置。請改為進行校準：

1. 實地走訪邊界。 攜帶測試裝置前往三個點：剛好在入口內、入口門檻上，以及室外的人行道或廣場上。在每個點停留幾分鐘，並記錄 Central 報告的 RSSI。
2. 在繁忙時段重複此步驟。 人體會吸收無線電能量，因此高峰時段的讀數會低於空無一人建築物中的讀數。請針對高峰期狀況進行校準，因為此時的計數最具關鍵意義。
3. 將閾值設定在「剛好在內」與「室外」之間。 如果街上的行流非常靠近玻璃，請將其偏向室內讀數。如果入口呈凹陷狀且附近沒有人逗留，請將其偏向室外讀數。
4. 記錄數值與日期。 日後的每一次比較，都取決於您是否知道是哪一個閾值產生了哪些數據。

步驟 3：設定區分路人與訪客的停留時間邊界

單憑 RSSI 會誤判走過玻璃窗旁的任何人。設定最低訪客停留時間可以排除他們。請將其設定為您場所中最短的真實造訪時間，而非產業平均值。較長的區間接著就能用來描繪訪客的參與度。

場所類型	路人的特徵	最低訪客停留時間基準	用於驗證的地面真實資料
街邊零售店	步行經過店面的行人	最快的實際購買，例如即買即走的商品	收銀機交易次數
飯店大廳	前往電梯或餐廳的賓客	最短的辦理入住或與櫃檯服務員互動的時間	前台入住記錄
體育場通道	在看台與販賣部之間移動的球迷	最短的販賣部購買時間	販賣部交易次數
圖書館或市政服務點	相鄰街道上的行人	櫃檯最短的諮詢時間	櫃檯諮詢記錄或門口計數器

一次只更改一個設定。如果您同時調整 RSSI 閾值和停留時間界限，您將無法判斷是哪一個變更影響了計數。

步驟 4：透過 Central API 匯出 Presence 數據

Central 儀表板適合快速瀏覽，但下游報告需要將數據匯出。 Aruba Central API 的匯出遵循以下四個步驟。

1. 在 API Gateway 中建立 API 用戶端。 Central 使用 OAuth 2.0 存取權杖進行 REST 呼叫驗證。存取權杖的效期很短，因此請將重新整理權杖儲存在金鑰管理工具中，並設定自動更新。
2. 呼叫 Presence 分析端點。 這些端點會傳回您指定時間範圍內的場域級別彙總數據。請參閱 HPE 的開發人員參考文件以取得目前的端點路徑和參數，因為它們會在不同的 API 版本之間發生變化。
3. 排程提取工作。 每日請求各場域前一天數據的工作非常便於審計。請儲存場域 ID、UTC 時間範圍，以及當時生效的閾值與停留時間設定。
4. 遵守速率限制。 Central 會針對每個帳戶套用 API 速率限制。大型物業應交錯發送場域請求，而不是在同一分鐘內提取所有場域的數據。

步驟 3 比表面上看起來更重要。當有人在六個月後變更閾值時，儲存的設定能讓分析人員拆分數據序列，而不是回報一個虛假的訪客數下滑。

您要如何確認計數是正確的？

與您已經在計算的數據進行驗證。從上表中為每個場域選擇一個真實來源，並在至少一週內每天將其與 Central 的訪客計數進行比較。

您並非在尋找完全相等的數字。有些顧客是一起抵達的，員工會攜帶手機，而有些訪客則根本沒有攜帶任何裝置。您要尋找的是一個穩定的比例。如果訪客數與交易次數保持穩定的倍數關係，則表示設定是健全的，而該比例就會成為您可以陳報的擷取率指標。

在您信任數據之前，請進行以下四項合理性檢查：

• 夜間計數。 在結束營業後記錄到的訪客通常指向員工裝置、固定裝置，或是鄰近高於您閾值的設備。
• 容納人數。 同時在場的訪客數絕不應超過該場地法定容納人數。
• 儀表板對照 API。 從 API 提取的每日總數應與同一場域和時間範圍的 Central 儀表板相符。不一致通常意味著時區錯誤。
• 場域對照場域。 比較營業狀況相似的場域。訪客數兩倍但交易量減半的場域，通常是校準問題，而非銷售問題。

在實際場地中進行調整看起來是怎樣的？

以下兩個案例使用說明性數據來展示方法。您自己的數據會有所不同，但計算方法是相同的。

案例 1：擁有玻璃門面的街邊時尚服飾店

情況。 一間單層店面的繁忙人行道旁，有著整面挑高的玻璃門面，且在距離門面幾公尺內裝有兩個 AP。在一個典型的週六，Central 報告了 3,200 名訪客，而收銀機交易量為 410 筆。大約 13% 的隱含捕獲率與營運團隊的實際經驗相比，顯得低得不合常理。

採取的行動。 網路工程師在週六午餐時間沿著邊界進行測試。他發現玻璃正外面人行道上的設備訊號強度，幾乎與剛進門內的設備一樣強。他將 RSSI 閾值調高到介於這兩個讀數之間。接著，他將最低訪客停留時間設定為在收銀機購買單件商品所需的時間。

結果。 下一個週六，Central 報告了 1,150 名訪客，而交易量為 425 筆，比例約為每筆交易 2.7 名訪客。在接下來的四個週末中，該比例保持在狹窄的區間內。數據分析師現在每週報告此數據，作為該店面 零售 營運檢討的轉換指標。

案例 2：鄰近飯店的會議中心大廳

情況。 一間會議中心與一間擁有 200 間客房的飯店共享一條玻璃連接通道。活動主辦單位希望獲得每日的停留時間數據，以便為大廳的贊助商攤位定價。不論活動是否正在進行，Central 的停留時間分佈在最短區間內都顯示出巨大的尖峰。

採取的行動。 工程師發現，走在連接通道上的飯店房客，其訊號高於大廳 AP 的 RSSI 閾值。如果僅調整閾值，會將站在通道附近的真正與會代表排除在外。因此，團隊將最低訪客停留時間提高到超過走完通道全程所需的時間。然後，他們在三個活動日中，對照識別證掃描數據驗證了計數。

結果。 在非活動日，大廳訪客量下降到與員工和承包商一致的水平。在活動日，訪客計數與識別證掃描以穩定的比例保持一致。主辦單位隨後可以向贊助商提供一個具說服力的數據，即在大廳停留超過設定時間的代表大約人數。飯店的 旅客 流量不再干擾活動數據。

案例 3：外有公車站的議會圖書館

情況。 一間公共圖書館旁設有公車站，人們會在那裡等候數分鐘，這完全在入口 AP 的覆蓋範圍內。議會需要年度服務報告的造訪人數。

採取的行動。 單憑 RSSI 或停留時間都無法區分等公車的乘客與圖書館的訪客。團隊利用在公車站本身測得的讀數來設定閾值。接著，他們將計數與現有的門口計數器進行了為期一個月的交叉比對。

成果。 數據顯示，人流偵測數量與門口計數器的數據保持一致的同步變動。議會決定保留門口計數器作為官方數據，並使用人流偵測數據來分析門口計數器無法提供的逐時趨勢。此趨勢分析為服務台的排班調整提供了決策依據。

常見問題及解決方法

訪客計數遠高於實際情況

RSSI 閾值設定過於寬鬆，通常是因為玻璃、薄隔間或 AP 安裝在入口附近所致。請在尖峰時段重新測試邊界並提高閾值。如果 AP 的部署位置無法實現清晰的區域隔離，請考慮將其移至遠離邊界的地方。

行動作業系統更新後計數發生變化

MAC 地址隨機化意味著一個實體裝置隨著時間推移可能會顯示為多個地址。iOS 或 Android 隨機化機制的每次變更都可能影響您的計數並降低重複訪客的數據。請在您的報表時間軸上標記重大作業系統版本的發佈日期。請謹慎對待來自未驗證裝置的重複訪問指標。

夜間或清晨的訪客數據

員工的手機、手持式掃描器、印表機和智慧型裝置整天都高於閾值。在 Aruba Central 允許的情況下排除已知的裝置地址，或者在您的下游報表中排除非營業時間。

API 呼叫傳回授權錯誤

存取權杖（Access Token）已過期，且重新整理（Refresh）步驟失敗或未執行。請檢查您的排程任務是否使用了重新整理權杖（Refresh Token）、是否儲存了接收到的新權杖對，並在失敗時發出警報，而不是靜默地寫入空白數據。

歷史對比數據突然出現階梯式變化

有人更改了閾值或停留時間邊界。這就是為什麼步驟 4 會在每次提取時儲存設定的原因。請以變更日期為界拆分數據序列，並分別陳述這兩個時期的報告。

Captive Portal 問題導致驗證指標失真

如果您同時運行 Captive Portal（即裝置在獲取網路存取權限之前看到的網頁），重導向失敗會減少已驗證的造訪次數。這不會影響人流偵測計數。請將 Portal 重導向問題作為與人流偵測校準無關的獨立事件進行調查。

Aruba Central 分析有哪些限制？

原生的人流偵測分析功能非常實用，並且隨附於您的 Aruba 設備中。但它也有其局限性，在利害關係人基於此建立報表專案之前，您應向其清楚說明。

• 場域層級聚合。 Central 按場域進行報告。如果您需要對同一個場域內的不同區域進行比較，或在採用一致規則的大型資產中進行排名，您需要自己在下游系統中進行建置。
• 保留期限。 Central 依據平台和您的訂閱方案設定，僅將人流偵測數據保留有限的時間。年度同比比較取決於您自己的匯出，因此請在第一天就啟用 API 管線。
• 無識別層。 存在數據僅是匿名的裝置數量。您無法將造訪與已同意的聯絡人、會員帳戶或 CRM 記錄連結。隨機化的 MAC 位址甚至會使匿名的重複造訪統計在長期下變得不可靠。
• 單一廠商視角。 Central 僅能看見 Aruba 基地台。在已收購的站點中混合使用 Aruba 與 Cisco Meraki、Ruckus 或 Juniper Mist 的物業，只能獲得部分的全貌。
• 校準債務。 每次重新裝修、AP 移動或安裝新玻璃都會改變無線電環境。除非有人重新進行邊界走測，否則在安裝時正確的閾值會產生偏差。

這些都不是缺陷。它們只是網路廠商分析功能的作用範圍，也定義了平台層發揮價值的空間。

這需要多少成本，以及在其上建置平台層何時能回收效益？

如果您的 Central 訂閱已包含存在分析，原生途徑耗費的是工程和分析人員的時間，而非額外的授權支出。預算需規劃每個站點的邊界走測、一週的驗證時間、API 管道的建立與維護，以及物理環境改變後的重新校準。

Purple 的 WiFi Analytics 則是增加了一個不同的層級，而非複製 Central。它作為與硬體無關的雲端疊加層運行在您已擁有的 Aruba 基地台之上，無需拆除並更換設備。Purple 的 Guest WiFi Captive Portal 透過有意識的選擇加入（Opt-in）增加了一個已驗證的層級，為您提供匿名存在分析無法提供的第一方數據。

功能	Aruba Central 存在分析	運行在 Aruba AP 上的 Purple WiFi Analytics
計算內容	超過 RSSI 閾值的匿名裝置	訊號強度判定裝置位於場域內的造訪，以及已驗證的訪客
識別度	無，僅有 MAC 位址	擁有已同意第一方數據的已驗證訪客
停留報告	每個站點的持續時間區段	已驗證訪客每次造訪的平均停留時間
時間模式	所選視窗內的站點儀表板	按星期幾和一天中小時劃分的造訪熱圖
跨場域視角	每個站點單獨顯示，物業需在下游自行整合	平台內直接排名造訪量前 10 名與後 10 名的場域
硬體支援	僅限 HPE Aruba	Cisco Meraki、HPE Aruba、Ruckus、Juniper Mist、Ubiquiti UniFi、Cambium、Extreme、Fortinet
即時視角	Central 儀表板	過去 25 分鐘內以一分鐘為間隔的數據，每分鐘更新一次 (Presence Legacy)
適合對象	需要匿名佔用模式的單一廠商物業	需要已識別、已同意訪客數據的多場域或混合廠商物業

此表格中的 Purple 功能源自 Purple 的 WiFi Analytics - Presence 和 Presence (Legacy) 說明文件。這些文件中提到一個注意事項：未經驗證訪客的數據處理時間，可能會比已驗證訪客的數據處理時間更長。

如果您經營單一的 Aruba 園區，需要匿名的佔用率和停留模式，且有工程師可以負責校準和 API 管道，那麼保留使用原生系統即可。

當符合以下任一情況時，請新增平台層：您營運混合硬體；您需要對許多場域進行相互評比；或者您需要已同意、已識別的訪客數據用於行銷或服務設計。這適用於建立房客設定檔的 飯店，以及將造訪與行銷活動連結起來的連鎖零售店。Purple 在全球 80,000 多個實體場域運作，並在 2024 年處理了 4.4 億次登入（此為 Purple 的自有數據）。這些場域中的大多數都直接使用原本已安裝的硬體。

常見問題

Aruba Central 授權中是否包含客流分析 (presence analytics)？

並非所有情況都包含。客流分析屬於特定的 Aruba Central 訂閱層級，因此請確認各個場地的 AP 是否具備包含該功能的訂閱層級。在規劃部署之前，請對照您 Central 帳戶中分配的訂閱，仔細檢查 HPE 目前的授權文件。如果某些場地使用較低級別的訂閱，將會導致全園區報告出現缺口。請先解決授權問題，然後再進行校準。

Purple 是否可以與我現有的 HPE Aruba 基地台配合使用？

是的。Purple 與硬體無關，可作為雲端重疊層運行在 HPE Aruba 基地台上，並與 Cisco Meraki、Ruckus、Juniper Mist、Ubiquiti UniFi、Cambium、Extreme 和 Fortinet 併行。您將保留您的 Aruba Central 設定和現有的 AP。Purple 則在上方添加 Captive Portal、已驗證訪客數據和分析層，因此無需進行硬體更換專案。

我可以將 Aruba Central 的客流數據匯出到資料倉儲或 BI 工具中嗎？

可以，透過 Central REST API 即可實現。在 API Gateway 中建立 API 用戶端，使用 OAuth 2.0 權杖進行驗證，然後呼叫客流分析端點以取得場地層級的彙總數據。建議排程每天為每個場地擷取一次、將時間戳記儲存為 UTC，並記錄當時生效的閾值設定。由於 Central 的保留期限有限，您的匯出檔將成為年度比較之長期記錄。

根據 GDPR，WiFi 客流數據是否屬於個人資料？

請將其視為個人資料。GDPR 的前言第 30 條將裝置提供的線上識別碼列為可以識別個人的資訊，而客流分析會處理 MAC 位址。請完成資料保護影響評估、在入口處設立清晰的告示，並保持適當的資料保留期限。彙總後的計數風險低於原始識別碼，但收集步驟仍屬於規範範圍之內。

設定與校準 Aruba 存在分析（presence analytics）需要多長時間？

預計每個場地需進行一次邊界實測，並進行至少一週的驗證。啟用此服務僅需數分鐘。校準過程包括在尖峰時段實際走過入口處、設定 RSSI 閾值與停留邊界，然後將計數結果與收銀機、報到記錄或門口計數器進行比對。API 管道則是一項獨立的工程工作。若發生任何裝修、AP 移位或玻璃變更，請務必重新校準。

MAC 位址隨機化會使 Aruba 存在計數失效嗎？

不會，但這會限制計數所代表的意義。當與收銀機交易等真實數據源進行驗證後，總訪客數和停留模式仍具備參考價值。然而，來自未驗證裝置的重複造訪和忠誠度數據將不再可靠，因為同一支手機在不同時間可能會顯示多個位址。若要取得可靠的重複造訪數據，您需要透過經同意並透過 captive portal 登入的已驗證訪客。

我該選擇 Aruba Central 存在分析還是 Purple WiFi Analytics？

大多數 Aruba 客戶兩者都會運作，因為它們能解答不同的問題。如果您的授權方案有包含，Central 無需額外費用即可提供每個場地的匿名佔用率與停留模式。Purple 則增加了經授權同意的訪客數據、跨場地排名，並支援混合硬體。若是在單一廠商的環境中進行匿名計數，請保留原生系統；當您需要識別的第一方數據時，請加入 Purple。

我需要新硬體來增加已識別的分析層嗎？

不需要。Purple 可直接架設在您現有的 HPE Aruba 基地台之上，因此無需拆除與汰換。已識別的分析層是來自具有自願勾選同意機制的 captive portal，而非來自新的無線電裝置。您現有的 Central 設定、存在分析與 API 匯出功能仍可並行運作。