HPE Aruba Central Presence Analytics：设置、导出与限制

Aruba Central presence analytics（存在感分析）可统计您的 HPE Aruba 接入点检测到的设备数量。然后，它根据您为每个场所设置的 RSSI 阈值和停留时间边界，将这些设备分类为路人（passers-by）和访客（visitors）。您可以在每个场所启用此功能、在楼层内校准阈值，并可通过 Central REST API 导出汇总数据。它只统计设备数量，绝不会识别个人身份。

Aruba Central presence analytics 到底测量什么？

每部开启了 WiFi 的手机都会发送探测请求（probe requests），即询问附近有哪些可用网络的简短帧。无论手机是否加入您的网络，都会发送这些探测请求。您的 Aruba 接入点会接收这些帧，并将每个设备的 MAC 地址和信号强度报告给 Central。随后，Central 会应用由您控制的两条规则。

第一条规则是信号强度。RSSI（接收信号强度指示）以 dBm 为单位进行测量，数值越接近于零，表示设备距离接入点越近。高于您设定的 RSSI 阈值的设备将被计为场所内设备。低于该阈值的设备则被计为路人。

第二条规则是停留时间。在高于阈值的设备中，Central 使用停留时间边界来区分短暂探测和真实访问。然后，它将访客分为不同的停留时长区间。

其输出结果是每个场所的汇总 Aruba 客流量数据：路人、访客以及停留时间分布。它回答了“这里有多少台设备，停留了多长时间”的问题。但它无法回答“他们是谁”，这个限制决定了本指南后续所有内容的基调。

Purple 自己的 presence 模型也基于相同的物理原理。Presence (Legacy) 文档 描述了如何统计向接入点发送“ping”信号且距离足够近以记录其 MAC 地址的未认证设备。RSSI 用作邻近度信号。时长则测量场所内的任意接入点探测到该设备的时间长度。如果您理解了其中一个模型，也就理解了另一个。

在 Aruba Central 中启用 presence analytics 之前，您需要准备什么？

五样东西，其中最后一样是各团队最容易遗漏的。

1. 支持 presence analytics 的 Central 订阅。 Presence analytics 并不包含在所有的 Central 许可层级中。请根据每个场所 AP 分配的订阅，检查 HPE 当前的许可文档。
2. 将 AP 分配到特定的场所（site），而不仅仅是组（group）。 Central 使用组来进行配置，而使用场所来进行定位和报告。Presence 数据是按场所汇总的，因此没有分配场所的 AP 无法提供任何有用的数据。
3. 标注有物理边界的平面图。 标记出门、店面玻璃、露台、停车场以及与相邻单位共用的墙壁。在这些地方，您的阈值最容易出现偏差。
4. 您可以识别的测试设备。 现代的 iOS 和 Android 版本会随机化设备呈现的 MAC 地址，因此请在您的测试手机上禁用私有地址设置，或者记下它所使用的地址。
5. 隐私立场。 MAC 地址是设备标识符。GDPR 的前言第 30 条将设备提供的在线标识符列为可以识别个人的信息。在开始收集之前，请完成数据保护影响评估，并在入口处张贴标识。英国 ICO 已发布基于设备信号的定位分析指南，该指南涵盖了这两点。

对于 API 工作，您还需要在 Central 中拥有一个可以创建 API Gateway 客户端的管理员角色，以及一个数据接收端：一个数据仓库、数据库或 BI 工具。

如何设置 Aruba Central 存在分析？

第 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 导出存在感测数据

Central 仪表板适合快速浏览，但下游报告需要将数据导出。Aruba Central API 导出遵循四个步骤。

1. 在 API Gateway 中创建 API 客户端。 Central 使用 OAuth 2.0 访问令牌对 REST 调用进行身份验证。访问令牌的有效期较短，因此请将刷新令牌存储在密钥管理器中并自动进行更新。
2. 调用存在分析端点。 它们会返回您指定时间窗口内的方法级别聚合数据。请使用 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 中对随机化行为的每次更改都会影响您的计数并降低重复访问的数据。请在您的报告图表中注明主要的操作系统发布日期。谨慎对待来自未认证设备的重复访问指标。

夜间或清晨的访客

员工手机、手持扫描枪、打印机和智能设备整天都处于阈值之上。在 Central 允许的情况下排除已知的设备地址，或者在您的下游报告中排除营业时间之外的时段。

API 调用返回授权错误

访问令牌已过期，且刷新步骤失败或未运行。请检查您的作业是否使用了刷新令牌，存储了接收到的新令牌对，并在失败时发出警报，而不是静默写入空数据。

历史对比数据突然发生阶梯式变化

有人更改了阈值或停留边界。这就是为什么步骤 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 通过有意识的选择加入增加了身份验证层，为您提供匿名存在感应无法提供的一方数据。

功能	Aruba Central 存在感应分析	您 Aruba AP 上的 Purple WiFi Analytics
计数对象	超过 RSSI 阈值的匿名设备	信号强度显示设备位于场馆内的到访，以及已验证的访客
身份识别	无，仅限 MAC 地址	拥有已同意一方数据的已验证访客
停留时间报告	每个网点的时长区间	已验证访客每次到访的平均停留时间
时间模式	所选窗口内的网点仪表盘	按星期和小时划分的到访热力图
跨场馆视图	按网点，需为多网点场所进行下游构建	平台内排名前 10 和后 10 的场馆到访量排名
硬件支持	仅限 HPE Aruba	Cisco Meraki、HPE Aruba、Ruckus、Juniper Mist、Ubiquiti UniFi、Cambium、Extreme Networks、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 Networks 和 Fortinet。您只需保留您的 Aruba Central 配置和现有的 AP。Purple 会在顶层添加 Captive Portal、已认证访客数据和分析层，因此无需进行硬件更换项目。

我可以将 Aruba Central 存在数据导出到数据仓库或商业智能（BI）工具中吗？

是的，可以通过 Central REST API 导出。在 API 网关中创建一个 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 导出将继续与其并行工作。