Analytics and Reports

• Analytics & reports
• My revenue
• Guest activity
• Notifications
• Security alerts
• Abuse & IP complaints
• Banned devices
• Data retention (POPIA auto-purge)
• Privacy requests (POPIA)

This is the full reference for this part of the dashboard. For everything else, see the main documentation.

The aggregate picture over a range you choose (7/30/90 days): guest connections, peak concurrent devices, ad views and clicks by campaign, vouchers redeemed, and SMS sent — with a downloadable CSV report. Guest connections count real portal activity (every ad-unlock, voucher redemption, data-plan purchase, or free-access grant), so it stays accurate even for a location whose router isn't yet reporting live telemetry. Peak concurrent devices prefers real router-reported device counts for its daily trend; if a router hasn't reported any data for the period, the summary figure falls back to your accurate monthly peak (the same number shown in Plan & pricing) rather than showing a misleading zero next to genuinely non-zero activity elsewhere on the page. A "Busiest hours" heatmap breaks the same connection events down by hour and day of week (South African time), so you can see when guests actually show up, not just how many. Below it, a capacity forecast turns your router-reported concurrent device counts into an actual recommendation — if any day of the week is trending close to your concurrent user limit, it says so directly (e.g. "trending toward your limit on Saturdays") instead of leaving you to read the trend off a chart yourself; needs at least one router actively reporting to appear at all. The stats grid also includes an average guest download/upload speed for the range — an estimate of what a connected guest actually experienced (router throughput divided by how many devices were online at each sampled moment), separate from any cap you've configured, so you can tell whether a slow week is your own settings or your ISP underdelivering.

A "Footfall & repeat visitors" panel answers "who's actually visiting my venue," beyond just how much data was used: unique visitors for the range, how many are brand new versus coming back, a returning ratio, and the single busiest hour (derived from the same heatmap above). A guest counts as returning if they connected at all before the start of your selected range — going further back than the range itself, not just within it, so a monthly regular still shows as returning even on a 7-day view. One thing deliberately left out: a "time spent on site" figure. There's no reliable way to measure that today — a voucher's or bundle's configured duration is how long access is valid for, not how long the guest actually stayed, and building a real one needs session-level tracking this platform doesn't do yet, so rather than show a number that would just be wrong, it's left out until it can be done honestly.

Footfall deep dive. Directly under that panel, for the same range. It shows connections and unique guests with the change against the previous range of the same length, how many guests usually come on weekends, your three busiest and three quietest day-and-hour slots (a quiet slot is a good time for maintenance or a router restart), how many different days each guest came (1 day, 2-3, 4-9, 10 or more), and the usual gap in days between a returning guest's visits. A location menu narrows everything to one router, and with all routers selected you also get a per-router table. Two heatmaps are shown: devices connected at once, taken from router readings and only kept for the last 7 days so it fills in gradually, and connections by day and hour for that location. A "connection" is counted each time a guest is granted access. All hours are SAST (UTC+2, also Namibia's time).

Full guide: Analytics and Reports.

What you've actually earned, in one place — separate from what you owe us in Plan & pricing. Three totals, each for the date range you pick: ad revenue (what advertisers paid for views delivered on your captive, capped at each campaign's own budget — see Ad pricing), voucher revenue (the price you set on every voucher actually redeemed — see Generate vouchers), and data plan revenue (card payments guests made for a Data plan). A daily trend chart breaks all three down together, and "Download statement (PDF)" generates a one-page summary for any calendar month — revenue earned alongside your subscription cost for that month, and the net of the two — for your own bookkeeping. Next to it, "Download service report (PDF)" produces a one-page service report for the same month that you can hand to the venue owner, municipality or sponsor to show the service really ran: network uptime (overall and per router), guests served (unique, new and returning), new sign-ups, data used, ad impressions, revenue by source, the busiest hour and day, and a connections-per-day chart. Uptime comes from each router's own heartbeat, checked every 5 minutes, so every outage is accurate to within a few minutes; a router counts from the day it was registered, and an outage that is still open is counted up to the end of the month. Financial team members can download it too.

Every rand shown here is 100% yours — ISN never takes a share of ad, voucher, or data plan revenue. Your only cost on this platform is the flat subscription in Plan & pricing; what guests and advertisers pay is a separate transaction that never routes through an ISN-controlled account in the first place. Card payments for data plans, and prepaid 1Voucher/OTT redemptions, settle straight into your own Paystack, PayFast, or Flash Group merchant account (see Payment gateways) — we only ever check that a payment happened, we never touch the money itself. Vouchers you generate yourself are sold however you choose (cash, front desk, your own booking system); the platform just tracks issuance and redemption, so the full price is whatever you actually collected. Ad campaigns go further still — a local business's spend is only ever tracked here (views delivered × your price, capped at their budget, per Ad pricing) so you know exactly what to bill them; no payment gateway is involved in a campaign at all, so collecting from that advertiser (invoice, EFT, cash — your call) is a matter between you and them alone.

Revenue by router. If you run more than one router or location, a second table below the trend chart breaks ad, voucher, and data-plan revenue out per router instead of one combined total — plus ad views, voucher redemptions, and data plans sold at each one, so you can actually see which locations are underselling and which are carrying the venue. Two independent signals flag a router worth a look: a router earning under half your per-router average for the selected range is Underselling (over 1.5× is Overselling) — that's compared against your OTHER routers right now. Separately, a Trend column compares each router against its OWN prior period of the same length, so a router that used to earn well and just dropped shows up even if it's still above the fleet average. Each router also shows its live online/offline status right alongside its numbers, since a router that's simply been offline explains low revenue on its own. A "Rank by" toggle lets you sort the table by total revenue or by growth — useful for presenting which locations are actually improving, not just which are biggest. (Survey revenue isn't broken out per router yet, and stays in the combined total above only.) The same breakdown, same numbers, is also on the Captive Dashboard's own Billing & Revenue tab.

Revenue by department. A third table rolls the same revenue up by router group instead of by individual router — one row per group with its router count and ad/voucher/data-plan/total revenue, plus an "Ungrouped" row for any router not yet assigned to one. Useful once "per router" is too granular to present — a city reporting Parks routers vs Libraries routers, a franchise reporting by branch — without having to add up individual routers by hand every time. Purely a different view of the same numbers above; assigning routers to groups is done under Router groups, not here.

The individual event log, for when you need to trace one specific guest or incident rather than the aggregate trend: registered users (name, email/phone, bundle and remaining data, status, when they registered), recent bundle-grant transactions (identifier, bundle size, router, when granted), and domain visits — POPIA-compliant, daily anonymised snapshots aggregated by domain only, never a per-guest browsing history.

Everything that needs your attention, surfaced by email in one place instead of you having to notice it yourself in the dashboard: low SMS credits (and, if you've set one, your monthly auto-topup spend cap being reached), capacity approaching and capacity-reached warnings (your billing/concurrent-user ceiling — see Plan & pricing), bandwidth congestion alerts (real Mbps saturation on a specific router — a different thing from the capacity warnings above; see Bandwidth congestion alerts), billing reminders sent a few days ahead of a trial converting to paid or a subscription renewing so a charge is never a surprise, a router offline alert the moment any router in your fleet stops reporting in (checked every 5 minutes, and only ever sent once per outage — not repeated every check while it stays down, with an opt-in SMS version too — see Fair Pause & outage alerting), and an optional weekly summary — revenue, guest connections, busiest hour, and SMS balance, sent every Monday morning. Each type can be switched off individually if you'd rather not receive it. Every one of these is sent to your own account's registered email — never anyone else's, and never shared across tenants.

Automatic anomaly detection for internal accounts and roaming logins, tenant-scoped, surfaced as a live feed you can review from the dashboard. Three signals feed it: impossible travel (the same account authenticating from two locations too far apart to genuinely be the same person, inside too short a window), excessive device cycling (one identifier moving through an unusually high number of distinct devices in a day — the pattern a shared or leaked login produces, not normal multi-device use), and a general credential sharing detected signal covering related patterns.

These are signals, not an enforcement gate — nothing is auto-blocked or auto-logged-out when one fires, since a legitimate case (a phone and a laptop, a household sharing one account) can still occasionally brush against the same thresholds. An alert is something to review and act on yourself — reset the account's credentials, tighten its device limit, or reach out to whoever it belongs to — rather than something the platform decides on your behalf.

A log-and-lookup tool for the question every network operator eventually has to answer: "who was actually using this IP at this reported time?" Log a report with the IP address involved, when the activity was reported to have happened, a description, and (optionally) who reported it — then click "Look up" to have the platform find the answer from data it already has: which of your routers actually had that public IP at that exact moment, and which of your guests had a live, granted access session on that router at the same time.

How the lookup actually works. Every router already reports its own real public IP address to us on its normal check-in (the same IP any outside party sees when your router talks to the internet) — we keep a full history of this per router, not just the current value, specifically because a complaint often lands days after the fact, by which point a dynamic IP may have already changed. The lookup matches the reported IP and time against that history to find the router, then cross-references that router's own granted-access log for guests who were online at that exact moment. If your router's IP hasn't changed since the reported time, this resolves cleanly; if it has changed more than once since, or the router wasn't registered with us yet at that time, there may be nothing to match — the tool tells you either way rather than guessing.

What this deliberately is not. It's an operational log and a lookup tool, not a legal-advice generator — it doesn't draft a takedown notice, cite a specific law, or tell you what you're obligated to do with a complaint once you've resolved it. Legal requirements around network-abuse complaints vary by jurisdiction and by what's actually being alleged; for that part, talk to your own legal advisor rather than relying on anything generated here.

Blocks a specific device's MAC address from your WiFi entirely, for cases like the abuse tool above turning up a repeat offender. Found under Security → Banned devices. Enter the device's MAC address, an optional reason for your own record, and choose whether the ban applies to just one of your routers or across your whole fleet at once. An already-connected device is also kicked off immediately as part of the same action.

Enforced at the router itself, not just in this dashboard. A ban pushes a real block rule to the router — a MikroTik hotspot IP-binding marked "blocked", or an OpenWRT firewall rule dropping that MAC's traffic — so the device genuinely cannot reach the network, rather than this platform trying to recognize and refuse it at every single one of the different ways a guest can get online here (voucher, ad-unlock, point-of-sale, SSO, roaming). A block at the router is the one mechanism that automatically covers all of those at once, because the device never gets anywhere near any of them.

A fleet-wide ban is pushed to every router you have at the moment you set it; a router you add afterward does not automatically inherit existing bans yet — re-ban from this page if you want it to also apply to a brand-new router. Works for MikroTik and OpenWRT-family routers; not yet verified against real hardware for either.

Off until you set a window (a blank/empty value leaves it off — there's a 30-day floor once you do turn it on, enforced regardless of what's entered, so a mistaken tiny value can't purge near-fresh data). Once configured, a daily check anonymizes the record of any guest who hasn't logged in for at least that long — clearing their name, date of birth, email, phone, and registration IP/device info. Their past usage and revenue totals stay exactly as they were in your reporting; only who they were is cleared, not what they did.

Worth knowing the real scope: this clears the guest's main identity record, but doesn't yet reach into every historical row elsewhere on this platform that separately stored their contact details (e.g. an old voucher redemption log) — a real, working purge of the primary record, not a claim of scrubbing every last trace. A guest who returns after their record was purged simply signs up again as new. A "Purge history" table below the setting shows every run — how many records, and what window was active at the time — for your own compliance record.

South Africa's Protection of Personal Information Act gives every guest two rights this handles for you: to see the personal information you hold about them (section 23), and to ask for it to be deleted (section 24). Find it under Security → Privacy requests. Only the account owner and the IT Department role can open it, since it hands over or removes a real person's data.

How guests use it. A guest already signed in to your WiFi finds Download My Data and Delete My Data right in their own My Account panel, next to their profile, including from the link in your own guest terms (section 8) — no separate page or re-typing their number/email, just their password once to confirm it's really them. Download My Data gives them a file straight away with their profile, data bundles, purchases, vouchers, devices, sign-ins and ad activity. It's logged in your list as done, with nothing for you to action. Delete My Data lands in your list as "Waiting on you" with a due date 30 days out, and you get an email about it. This is the same check your WiFi login already uses, with the same lockout after repeated wrong guesses, and a guest can only ever see or request their own data. A guest who isn't currently signed in has nothing to check a password against, so they're prompted to log in first — the same as opening any other part of My Account.

What "Delete now" actually does. The guest's name, email, phone, date of birth, password and sign-up details are cleared. Their devices are signed off the network and removed. Ad views, ad clicks and visit history are kept for your ad billing totals but no longer point to the person (the IP address and browser details are cleared too). Connection and billing records (sign-ins, data used, bundles, purchases, vouchers, till grants, roaming) are kept, because RICA requires them for 5 years. This matches what your captive's terms already tell guests, and the guest is told the same thing when they ask. If any part fails, nothing is marked complete, so you can simply press it again. For a staff or student username account, the login itself stays in Internal accounts for you to disable there.

Other options. Download data gives you the same file the guest would get, for a request that came in by email or at the front desk. Refuse closes a request with a reason, which POPIA requires. A lawful reason might be an unpaid account or a legal hold. Log a request for a guest records a request made in person, by phone or by email. Confirm it's really them first. Once a request is closed, the guest's actual number or email is removed from the request itself, and only a masked version (e.g. 082****567) stays in your records.