RADIUS Analytics Deep Dive
Key Takeaways: RADIUS (Remote Authentication Dial-In User Service) analytics is the data pipeline behind every WiFi intelligence metric, from dwell time to zone heatmaps. Eight key fields in the
radaccttable power all WiFi business intelligence. MyWiFi Networks processes RADIUS accounting data from 20+ hardware vendors automatically, correlating session data with captive portal profiles to overcome MAC address randomization.
Every metric on a WiFi analytics dashboard (capture rate, dwell time, return rate, zone heatmaps, peak occupancy) originates from the same source: RADIUS session accounting data.
If you're a reseller pitching WiFi analytics to clients, understanding what RADIUS actually captures and how it becomes business intelligence separates you from competitors who can only say "you get a dashboard." When a client asks "how do you know people spend 47 minutes on average?" you should be able to explain the data pipeline, not just point at a chart.
What is RADIUS and how does it work?
RADIUS stands for Remote Authentication Dial-In User Service. Despite the dated name (it was designed in 1991 for modem dial-up), it remains the standard protocol for managing network authentication and accounting across virtually all enterprise WiFi hardware.
When a guest connects to a WiFi network, the access point sends a RADIUS request to an authentication server. The server validates the guest (via captive portal, WPA2-Enterprise, or any other method) and tells the AP to grant or deny access. That is the authentication side.
The accounting side is where the analytics value lives. Throughout the guest's session, the AP sends structured accounting records to the RADIUS server. These records, stored in a table commonly called radacct, contain precise, timestamped data about every WiFi session on the network.
What data fields does RADIUS capture for WiFi analytics?
A RADIUS accounting record contains dozens of attributes. For WiFi analytics, eight fields carry most of the intelligence value:
+-------------------------+-------------------+------------------------------------+
| Field | Example Value | What It Tells You |
+-------------------------+-------------------+------------------------------------+
| Acct-Session-Id | 8A3F9C02-001 | Unique session identifier |
| Acct-Session-Time | 2820 | Session duration in seconds (47m) |
| Acct-Input-Octets | 524288000 | Download bytes (~500 MB) |
| Acct-Output-Octets | 104857600 | Upload bytes (~100 MB) |
| Called-Station-Id | AA:BB:CC:DD:EE:FF | AP MAC — identifies the zone/AP |
| Calling-Station-Id | 11:22:33:44:55:66 | Device MAC — identifies the guest |
| NAS-IP-Address | 10.0.1.1 | Network Access Server (AP/gateway) |
| Acct-Status-Type | Stop | Start / Interim-Update / Stop |
+-------------------------+-------------------+------------------------------------+
Here is what a complete radacct record looks like in practice:
INSERT INTO radacct (
acctsessionid, acctstarttime, acctstoptime,
acctstatustype, acctinputoctets, acctoutputoctets,
acctsessiontime, calledstationid, callingstationid,
nasipaddress, username
) VALUES (
'8A3F9C02-001', '2026-03-21 09:14:22', '2026-03-21 09:55:42',
'Stop', 524288000, 104857600,
2820, 'AA:BB:CC:DD:EE:FF', '11:22:33:44:55:66',
'10.0.1.1', 'guest-7842@portal'
);
That single record tells you: a guest device (11:22:33:44:55:66) connected at 9:14 AM, stayed for 47 minutes, consumed 500 MB of data, and was served by the access point with MAC AA:BB:CC:DD:EE:FF on the network at 10.0.1.1. When the session ended, the AP sent the Stop record.
How does MyWiFi Networks translate RADIUS into business intelligence?
Raw radacct data is not useful to a venue manager. MyWiFi's analytics engine processes these records and surfaces them as metrics your clients actually understand.
Session duration equals dwell time
Acct-Session-Time directly maps to dwell time. Aggregate across all sessions for a given day and you have average dwell time. Filter by Called-Station-Id (which AP the guest was on) and you have dwell time per zone: lobby vs. dining room vs. outdoor patio.
A restaurant client does not need to know about Acct-Session-Time. They need to know that lunch guests spend an average of 38 minutes and dinner guests spend 72 minutes. The RADIUS data makes that calculation possible.
Device identity equals guest tracking
Calling-Station-Id is the guest device's MAC address. This is the persistent identifier that enables return-visit tracking. When the same MAC appears in radacct records across multiple days, you know that guest came back.
From this single field, the system derives return rate (percentage of devices seen more than once in a 30-day window), visit frequency (average sessions per device per month), loyal vs. lapsed classification (devices with 4+ sessions/month vs. devices not seen in 30+ days), and new vs. returning ratio (first-time MACs vs. previously seen MACs, per day).
MAC randomization on modern devices (iOS 14+, Android 10+) does affect accuracy. However, once a guest authenticates through the captive portal by providing an email, phone number, or social login, MyWiFi ties that session to a persistent profile that survives MAC rotation.
AP identity equals zone mapping
Called-Station-Id and NAS-IP-Address identify which access point served the session. In a multi-AP deployment, this maps directly to physical zones within the venue.
A hotel with APs in the lobby, restaurant, pool area, and conference rooms can see guest flow between zones. A shopping mall reseller can show foot traffic per wing. An airport deployment reveals terminal-level dwell patterns.
Zone-level analytics is one of the highest-value features you can sell. For how this translates into real-time operational decisions, see our guide on real-time venue analytics. It answers questions like "which area of my venue gets the most traffic?" and "where do people spend the most time?" Questions that traditionally required expensive dedicated sensors.
Bandwidth usage as engagement proxy
Acct-Input-Octets and Acct-Output-Octets measure data consumption per session. A guest who downloads 2 GB during a 45-minute visit is streaming video or working. A guest who uses 5 MB in 10 minutes checked their email and left.
Bandwidth data, combined with dwell time, creates a composite engagement score. High dwell + high bandwidth = deeply engaged. High dwell + low bandwidth = waiting (possibly in a queue). Low dwell + high bandwidth = grabbed content and left.
Building presence analytics from RADIUS
The real value comes from aggregating RADIUS data across time. Individual sessions become patterns. Patterns become predictions.
Count unique Calling-Station-Id values per hour across a week and you have hourly occupancy curves showing peak and off-peak hours. A restaurant client can staff based on WiFi-derived occupancy data instead of guesswork.
Aggregate session counts by weekday for day-of-week analysis. This data feeds directly into AI-powered guest segmentation for targeted campaign delivery. Tuesday might consistently show 40% less traffic than Saturday. A "Tuesday special" campaign targeted at regular-segment guests can flatten the curve.
The delta between Acct-Start-Time and Acct-Stop-Time across all sessions reveals when guests typically arrive and leave. For venues with capacity constraints, this enables queue management and reservation optimization.
Stack monthly aggregates across quarters for seasonal trends. A retail client sees holiday traffic spikes quantified. A university deployment shows semester-vs-break patterns. A beach resort reseller proves summer occupancy to justify seasonal pricing.
Hardware requirements
RADIUS analytics work with any hardware that supports RADIUS accounting, which is effectively every enterprise and prosumer AP on the market. MyWiFi integrates with 20+ hardware vendors.
Ubiquiti UniFi has native RADIUS accounting via controller. Cisco Meraki uses cloud-managed RADIUS via dashboard. Ruckus SmartZone and Unleashed both support RADIUS accounting. Cambium cnMaestro is supported through MyWiFi's white-label cnMaestro integration. Aruba Instant On and Central both support external RADIUS. TP-Link Omada provides RADIUS accounting via Omada controller. MikroTik, Teltonika, Draytek, EnGenius, and others are also supported.
The access point handles all RADIUS communication natively. There is no additional hardware, no sidecar appliance, no packet capture device. The AP sends accounting data to MyWiFi's RADIUS server, and the analytics pipeline takes it from there.
Why resellers should understand this
You do not need to explain radacct fields to your clients. They want dashboards, not database schemas. But understanding the data pipeline gives you three advantages.
First, credibility in technical conversations. When an MSP's network engineer asks "how does your analytics work?" you can explain the RADIUS accounting pipeline. That conversation builds trust faster than any slide deck.
Second, accurate scoping. You know that zone-level analytics requires multiple APs with distinct Called-Station-Id values. A single-AP deployment gives you dwell time and return rates but not zone mapping. Setting correct expectations prevents client disappointment.
Third, troubleshooting ability. When a client reports that analytics look wrong, that dwell times seem too short or return rates seem too low, you can reason about the data layer. Is MAC randomization inflating unique device counts? Are interim-update records not being sent? Is one AP misconfigured for RADIUS accounting? Understanding the pipeline means you can diagnose issues instead of filing support tickets.
From raw protocol to clean dashboard
MyWiFi processes all RADIUS accounting data automatically. Resellers and their clients never see raw radacct records. The platform ingests session data, correlates it with captive portal profiles, applies MAC de-duplication logic, and surfaces clean metrics in real-time dashboards.
What your clients see: a chart showing 847 unique visitors this week, average dwell time of 42 minutes, 34% return rate, and a heatmap of traffic across their venue zones.
What powers that chart: thousands of RADIUS accounting records, each containing the eight fields described above, processed through an analytics pipeline that turns protocol-level data into business decisions.
That is the RADIUS analytics WiFi infrastructure you are reselling. Knowing how it works makes you better at selling it.
Explore all platform features to see the analytics dashboard, review pricing plans, or start a free trial to see RADIUS-powered analytics in action across your client deployments.
FAQ
What is RADIUS analytics in WiFi marketing?
RADIUS (Remote Authentication Dial-In User Service) analytics uses session accounting data from the RADIUS protocol to power WiFi business intelligence. When a guest connects to a WiFi network, the access point sends structured accounting records (session duration, device MAC address, AP identity, bandwidth usage, and timestamps) to a RADIUS server. MyWiFi Networks' analytics engine processes these radacct records into business-readable metrics: dwell time, return rates, zone heatmaps, hourly occupancy curves, and guest segmentation.
What data does a RADIUS accounting record contain?
A RADIUS accounting record contains eight key fields for WiFi analytics: Acct-Session-Id (unique session identifier), Acct-Session-Time (duration in seconds, mapping to dwell time), Acct-Input/Output-Octets (bandwidth usage as engagement proxy), Called-Station-Id (AP MAC for zone mapping), Calling-Station-Id (device MAC for guest tracking), NAS-IP-Address (network access server), and Acct-Status-Type (Start/Interim-Update/Stop). The protocol was designed in 1991 for modem dial-up but remains the standard across all enterprise WiFi hardware.
Which hardware vendors support RADIUS accounting for WiFi analytics? RADIUS accounting is supported by virtually every enterprise and prosumer access point. MyWiFi Networks integrates with 20+ vendors: Ubiquiti UniFi (native RADIUS via controller), Cisco Meraki (cloud-managed RADIUS), Ruckus (SmartZone and Unleashed), Cambium cnMaestro (MyWiFi is white-label with this integration), Aruba (Instant On and Central), TP-Link Omada, MikroTik, Teltonika, Draytek, and EnGenius. No additional hardware or sidecar appliances are required.
How does RADIUS analytics handle MAC address randomization? Modern iOS (14+) and Android (10+) devices randomize MAC addresses per network, which can inflate unique device counts. MyWiFi Networks solves this through captive portal authentication: once a guest authenticates via email, phone, social login, or WhatsApp, their session ties to a persistent profile that survives MAC rotation. This approach ensures accurate return-visit tracking and guest segmentation despite device-level randomization.
What is the difference between zone analytics and venue-level analytics?
Venue-level analytics aggregate all RADIUS data across a location, providing metrics like total unique visitors, average dwell time, and capture rate. Zone analytics use the Called-Station-Id field (which AP served the session) to map guest activity to physical areas within a venue: lobby vs. dining room vs. outdoor patio. Zone-level analytics require multi-AP deployments and enable foot traffic heatmaps, flow diagrams between zones, and zone-specific occupancy tracking that traditional single-AP setups cannot provide.