Measure visitor flows with data minimisation: a buying guide

A municipality should plan visitor-flow measurement backwards from its intended decision. A count per time window can cover a square's occupancy. Movement between zones requires short-lived links between observations. Return rates or dwell histories need longer recognition and raise the privacy burden. The least intrusive design supplies no more resolution than municipal teams can use.

If a system processes device identifiers, signal paths or another recognisable feature, the municipality should treat it as personal-data processing until evidence proves otherwise. Hashing does not establish anonymity. Before procurement, data protection, the service department and IT need to test whether anyone can single out a person, link observations or infer information about them.

Four desired outputs lead to four data models

Visitor flow covers several tasks. A town-centre manager may compare footfall, an event team needs density near an entrance, and transport planners want movement between areas. Each task requires different source data.

Desired output	Smallest useful data model	Suitable decision	Privacy risk
Passages across a line	count by direction and time window	opening hours, cleaning, before-and-after comparison	low if no recognisable feature is created
Presence in a zone	estimated number by area and time window	occupancy, staffing, access information	depends on the sensor and intermediate data
Movement between zones	observation linkable for a limited window, followed by aggregation	route design, market layout, corridor comparison	elevated because the method needs linkability
Return or dwell history	recognition over a longer period	campaign analysis, repeat-visit rate	high because longer-term profiles become possible

The resolution rule for municipal visitor analytics is: choose the decision first, then the smallest spatial unit and coarsest time window that can support it. Procure recognition where evidence shows that plain counts cannot answer the question. The European Data Protection Board's guidelines on data protection by design say controllers should first assess whether they can meet the purpose with less detailed or aggregated data, or without personal data. The guidelines name data avoidance, limitation, aggregation, and prompt anonymisation or deletion as core data-minimisation measures (EDPB Guidelines on Data Protection by Design and by Default).

Comparing market-day footfall with an ordinary Saturday does not require a device identifier that stays stable for weeks. A line counter or a zone estimate aggregated after a short window can provide the comparison.

Anonymity requires technical evidence

The European Data Protection Board distinguishes pseudonymisation from anonymisation. Pseudonymised data remains personal if someone can attribute it with additional information. The Board tests anonymity against three risks: singling out, linkage and inference (EDPB guide to anonymisation).

For radio sensors, the municipality should examine the complete processing chain: received signal, created identifier, first transformation, raw-data lifetime and cross-location recognition. A salt that rotates each day can limit linkage. A replacement value that remains stable across several locations still represents an individual path.

The Independent Centre for Privacy Protection Schleswig-Holstein classified virtual or dynamic MAC addresses used for Wi-Fi tracking as personal data. Its public-space visitor-count report says the processing, purpose and risks determine the assessment (ULD on Wi-Fi tracking and crowd density). A specification needs evidence beyond a "GDPR compliant" label.

CNIL offers a useful technical benchmark, although a German municipality must assess its legal basis under German and European law. The French authority separates non-identifying passage counters from device tracking. Depending on the design, it expects prompt deletion, limited areas and periods, visible information, and effective objection mechanisms (CNIL guidance on footfall measurement in public spaces).

The sensor type limits the claim a team can make

Light barriers, thermal sensors, radar or local image processing can count entries and exits without cross-location recognition. They suit defined entrances. Groups, opposing flows, open areas and altered sight lines expose weaknesses that the pilot must test.

Wi-Fi or Bluetooth observations can estimate links between zones because a device appears at several points. They count devices, while some visitors carry none and others several. Stationary devices add noise, and dense crowds alter radio conditions. A TU Delft event study found that cameras gave accurate local counts without routes, Wi-Fi supplied routes with low penetration, and GPS supplied detailed but discontinuous information (TU Delft comparison of measurement methods).

A Bamberg research project compared a privacy-aware Wi-Fi estimate with a laser scanner. The estimate approximated visitor density, while deviation increased at higher footfall (University of Bamberg CrowdAnym study). Municipal teams should infer two limits: privacy measures affect utility, and quiet-period calibration does not establish festival quality.

Reference counts turn estimates into operating data

A pilot needs independent references. Staff or a separate counter records passages during quiet hours, peaks, rain, events, group arrivals and changed routes. The team checks error by location class, gaps, duplicate counts, stationary-device noise and the device-to-person factor.

A visitor estimate is ready for operational use when its purpose, area, time window, estimation method, reference error and data status travel with the value. If one of those elements is missing, the service department should use the number as an unconfirmed signal. An access or evacuation decision needs stricter evidence than a month-to-month town-centre footfall comparison. The service department defines that boundary before the pilot.

The quality report separates the naive total, adjusted estimate and factor, then marks gaps and model changes. A factor change starts a new comparison period. Otherwise, a method break can look like a change in the town centre.

The specification asks for the data flow, not a badge

Teams should test the supplier with one scenario: a device crosses two zones and returns the next day. For each processing step, the supplier states which value arises, where it resides, who can read it and when it disappears.

Six contract questions provide an initial filter:

1. Which raw features does the sensor receive, and do they leave the device?
2. How does the method prevent singling out, cross-location linkage and inference?
3. Which keys or salts exist, who controls them, and how often do they rotate?
4. After which period does the system retain no data beyond aggregate counts?
5. Which exports, logs and subcontractors can expose intermediate data?
6. How does the municipality inform people, process objections and delete related data?

The European Commission requires a Data Protection Impact Assessment for processing expected to create a high risk, including large-scale systematic monitoring of publicly accessible areas (European Commission guidance on data protection obligations). The data protection officer assesses scale, duration, linkability and purpose before award.

A pilot ends with approval for each metric

The service department first names the decision and acceptable error. Data protection and IT draw the data flow, then the supplier installs representative measuring points. The team collects references, triggers gaps, and checks deletion, roles, export and model changes. At the end, the controller approves, limits or rejects each metric in its own decision.

An approval might read: "Footfall estimate by hour for comparing similar Saturdays, not for closing an entrance." A privacy boundary adds: "Zone paths are aggregated within the agreed window; the service department cannot access raw or replacement identifiers, and verified deletion follows."

When urbanOS fits this task

The product page describes CityPulse on the urbanOS Urban Data and Urban Intelligence platform as camera-free visitor analytics for municipalities and large estates. According to the page, radio sensors collect anonymised device signals, deduplicate observations within an area, and present footfall, routes, heatmaps, comparisons and forecasts. The app exposes its estimation factor and naive total, with CSV and a read-only export API.

CityPulse is a strong fit for economic-development teams, town-centre managers and large-estate operators comparing open areas and movement between zones without camera images. The municipality must confirm the described anonymisation, short retention, limited linkage, public information and local error. A single doorway will suit a non-identifying counter with less overhead. Capacity decisions with legal or safety consequences need an approved method and fallbacks.

The approval formula joins utility and intrusion

Before routine operation, the project lead should sign off eight statements:

• The service decision and its acceptable error are documented.
• Every published value carries its area, time window, method and status.
• The team assessed plain counting as a less intrusive option.
• Raw features, replacement identifiers, keys, storage locations and deletion periods are known.
• The method passes the tests for singling out, linkage and inference.
• Reference counts cover peaks, groups, weather and changed routes.
• Public information, individual rights and responsibilities work on site.
• Each metric has its own approved use and explicit non-use.

The procurement question is precise: does the service department need a count, movement between zones, or recognition over a longer period? Each added link needs proven utility, while the team reduces data volume, retention and access. The result should give municipal staff useful analytics and a privacy design they can explain in routine operation.