In brief
Pixels, social login and age or gender inference look attractive on guest Wi-Fi. Each one puts a burden on the business. What the box collects instead, and an honest trade-off.
A design decision
The guest Wi-Fi portal is one of the few digital touchpoints a business has with its guests. So the thought "they are here anyway, let us collect a little data" comes naturally. When we designed Hotspot-Box we deliberately chose the opposite: the portal verifies identity, keeps the record and sends the guest on their way.
This article explains the reasons. It is not sales copy; we also spell out what you give up.
Three tempting things and the burden they bring
Tracking pixels
Put an ad network's pixel on the portal page and that network learns it has seen the guest's device at your premises, then adds it to its profile. The guest has no idea. The burden: you must declare the third-party transfer in your privacy notice, obtain separate consent for cookies and tracking technologies, and, if the pixel provider is abroad, meet the rules on international transfers. For a small café, that burden far outweighs what the pixel delivers.
Social login
"Log in with your social account" is easy, one tap. But it has two problems. First, a social account is not identity verification; anyone can open an account under any name. It does not answer the "who connected" question that the Law 5651 record exists for. Second, the profile data that arrives at login (name, photo, friend count, likes) lands in the business's hands. You are now responsible for that data; even proving you did not keep it is hard. That is why the box has no social login.
Age and gender inference
Some systems produce an age and gender guess from a name or device details. A guess is still personal data processing, and it is often wrong. On top of that, once your records contain fields like "probably female, 25-34", your inventory, privacy notice and access matrix all grow. Fields that are not needed to answer an official request only generate risk.
| Method | Promise | Real burden |
|---|---|---|
| Tracking pixel | Retargeting | Third-party transfer, separate consent, international transfer |
| Social login | Easy login, profile data | Not identity verification, unwanted profile data |
| Demographic inference | Customer analytics | Wrong guesses, growing data inventory |
What the box collects instead
Only what is needed to build the record and provide the service:
- Verification detail: phone number verified by SMS (stored encrypted, masked in the panel), coupon code or e-mail
- Device MAC address, assigned internal IP, session start and end, NAT mapping where applicable
- The explicit consent record for the privacy notice
There are no visited sites, no content, no location, no social profile and no demographic guess. Records stay on the box; they do not go to a cloud, abroad or to us. Our platform never sees a guest number; the box sends the SMS straight to the provider. Device telemetry carries no guest data either; the platform only watches the box's health, licence and SMS credit. This list stays the same for the full two years; there is no "a new field was added" surprise after installation.
The trade-off: what you do not get
Let us be honest. With this approach you will not have:
- Guest profiles and segments
- Retargeting audiences
- Demographic reports such as "what share of our visitors are women"
- Marketing dashboards
What you do have are the operational reports needed to run the business: hourly load, the login funnel (how many devices opened the portal, how many entered a code, how many connected), CSV export and scheduled reports. These describe the network as a system, not the guest as a person. You know how many devices connected at which hour; you do not see who connected on the report screen.
You can show a survey or an announcement on the portal. The survey gives your business feedback; the announcement shows today's menu or an event. Both stay on the page; no message goes to the guest's number.
"Isn't e-mail login data too?"
A fair question. The box supports e-mail login, and an e-mail address is personal data as well. The difference is the purpose. Here the address is taken to verify the guest and build the access record, and it follows the same record rules: kept 730 days, visible only to an authorised role, then deleted. It is not moved to a newsletter list. So the question is not "is data collected" but "for which purpose, and does it leave that purpose". The box has no tool for a second use; that is not a gap, it is the design.
Who this decision suits
Businesses that treat guest Wi-Fi as a service and an obligation rather than a marketing channel. Cafés, restaurants, hotels, dormitories, clinics, offices, factories, event venues. You may well have separate tools for marketing; Wi-Fi does not have to be one of them.
If you are looking for a system where collecting marketing data is the main point, Hotspot-Box is not the right product for you. We would rather say so up front than disappoint later.
Why this is better
Three reasons:
- Less data, less risk. Data you do not hold cannot leak.
- A shorter compliance file. The inventory, privacy notice and access matrix stay small.
- Guest trust. Someone who gives a number for Wi-Fi knows they will not see an ad the next day.
See industries for portal set-ups by sector and products for the product options.
This article is for general information only and is not legal advice.