HPE Aruba Central presence analytics: setup, exports and limits

Aruba Central presence analytics counts the devices your HPE Aruba access points hear. It then sorts them into passers-by and visitors using an RSSI threshold and dwell-time boundaries you set for each site. You enable it per site, calibrate the threshold on the floor, and export aggregates through the Central REST API. It counts devices and never identifies people.

What does Aruba Central presence analytics actually measure?

Every phone with WiFi switched on sends probe requests, which are short frames asking which networks are nearby. It sends them whether or not it ever joins your network. Your Aruba access points hear those frames and report each device's MAC address and signal strength to Central. Central then applies two rules that you control.

The first rule is signal strength. RSSI (received signal strength indicator) is measured in dBm, and values closer to zero mean the device is nearer the access point. A device above your RSSI threshold counts as inside the venue. A device heard below it counts as a passer-by.

The second rule is dwell time. Among devices above the threshold, Central uses dwell-time boundaries to separate brief detections from genuine visits. It then groups visitors into duration bands.

The output is aggregate Aruba footfall data for each site: passers-by, visitors and the dwell distribution. It answers "how many devices were here, and for how long". It cannot answer "who were they", and that limit shapes everything at the end of this guide.

Purple's own presence model works on the same physics. The Presence (Legacy) documentation describes counting unauthenticated devices that "ping" an access point closely enough for their MAC address to be recorded. RSSI serves as the proximity signal. Duration measures how long any access point in the venue saw the device. If you understand one model, you understand both.

What do you need before you enable presence analytics in Aruba Central?

Five things, and the last one is the one teams skip.

1. A Central subscription that covers presence analytics. Presence analytics is not part of every Central licence tier. Check HPE's current licensing documentation against the subscription assigned to the APs at each site.
2. APs assigned to a site, not just a group. Central uses groups for configuration and sites for location and reporting. Presence aggregates per site, so an AP with no site assignment contributes nothing useful.
3. A floor plan with the physical boundary marked. Mark doors, shopfront glass, terraces, car parks and walls shared with neighbouring units. These are the places where your threshold will be wrong first.
4. A test device you can identify. Modern iOS and Android releases randomise the MAC address a device presents, so either disable the private address setting on your test handset or note the address it uses.
5. A privacy position. MAC addresses are device identifiers. Recital 30 of the GDPR names device-provided online identifiers as information that can identify a person. Complete a data protection impact assessment and put signage at entrances before collection starts. The UK ICO has published guidance on location analytics based on device signals, and it covers both points.

For the API work, you also need an admin role in Central that can create API Gateway clients, and a destination for the data: a warehouse, a database or a BI tool.

How do you set up Aruba Central presence analytics?

Step 1: enable the service for each site

Turn on presence analytics at site level in Central. The exact menu path differs between classic Aruba Central and the newer HPE Aruba Networking Central interface. Follow HPE's current documentation for your release rather than a screenshot from an older one. Allow the first data to populate before you judge anything, and expect the opening day's numbers to look wrong until you calibrate.

Step 2: calibrate the RSSI threshold

There is no universal Aruba RSSI threshold for visitor counting. The right value depends on AP mounting height, antenna pattern, wall material, glazing and how close the APs sit to the boundary. A number copied from another venue will misclassify devices at yours. Calibrate it instead:

1. Walk the boundary. Carry the test device to three points: just inside the entrance, on the threshold itself, and on the pavement or concourse outside. Hold each point for a few minutes and note the RSSI Central reports.
2. Repeat at a busy hour. People absorb radio energy, so readings at peak time sit lower than readings in an empty building. Calibrate against peak conditions, because that is when the counts matter.
3. Place the threshold between "just inside" and "outside". Bias it towards the inside reading if street traffic passes close to the glass. Bias it towards the outside reading if the entrance is recessed and nobody lingers nearby.
4. Record the value and the date. Every later comparison depends on knowing which threshold produced which numbers.

Step 3: set the dwell boundaries that separate passers-by from visitors

RSSI alone misclassifies anyone who walks past close to the glass. The minimum visitor dwell removes them. Set it to the shortest genuine visit at your venue, not to an industry average. The longer bands then describe how engaged your visitors are.

Venue type	What a passer-by looks like	Anchor for minimum visitor dwell	Ground truth to validate against
High street retail	Pedestrian walking past the shopfront	Fastest real purchase, such as a grab-and-go item	Till transaction count
Hotel lobby	Guest crossing to the lifts or the restaurant	Shortest check-in or concierge interaction	Front desk check-in log
Conference centre foyer	Delegate passing between halls	Shortest session attendance	Badge scans per session
Stadium concourse	Fan moving between stand and kiosk	Shortest kiosk purchase	Kiosk transaction count
Library or council service point	Pedestrian on the adjacent street	Shortest enquiry at the desk	Desk enquiry log or door counter

Change one setting at a time. If you move the RSSI threshold and the dwell boundary together, you cannot tell which change moved the count.

Step 4: export presence data through the Central API

Central dashboards are fine for a glance, but downstream reporting needs the data out. An Aruba Central API export follows four steps.

1. Create an API client in API Gateway. Central authenticates REST calls with OAuth 2.0 access tokens. Access tokens are short-lived, so store the refresh token in a secrets manager and automate renewal.
2. Call the presence analytics endpoints. They return site-level aggregates for a time window you specify. Use HPE's developer reference for the current endpoint paths and parameters, because they change between API versions.
3. Schedule the pull. A daily job that requests the previous day per site is easy to audit. Store the site ID, the time window in UTC, and the threshold and dwell settings in force at the time.
4. Respect rate limits. Central applies API rate limits per account. Large estates should stagger site requests rather than pulling every site in the same minute.

Step 3 matters more than it looks. When someone changes a threshold six months from now, the stored settings let analysts split the series instead of reporting a phantom drop in visitors.

How do you check the counts are right?

Validate against something you already count. Pick one ground-truth source per site from the table above and compare it with Central's visitor count every day for at least a week.

You are not looking for equal numbers. Several shoppers arrive together, staff carry phones and some visitors carry no device at all. You are looking for a stable ratio. If visitors run at a consistent multiple of transactions, the configuration is sound and the ratio becomes a capture-rate metric you can report.

Run four sanity checks before you trust the data:

• Overnight counts. Visitors recorded after closing usually point to staff devices, fixed devices or a neighbour's equipment above your threshold.
• Capacity. Visitors present at once should never exceed the venue's licensed occupancy.
• Dashboard against API. Daily totals from your API pull should match the Central dashboard for the same site and window. A mismatch usually means a time zone error.
• Site against site. Compare sites with similar trade. A site with twice the visitors and half the transactions has a calibration problem, not a sales problem.

What does tuning look like in a real venue?

The two scenarios below use illustrative figures to show the method. Your own numbers will differ, but the arithmetic is the same.

Scenario 1: a high street fashion store with a glass frontage

Situation. A single-floor shop has two APs within a few metres of a full-height glass frontage on a busy pavement. On a typical Saturday, Central reports 3,200 visitors against 410 till transactions. The implied capture rate of about 13% looks implausibly weak against the trading team's experience.

What was done. The network engineer walked the boundary at Saturday lunchtime. He found that devices on the pavement directly outside the glass read almost as strongly as devices just inside the door. He raised the RSSI threshold to sit between those two readings. He then set the minimum visitor dwell to the time it takes to buy a single item at the till.

Outcome. The following Saturday, Central reported 1,150 visitors against 425 transactions, a ratio of roughly 2.7 visitors per sale. That ratio held within a narrow band over the next four weekends. The insights analyst now reports it weekly as a conversion indicator for the store's retail trading review.

Scenario 2: a conference centre foyer with an adjacent hotel

Situation. A conference centre shares a glazed link corridor with a 200-room hotel. Event organisers want dwell data per day to price sponsor stands in the foyer. Central's dwell distribution shows a large spike in the shortest band, regardless of whether an event is running.

What was done. The engineer found that hotel guests walking the link corridor fell above the RSSI threshold for the foyer APs. Moving the threshold alone would have cut genuine delegates standing near the corridor. Instead, the team raised the minimum visitor dwell above the time it takes to walk the corridor end to end. They then validated the counts against badge scans on three event days.

Outcome. On non-event days, foyer visitors fell to a level consistent with staff and contractors. On event days, visitor counts tracked badge scans at a steady ratio. The organisers could then quote sponsors a defensible figure for delegates who spent more than a set time in the foyer. The hotel's guest traffic stopped polluting the event data.

Scenario 3: a council library with a bus stop outside

Situation. A public library sits beside a bus stop where people wait for several minutes, well within range of the entrance AP. The council wants visit numbers for its annual service report.

What was done. Neither RSSI nor dwell alone separated a waiting bus passenger from a library visitor. The team placed the threshold using readings taken at the bus stop itself. They then cross-checked the counts against the existing door counter for a month.

Outcome. Presence counts and door counts moved together within a consistent margin. The council kept the door counter as the official figure and used presence data for the hour-by-hour pattern, which the door counter could not provide. The pattern informed changes to staffing at the enquiry desk.

What goes wrong, and how do you fix it?

Visitor counts are far higher than any ground truth

The RSSI threshold is too permissive, usually because of glass, a thin partition or an AP mounted near the entrance. Re-walk the boundary at peak time and raise the threshold. If the AP placement makes clean separation impossible, consider moving it further from the boundary.

Counts shift after a mobile OS update

MAC address randomisation means one physical device can appear as several addresses over time. Each change to randomisation behaviour in iOS or Android can move your counts and depress repeat-visit figures. Annotate your reporting series with major OS release dates. Treat repeat-visit metrics from unauthenticated devices with caution.

Overnight or early-morning visitors

Staff phones, handheld scanners, printers and smart devices sit above the threshold all day. Exclude known device addresses where Central allows it, or exclude the hours outside trading in your downstream reporting.

API calls return authorisation errors

The access token has expired and the refresh step failed or never ran. Check that your job uses the refresh token, stores the new token pair it receives, and alerts on failure rather than silently writing empty days.

A sudden step change in historical comparisons

Someone changed a threshold or dwell boundary. This is why Step 4 stores the settings with every pull. Split the series at the change date and report the two periods separately.

Captive portal problems distort authenticated metrics

If you also run a captive portal, which is the web page a device sees before it gets network access, redirect failures reduce authenticated visits. They do not affect presence counts. Investigate portal redirects as a separate issue from presence calibration.

What are the limits of Aruba Central analytics?

Native presence analytics is useful and comes with your Aruba estate. It also has hard edges that you should state plainly to stakeholders before they build a reporting programme on it.

• Site-level aggregation. Central reports per site. If you need comparisons across zones within a site, or rankings across a large estate with consistent rules, you will build that downstream yourself.
• Retention. Central keeps presence data for a limited period set by the platform and your subscription. Year-on-year comparison depends on your own export, so start the API pipeline on day one.
• No identified layer. Presence data is anonymous device counts. You cannot connect a visit to a consented contact, a loyalty account or a CRM record. Randomised MAC addresses make even anonymous repeat-visit counts unreliable over long periods.
• Single-vendor view. Central sees Aruba access points. Estates that mix Aruba with Cisco Meraki, Ruckus or Juniper Mist at acquired sites get a partial picture.
• Calibration debt. Every refit, AP move or new glazing changes the radio environment. Thresholds that were correct at installation drift unless someone re-walks the boundary.

None of these is a defect. They are the scope of a network vendor's analytics feature, and they define where a platform layer earns its place.

What does it cost, and when does a platform layer on top earn it?

The native route costs engineering and analyst time rather than extra licence spend, provided your Central subscription already covers presence analytics. Budget for a boundary walk per site, a week of validation, an API pipeline to build and maintain, and recalibration after physical changes.

Purple's WiFi Analytics adds a different layer rather than duplicating Central. It runs as a hardware-agnostic cloud overlay on the Aruba access points you already own, with no rip and replace. Purple's Guest WiFi captive portal adds an authenticated layer through conscious-choice opt-ins, which gives you first-party data that anonymous presence cannot.

Capability	Aruba Central presence analytics	Purple WiFi Analytics on your Aruba APs
What it counts	Anonymous devices above an RSSI threshold	Visits where signal strength placed the device inside the venue, plus authenticated visitors
Identity	None, MAC address only	Authenticated visitors with consented first-party data
Dwell reporting	Duration bands per site	Average dwell per visit for authenticated visitors
Time patterns	Site dashboards over a chosen window	Heatmap of visits by day of week and hour of day
Cross-venue view	Per-site, built downstream for estates	Top 10 and bottom 10 venues by visits, ranked in-platform
Hardware	HPE Aruba only	Cisco Meraki, HPE Aruba, Ruckus, Juniper Mist, Ubiquiti UniFi, Cambium, Extreme, Fortinet
Real-time view	Central dashboards	Last 25 minutes in one-minute intervals, refreshed every minute (Presence Legacy)
Who it suits	Single-vendor estates needing anonymous occupancy patterns	Multi-venue or mixed-vendor estates that need identified, consented visitor data

The Purple capabilities in this table come from Purple's WiFi Analytics - Presence and Presence (Legacy) documentation. One caveat from those documents: data for unauthenticated visitors can take longer to process than data for authenticated visitors.

Stay native if you run a single Aruba estate, need anonymous occupancy and dwell patterns, and have an engineer who can own calibration and the API pipeline.

Add a platform layer when any of these hold: you operate mixed hardware; you rank many venues against each other; or you need consented, identified visitor data for marketing or service design. That applies to hotels building guest profiles and to retail chains linking visits to campaigns. Purple runs at 80,000+ live venues and handled 440 million logins in 2024 (Purple's own data). Most of those venues sit on hardware that was already installed.

Frequently asked questions

Is presence analytics included in my Aruba Central licence?

Not in every case. Presence analytics sits in specific Aruba Central subscription tiers, so confirm that the APs at each site carry a tier that includes it. Check HPE's current licensing documentation against the subscriptions assigned in your Central account before you plan a rollout. If some sites carry a lower tier, you will get gaps in estate-wide reporting. Fix the licensing first, then calibrate.

Does Purple work with my existing HPE Aruba access points?

Yes. Purple is hardware-agnostic and runs as a cloud overlay on HPE Aruba access points, alongside Cisco Meraki, Ruckus, Juniper Mist, Ubiquiti UniFi, Cambium, Extreme and Fortinet. You keep your Aruba Central configuration and your existing APs. Purple adds the captive portal, authenticated visitor data and analytics layer on top, so there is no hardware replacement project.

Can I export Aruba Central presence data into a data warehouse or BI tool?

Yes, through the Central REST API. Create an API client in API Gateway, authenticate with OAuth 2.0 tokens, and call the presence analytics endpoints for site-level aggregates. Schedule a daily pull per site, store timestamps in UTC, and record the threshold settings in force. Because Central retention is limited, your export becomes the long-term record for year-on-year comparison.

Is WiFi presence data personal data under GDPR?

Treat it as personal data. Recital 30 of the GDPR names device-provided online identifiers as information that can identify a person, and presence analytics processes MAC addresses. Complete a data protection impact assessment, put clear signage at entrances, and keep retention proportionate. Aggregated counts carry lower risk than raw identifiers, but the collection step still falls within scope.

How long does it take to set up and calibrate Aruba presence analytics?

Plan for one boundary walk per site and at least a week of validation. Enabling the service takes minutes. Calibration means walking the entrance at peak time, setting the RSSI threshold and dwell boundaries, then comparing counts with tills, check-ins or door counters. The API pipeline is a separate piece of engineering work. Recalibrate after any refit, AP move or glazing change.

Will MAC address randomisation make Aruba presence counts useless?

No, but it limits what the counts mean. Total visitors and dwell patterns remain usable when validated against a ground-truth source such as till transactions. Repeat-visit and loyalty figures from unauthenticated devices are unreliable, because one phone can present several addresses over time. For dependable repeat-visit data, you need authenticated visitors who sign in through a captive portal with consent.

Should I choose Aruba Central presence analytics or Purple WiFi Analytics?

Most Aruba estates run both, because they answer different questions. Central gives anonymous occupancy and dwell patterns per site at no extra licence cost if your tier includes it. Purple adds authenticated, consented visitor data, cross-venue rankings and support for mixed hardware. Stay native for anonymous counts on a single-vendor estate. Add Purple when you need identified first-party data.

Do I need new hardware to add an identified analytics layer?

No. Purple layers on top of the HPE Aruba access points you already run, so there is no rip and replace. The identified layer comes from a captive portal with conscious-choice opt-ins, not from new radios. Your existing Central configuration, presence analytics and API exports continue to work alongside it.