Wi-Fi tracking after MAC randomization

Ten years ago it was the best deal in the analytics market: you put the box on, it listens to the broadcast, and you get the number of visitors, the proportion of those who returned, the time of stay and the distribution by zones. No tags, no consents, no cameras, almost no money. The box listened to service requests that smartphones send out in search of familiar networks, and counted unique MAC addresses.

Today, the same service continues to be sold in the same words, but it has stopped working. And more importantly, it was broken not by competitors, but by operating system manufacturers, purposefully and irreversibly.

This article is about what's left. Spoiler: there's a lot left, but not at all what the presentation promises.

How it worked

A smartphone with Wi-Fi enabled periodically sends on-air requests "is there a network I know here" — probe request. In these requests, the hardware address of the interface, MAC, is transmitted: unique, unchangeable, hardwired into the device. The receiver, which does not need either a connection or a password, hears these requests and records the addresses.

Everything else came out of it:

• invoice — the number of unique addresses for the period;
• repeat sessions — same address in a week;
• time of stay — from the first to the last request;
• zones — several receivers and a comparison of signal levels, trilateration with an accuracy of about 5-15 meters;
• passability and conversion — the proportion of those who passed by to those who went inside.

The scheme was cheap and sufficient for a shopping mall. And it was also an obvious privacy problem: anyone with a receiver could track the movement of a particular person around the city without asking anyone.

What's broken

Apple and Google have closed this at the operating system level. With iOS 14 and Android 10, a random, periodically changing MAC address in service requests has become the default behavior.

For analytics, this does not mean a deterioration in accuracy, but the destruction of the very foundation: the identifier has ceased to be an identifier. One guest who has spent four hours in the complex looks like a dozen different visitors who have come in for twenty minutes each.

The scale of the effect in open sources is described mainly by vendors, and the figures should be treated accordingly. Analytics providers report a three- to five-fold increase in "unique visitors" after OS updates; industry reviews estimate the final accuracy of Wi-Fi analytics at 60-80%. Independent measurements of retail facilities could not be found in open sources, and this in itself is indicative.

It is important to understand that this is not fixed by filters. Vendors have learned to discard obviously random addresses — they have a feature in the address structure — but by discarding them, you discard almost all modern smartphones. There are old devices and those with randomization disabled, that is, an unrepresentative sample of unknown size.

De-randomization: Why it's a dead end

The natural reaction of the industry is to try to restore connectivity: to understand that a dozen random addresses belong to one device, by indirect signs. There are signs: the contents of the service fields of the request, a set of supported features, time intervals between requests, signal strength, sequence of numbers.

The academic results are impressive. In one study, a de-randomization method using "fingerprints" and signal strength achieved about 89.7% success rate versus 22.2% for a conventional approach in a multi-day field trial. In the work of 2026, clustering by the DBSCAN method gives about 89.6% of the total accuracy on marked-up records.

And exactly here it is worth stopping for three reasons.

The first is technical. Both results were obtained under controlled conditions: isolated channel, marked data, limited number of devices. The shopping mall on Saturday is hundreds of devices, dozens of models, intersecting streams and traffic. Laboratory 90% are not transferred there, and none of these methods guarantees the stability of the metric over time, and analytics lives by stability: it is not the absolute number that is important, but the comparison of this Saturday with the last.

The second is legal. MAC randomization is a privacy protection mechanism built in by the manufacturer. The system that purposefully overcomes it is not engaged in "counting visitors", but in restoring identifiers that the user has hidden. A legal assessment of such processing should be obtained from a lawyer before implementation, and the argument "we do not know the FULL name" does not work well here: the law on personal data speaks about the definiteness of a person, and not about the presence of a full name in the database.

The third is reputational. This is the part of the project that is unpleasant to explain to a guest if he asks. A good test for any tracking technology: write on the sign what exactly you are doing. "Counting the number of visitors" is easy to spell. "We are restoring the identifiers of your phones that your phone specifically changes" — it is not written.

The conclusion is simple: the money that is asked for de-randomization is better spent on counters at the entrances. They give a stable number, do not require excuses and cost about the same.

What works reliably over Wi-Fi

Two scenarios in which Wi-Fi remains an honest data source.

Connected devices

The device connected to the network uses a stable address within the session, and the access point controller sees its movement between points. This gives a zonal picture of those who are connected: staff with working devices, equipment, terminals, as well as guests connected to your Wi-Fi.

The tool is good for infrastructure tasks — where the staff is, how the access points are loaded, whether the cash register has disappeared from the network. For guest analytics, it is limited to the percentage of connected users.

Guest Wi-Fi is also an important Russian feature

It would seem that here is the solution: make a good guest Wi-Fi, and the connected guests will give both an identifier and consent. The scheme is working, but in Russia it has specifics that you need to know before you start.

Public access to Wi-Fi in Russia requires user identification. As explained by Roskomnadzor, the decree of the Government of the Russian Federation dated 07/31/2014 No. 758 introduced mandatory identification of users and their equipment: user information and the MAC address of the device. Acceptable methods of identification are an identity document, a mobile phone number, or an account on the public services portal; authorization via a social network is not provided for by law.

Two practical conclusions follow from this.

The first one. "Anonymous analytics on guest Wi-Fi" in Russia is a contradiction in terms. The network, by definition, contains user identification information associated with the MAC address of his device. These are full-fledged personal data with a full set of operator responsibilities: foundation, notification of Roskomnadzor, policy, terms, rights of the subject, protection. Not "analytics without consent", but on the contrary — the most binding of all the options in this series.

The second. If you already have guest Wi-Fi and are configured according to the rules, you already have both an identified audience and a legal framework. Then connection analytics is not a new project, but an extension of an existing one, and this is a reasonable way for HoReCa and events where the application will not be installed, but they will willingly connect to Wi-Fi.

The size of fines for violating the requirements for public networks in open sources are given differently and often with reference to draft laws, and not to the current norms. Before making decisions, the figures should be checked according to the current version of the Administrative Code — in the legal article of the series this is sorted out with the indication of articles.

MAC address: personal data or not

A question to which there is no definite answer, and this is also an answer.

The regulator's position as a whole boils down to definiteness: unique device identifiers, including MAC addresses, may relate to personal data if they allow identifying the user - this approach is given with reference to the letter of Roskomnadzor dated 05/27/2014 No. 08-7234. Separately, there is a position that the MAC address, together with other information - geolocation, cookies — is personal data.

Judicial practice is contradictory. In the reviews there is a reference to the definition of the First Court of Cassation of General Jurisdiction dated 05/25/2022 in case No. 88-11406/2022, where the court proceeded from the fact that different people can use one device, which means there is no exact link to the person. In a separate case, the Supreme Court did not recognize the e-mail address as personal data.

Practical conclusion for the project: do not build an architecture on the assumption that the MAC address is not personal data. This is a controversial position that you will have to defend, and not a fact that you can rely on. All the listed documents are secondary references from legal reviews, and before making a decision, they should be read in the original source.

Wi-Fi RTT: measuring distance instead of guessing

In parallel with the collapse of probe tracking in Wi-Fi, what positioning really knows was developing: measuring the signal travel time.

802.11mc (FTM). The first generation, accuracy of the order of 1-2 meters under good conditions. It has been supported by part of Android devices for a long time.

802.11az. The next generation. The Android documentation reports that support for the so-called non-trigger based ranging appeared in Android 15, and the application can search for both 802.11mc and 802.11az access points in one request. A prerequisite is that the access point must support the appropriate standard.

Real accuracy. This is the case when there are independent measurements, and they are sobering: according to research, a level of about a meter is reached in line of sight on wide channels, and in the absence of line of sight, the error grows to about five meters.

802.11bk. Further expansion with a band up to 320 MHz, aimed at approaching the accuracy of UWB. So far, this is the standard, not the products.

The main limitation of the whole line. You need at the same time: a phone with support, an access point with support and firmware, and — critically — an application. The distance measurement is initiated by the application on the phone; the infrastructure itself does not recognize the position of the guest. That is, in terms of coverage, this is the same "guest with an application" scenario as Bluetooth navigation, with all its limitations. As a navigation tool in a large complex, it is promising; as a flow analytics, it is not.

Wi-Fi Sensing: 802.11bf and measurement of a person without a device

The most interesting thing that is happening now is that it reverses the logic of the topic.

All previous technologies measured the device. Wi-Fi Sensing measures a person: it analyzes how the body distorts radio waves between the transmitter and receiver. You don't need a phone, you don't need a label, a person can be without everything.

The status of the standard. IEEE 802.11bf-2025 was published on September 26, 2025 as a supplement to IEEE 802.11-2024. It describes the procedures for detecting opportunities, establishing a measurement session, exchanging results and reporting in the ranges below 7,125 GHz and in the directional range of 60 GHz. An important caveat: the standard does not prescribe a single recognition model — what exactly is considered "presence" and "fall" is decided by the vendor. Therefore, the presence of a Wi-Fi 6 or Wi-Fi 7 tag on your equipment does not mean that sensing is supported in any way.

Silicon. Infineon in January 2026 announced the AIROC ACW741x family for Wi-Fi 7 with declared 802.11bf support through channel state measurement; sensing support also appears in the materials of Qualcomm Dragonwing platforms. That is, chips appeared.

Which is not. There is no Wi-Fi Alliance certification for sensing at the time of writing. It follows from this that compatibility between vendors is not guaranteed and it is too early to wait for "turnkey ready-made solutions" in the catalog.

Which already works in practice. The closest to the market are operator services for motion detection in an apartment based on a home gateway and several stationary devices, turned on by the user at his own choice. This is today's level of maturity: presence and movement, not positioning.

Security. The researchers note the absence of a mechanism for protecting service measurement packets in the standard, which opens up opportunities for falsifying results. This is essential for security systems.

And separately — the ethical side, which should be considered in advance. The technology that determines the presence and movement of a person through walls, without his device and without the ability to notice it, is by its nature much less noticeable to a person than a camera. The camera is visible, and there is a sign about it. Radio waves are not visible. If you are considering sensing for areas like locker rooms — and there is a temptation, because cameras are prohibited there — the issue of legal grounds and information needs to be resolved before installation. Technically, the presence of a person in a room, determined by the distortion of a radio signal, without reference to a person, is usually not personal data. But the boundary is thin: in a room where there is one person, depersonality is conditional. For more information, see the legal article and the article about sensors without cameras, where alternatives with a more understandable legal status are analyzed.

Three generations in one table

	Probe tracking	Wi-Fi RTT (az)	Wi-Fi Sensing (bf)
What measures	Device	Device	Human
Need a smartphone	Yes	Yes, plus the app	I don't
Who initiates	Infrastructure	The app on the phone	Infrastructure
Accuracy	5-15 m, ID destroyed	~1 m in line of sight, ~5 m without it	Presence and movement
Audience reach	Formally, everything is actually distorted	Only with the app	Everyone who is indoors
Maturity 2026	Degraded	Early, you need both a phone and an access point	Early, no certification
Legal regime	Controversial and binding	Consent via the app	Requires separate study

Where applicable on Wednesdays

Shopping mall. For counting at the inputs — no, you need counters. For the zonal picture of personnel — yes, through the access point controller. For guests — only through authorized guest Wi-Fi, with full legal circuit.

HoReCa and events. The most appropriate scenario for guest Wi-Fi: guests willingly connect, identification is already mandatory according to the rules, analytics is obtained as a by-product of the legal process.

Thermal Spa complex and water park. Wi-Fi is not a tool for tracking guests here: phones are in lockers. By the way, this is the best possible argument against Wi-Fi analytics at such facilities - your guest physically left the device in the locker room. The bracelet works, not the phone.

Fitness club. Partially works: the phone is usually with you. But the proportion of those connected to the guest network and the need for identification make this less practical than a label in the club card.

Warehouse, workshop, office. Connected devices are a working tool: tablets, data collection terminals, appliances. Here Wi-Fi as a source of zonal data is quite appropriate and does not require additional purchase.

Restrictions and how they cost

Destroyed ID. It does not do. The workaround is different: replacing the task — count with counters, identify with bracelets.

Low trilateration accuracy. It can not do without switching to RTT, that is, to the application.

Application dependency in RTT. It costs only to work with a loyal audience that has an application.

Saturation of the range. Guest Wi-Fi at 2.4GHz competes with Bluetooth tags. A reasonable practice is to take away guest devices at 5 and 6 GHz.

The phone is in the locker. A fundamental limitation for objects with wet zones. Does not do in principle.

Checklist for talking to the supplier

1. What exactly are you measuring: service requests, connected clients, RTT distance, or sensing?
2. How do you handle randomized addresses: do you discard or restore connectivity?
3. If you restore — on what signs and what is the verified accuracy on an object of our type?
4. What legal basis of processing do you assume and who is the operator?
5. How do you assess the stability of the metric over time if the proportion of devices with randomization changes?
6. What percentage of visitors does your rating cover and how is this percentage measured?
7. For RTT: which phone models and which access points are supported, do I need firmware?
8. For sensing: on which chip, which recognition model, are there any confirmed implementations?
9. How is the result checked against an independent source — a turnstile or a meter?
10. What will happen to the system if OS manufacturers make the following change to privacy?

The last question is a test. A supplier who cannot answer it sells you a technology that has already been broken once in the same way.

Sources

Sources

• Roskomnadzor: memo for those organizing public access to Wi-Fi — identification requirements, Resolution No. 758
• Purple, about randomization of MAC impact assessment (vendor data)
• De-Randomization of MAC Addresses Using Fingerprints and RSSI With ML — academic result
• Can Machine Learning Break Wi-Fi Privacy? — clustering of randomized addresses, 2026
• Android Developers: Wi-Fi RTT — Support 802.11mc and 802.11az
• Comparison of FTM 802.11mc and 802.11az protocols — accuracy measurements
• IEEE 802.11bf Overview — Standard Status, Chips, Certification
• Towards Integrated Sensing and Communications in IEEE 802.11bf — technical analysis of sensing
• ConsultantPlus: selection by MAC address as personal data — positions and practice (check primary sources)