New: AI-powered Google Review automation is liveLearn more →
VoqadoWiFi
Use Case

Get Real Analytics From Your Guest WiFi

The job to be done

Find out how many people actually come in, how long they stay and how many come back, using data you already generate.

Most venues run on two numbers: takings and covers. Neither tells you how long people stayed, how many were returning, or which day is genuinely quiet rather than just feeling quiet. A guest WiFi portal sits at the door of a data set that answers those questions, because every connection carries a time, a duration and an identity. Read carefully it is genuinely useful. Read carelessly it will confidently mislead you.

The three measurements that matter

Connections tell you volume: how many guest sessions started in a period, broken down by day and by hour, which is the closest thing to a footfall curve most independent venues will ever have. Dwell time tells you duration: how long sessions lasted, which separates a venue people sit in from a venue people pass through. Repeat rate tells you loyalty: what share of sessions came from an identity you had seen before. Volume, duration and return are the whole picture, and every other chart is a slice of one of them.

How to read the hourly curve without fooling yourself

The hourly connection curve is the report operators look at most and misread most. It shows when people connected, which is not the same as when people arrived, because some guests connect on the way in and some connect twenty minutes later when they run out of conversation. It also undercounts short visits almost entirely. The correct use is comparative rather than absolute: this Tuesday against last Tuesday, this month against the same month last year, the hour before a promotion against the hour after. Compare like with like and the noise cancels. Read a single day in isolation and you will invent a story.

What guest WiFi analytics cannot see

Being explicit about the blind spots is what makes the visible parts trustworthy.

  • Guests who never connect. Anyone with unlimited mobile data, a short visit, or no interest in your network is invisible.
  • Spend. The portal sees sessions, not transactions, so revenue attribution needs point of sale data joined in separately.
  • Group size. One connection can represent a table of six or a single person with two devices.
  • Passers-by, unless you deliberately measure them, and even then randomised hardware addresses make presence detection unreliable by design.
  • Anything about a guest beyond what they told you at the login and what their session recorded.

Turning the numbers into a decision

Analytics only earn their keep when they change something. The pattern that works is to pick one question a month and answer it properly. Is the new opening hour worth staffing? Compare connections in that hour across four weeks before and after. Did the menu change hold people longer? Compare median dwell time either side of the change, in the same day part. Is the loyalty sequence working? Compare the returning share of sessions, month over month. One question, one comparison, one decision. Dashboards that are watched daily and acted on never are the most common failure mode in this category.

Privacy, which is a design constraint rather than a footnote

This data describes real people in a real place, so the collection has to be proportionate and the storage defensible. Collect what you will use, tell guests plainly what is recorded, keep session records for a defined retention period rather than forever, and keep analytics aggregated where individual detail is not needed. VoqadoWiFi stores consent alongside guest records so the marketing basis and the analytics basis stay separate and auditable. A guest who declines marketing still generates a session your footfall curve can count, and should not thereby end up on a mailing list.

How to set it up

In order. Skipping a step here is usually why a portal ends up showing a spinner instead of a login screen.

  1. 1

    Get a full month of clean data before you conclude anything

    Weekly seasonality is strong in hospitality and retail. Any reading taken across less than four of each weekday is measuring noise.

  2. 2

    Set the dwell threshold to match your venue

    A coffee shop and a hotel lobby have completely different definitions of a real visit. Configure the minimum session length that counts before you start comparing periods, and then leave it alone.

  3. 3

    Separate staff and payment devices onto their own SSID

    Staff phones connecting all day are the single biggest source of inflated dwell time and phantom regulars. Keep them off the guest network entirely.

  4. 4

    Write down the question before you open the dashboard

    Decide what you are trying to learn and what result would change your mind. Numbers looked at without a question in hand always confirm whatever you already believed.

  5. 5

    Export and keep a monthly snapshot

    Retention limits mean live dashboards eventually forget. A monthly export gives you the year over year comparison that in-product reporting cannot, and it is the comparison that matters most.

Who this suits

The venue types where this job comes up most often, and where the data the portal produces is dense enough to act on.

Restaurants planning staffing against real footfall curves
Retail stores measuring dwell time by day part
Hotels understanding lobby and public area usage
Bars judging whether an event night actually drew people
Gyms tracking attendance patterns beyond check-in software
Multi-site operators comparing locations on the same measures

Run this on your own network first

The Starter plan is free forever: one location, 25 logins a month, a branded splash page and consent logging. Growth is $49 a month and covers up to three locations. Works with TP-Link Omada and Ubiquiti UniFi.

Common questions

Does this count people who do not connect to the WiFi?

No. Everything described here is derived from actual portal sessions, so guests who never connect are not in the data. That is a coverage limit rather than a flaw, and it is why the numbers should be read as trends over time rather than as a headcount.

Is MAC address randomisation a problem for these reports?

It breaks device-level tracking, which is why identity in VoqadoWiFi hangs off the portal login rather than the hardware address. Volume and dwell reporting are unaffected. Repeat-visit reporting depends on the guest logging in the same way each time.

Can I compare two of my locations?

Yes, if both run portals under the same account. The Growth plan covers three locations. When comparing, hold the dwell threshold and the reporting period identical across sites, otherwise you are comparing definitions rather than venues.

How long is session data kept?

Retention is a setting you should choose deliberately rather than leave at a default, because it is both a privacy commitment to your guests and the limit on how far back you can compare. Export a monthly snapshot if you want year over year history that outlives the retention window.

Read next

These jobs share the same plumbing, so operators normally set them up in sequence rather than one at a time.

Use Case

Measure How Many Customers Actually Come Back

Replace a gut feeling about regulars with a number you can compare month to month.

Use Case

Run a Loyalty Programme Through Your WiFi

Recognise and reward guests who come back, without asking anyone to install an app or carry a stamp card.

Use Case

Collect Emails From Your Guest WiFi

Turn the WiFi login that already happens hundreds of times a month into a consented, deliverable email address you own.

Terms used on this page

Related pages

← Back to all use cases

Stop reading.
Set it up in an afternoon.

Free forever on Starter: one location, 25 logins a month, branded splash page and consent logging. Enough to see this whole playbook running on your own network.

TP-Link Omada and Ubiquiti UniFi  ·  No card required