Analyse de la fréquentation WiFi : Comment mesurer et agir sur les données des visiteurs
Ce guide fournit aux responsables informatiques, aux architectes réseau et aux directeurs des opérations de sites une référence pratique et technique pour le déploiement de l'analyse de la fréquentation WiFi dans les environnements de l'hôtellerie, du commerce de détail, de l'événementiel et du secteur public. Il couvre l'ensemble du pipeline de données — de la capture des requêtes de sondage 802.11 et du positionnement basé sur le RSSI jusqu'au traitement des données conforme au GDPR et aux tableaux de bord de business intelligence exploitables. Les lecteurs repartiront avec un cadre de mise en œuvre clair, des études de cas réelles et les critères de décision nécessaires pour sélectionner, déployer et optimiser une plateforme d'analyse WiFi ce trimestre.
🎧 Écouter ce guide
Voir la transcription
Résumé Exécutif
L'analyse de la fréquentation WiFi transforme votre infrastructure sans fil existante en un système de mesure continu à l'échelle du site. En capturant passivement les requêtes de sondage 802.11 des appareils des visiteurs, en traitant les signaux RSSI sur plusieurs points d'accès et en appliquant l'anonymisation et l'agrégation au niveau de la couche d'analyse, les opérateurs obtiennent des comptages précis de visiteurs uniques, le temps de présence par zone, les distributions des heures de pointe et les taux de visites répétées — le tout sans exiger que les visiteurs se connectent activement au réseau.
Pour un CTO évaluant cette capacité, les points de décision clés sont : les exigences de précision (le WiFi standard offre une précision de 5 à 10 m ; une augmentation BLE ou UWB est nécessaire pour les cas d'utilisation sub-mètre), la posture de conformité à la confidentialité (le GDPR impose l'anonymisation en périphérie et des flux de consentement transparents), et la profondeur d'intégration (le ROI le plus élevé provient de la liaison des données de fréquentation anonymes aux profils d'utilisateurs authentifiés via une plateforme Guest WiFi ). La plateforme WiFi Analytics de Purple gère les trois couches dès la sortie de la boîte, couvrant les déploiements dans le Commerce de Détail , l' Hôtellerie , la Santé et le Transport . Pour une introduction plus large à la discipline de l'analyse, consultez Qu'est-ce que l'analyse WiFi ? Un guide complet .
Approfondissement Technique
Comment fonctionne l'analyse de la fréquentation WiFi
Le fondement de l'analyse de la fréquentation WiFi est le mécanisme de requête de sondage IEEE 802.11. Lorsque la radio WiFi d'un appareil est active — que l'utilisateur soit connecté ou non à un réseau — l'appareil diffuse des requêtes de sondage pour découvrir les SSID disponibles. Ces trames contiennent l'adresse MAC de l'appareil, un horodatage et les débits de données pris en charge. Les points d'accès de votre site reçoivent passivement ces trames et les transmettent, ainsi que la valeur RSSI mesurée, à un moteur d'analyse centralisé.
Le moteur d'analyse effectue quatre opérations principales. Premièrement, la détection d'appareils : chaque adresse MAC unique observée dans une fenêtre de temps configurable est comptée comme une présence de visiteur distincte. Deuxièmement, le positionnement : en comparant les valeurs RSSI de plusieurs points d'accès ayant entendu la même sonde, le moteur applique des algorithmes de trilatération ou d'empreinte digitale pour estimer l'emplacement de l'appareil sur le plan d'étage, généralement à 5–10 mètres près pour les déploiements 802.11ac/ax standard. Troisièmement, le calcul du temps de présence : le moteur suit la première et la dernière observation de sonde pour chaque appareil au sein d'une session, calculant la durée de présence par zone. Quatrièmement, l'anonymisation : les adresses MAC sont hachées de manière unidirectionnelle à l'aide de SHA-256 ou équivalent avant de quitter la périphérie, garantissant qu'aucune information personnellement identifiable n'est transmise ou stockée dans la couche d'analyse cloud.
La randomisation MAC et son impact
Un défi technique critique pour tout déploiement d'analyse WiFi est la randomisation des adresses MAC. Depuis iOS 14 (2020) et Android 10 (2019), les systèmes d'exploitation mobiles randomisent l'adresse MAC utilisée dans les requêtes de sondage par réseau ou par session. Cela signifie qu'un seul appareil physique peut apparaître sous plusieurs adresses MAC distinctes au fil du temps, gonflant artificiellement les comptages bruts de fréquentation de 20 à 40 % si cela n'est pas corrigé.
Les plateformes d'analyse matures abordent ce problème par plusieurs mécanismes : le regroupement temporel (groupement des rafales de sondes provenant du même emplacement physique dans une courte fenêtre), l'empreinte digitale du signal (mise en correspondance des profils RSSI sur les points d'accès pour identifier la continuité probable de l'appareil), et la liaison de session authentifiée (lorsqu'un utilisateur se connecte via un portail captif Guest WiFi , la MAC de la session authentifiée est liée à l'historique des sondes, fournissant une ancre de déduplication de vérité terrain). Pour un examen plus approfondi de la façon dont les technologies de positionnement interagissent avec ces défis, consultez le Guide des systèmes de positionnement intérieur : UWB, BLE et WiFi .
Architecture des données et conformité aux normes
Une architecture d'analyse de la fréquentation WiFi de qualité production s'étend sur trois niveaux. Le niveau périphérique se compose des points d'accès eux-mêmes, exécutant un micrologiciel capable de capturer les trames de sondage et d'effectuer un hachage local. Le niveau d'agrégation est un moteur d'analyse cloud ou sur site qui ingère les événements de sondage hachés, applique la déduplication et calcule les métriques. Le niveau de présentation est le tableau de bord BI et la couche API qui affiche les KPI aux équipes d'opérations et alimente les systèmes en aval tels que le CRM, la gestion de la main-d'œuvre et l'affichage numérique.
Du point de vue des normes, le déploiement doit prendre en compte : IEEE 802.1X pour l'accès réseau authentifié (pertinent lors de la liaison des données de fréquentation aux sessions d'utilisateurs connus), WPA3 pour le chiffrement sans fil des sessions authentifiées, l'Article 5 du GDPR (minimisation des données et limitation de la finalité — ne collectez que ce dont vous avez besoin, pour la finalité déclarée), et PCI DSS si le réseau transporte des données de cartes de paiement en plus du trafic d'analyse (la segmentation du réseau via des VLAN est obligatoire dans ce cas).
Guide d'Implémentation
Étape 1 : Étude de site RF et placement des points d'accès
Une analyse précise de la fréquentation commence par une étude de site RF professionnelle. L'objectif n'est pas seulement la couverture — c'est la résolution de localisation. Pour que la trilatération fonctionne, chaque point du plan d'étage doit être à portée d'au moins trois points d'accès avec des lectures RSSI distinctes. En règle générale, déployez les points d'accès à une densité d'un pour 150 à 200 mètres carrés dans les environnements ouverts, en réduisant à un pour 80 à 100 mètrmètres dans les zones avec des interférences RF importantes (cuisines, salles de serveurs, étagères denses). Utilisez des outils de planification RF prédictive pour modéliser la propagation du signal avant l'installation physique.
Étape 2 : Configuration du micrologiciel et de la capture de sondes
Activez la capture des requêtes de sondes sur le micrologiciel de vos points d'accès. La plupart des fournisseurs de niveau entreprise (Cisco, Aruba, Ruckus, Meraki) prennent en charge cette fonctionnalité nativement via leurs API de services de localisation. Configurez l'intervalle de capture — généralement des fenêtres d'agrégation de 30 secondes équilibrent la granularité et le volume de données. Assurez-vous que le hachage MAC est effectué sur l'appareil ou sur le contrôleur local avant que toute donnée ne quitte la limite du site. C'est une exigence stricte pour la conformité GDPR.
Étape 3 : Déploiement du moteur d'analyse
Connectez vos points d'accès ou votre contrôleur à la plateforme d'analyse via un point de terminaison API sécurisé HTTPS/TLS 1.3. Configurez la cartographie des plans d'étage en téléchargeant les dessins CAO ou architecturaux de votre site et en calibrant le système de coordonnées par rapport aux positions connues des points d'accès. Définissez des zones — des zones logiques du plan d'étage (hall d'entrée, aire de restauration, commerce de détail Zone A, etc.) — qui seront utilisées comme unité d'analyse pour le temps de présence et les rapports de fréquentation.
Étape 4 : Intégration du Guest WiFi
Déployez un portail captif Guest WiFi pour permettre la transition des données de sondes anonymes vers des profils de visiteurs authentifiés. La page d'accueil doit présenter un avis de consentement clair, conforme au GDPR, expliquant quelles données sont collectées et comment elles seront utilisées. Proposez une connexion sociale, une inscription par e-mail ou une authentification basée sur OpenRoaming. Chaque session authentifiée fournit un identifiant stable que le moteur d'analyse utilise pour ancrer la déduplication et enrichir les enregistrements de fréquentation avec des données démographiques et de préférences.
Étape 5 : Configuration du tableau de bord et des alertes
Configurez votre tableau de bord WiFi Analytics avec les KPI pertinents pour votre type de site. Mettez en place des alertes automatisées pour les dépassements de seuil — par exemple, une alerte en temps réel lorsque la fréquentation dans une zone spécifique dépasse 80 % de la capacité maximale historique, déclenchant une réponse de déploiement du personnel. Planifiez des rapports hebdomadaires et mensuels pour distribution aux gestionnaires de site et au conseil d'administration des opérations.
Bonnes pratiques
Les pratiques suivantes reflètent l'expérience de déploiement sur des milliers de sites et s'alignent sur les directives IEEE, GDPR et PCI DSS.
Confidentialité dès la conception : Anonymisez les adresses MAC en périphérie, pas dans le cloud. C'est à la fois une exigence GDPR et une mesure pratique de minimisation des données. Ne stockez jamais d'adresses MAC brutes dans votre base de données analytique.
Établir une base de référence avant d'optimiser : Exécutez la plateforme d'analyse en mode d'observation passive pendant un minimum de quatre semaines avant d'apporter des modifications opérationnelles. Vous avez besoin d'une base de référence statistiquement valide — tenant compte des variations journalières, des schémas saisonniers et des anomalies liées aux événements — avant qu'une métrique ne devienne exploitable.
Granularité des zones : Définissez les zones au niveau de la prise de décision opérationnelle, et non au niveau de la capacité technique. Si votre équipe d'opérations ne peut pas agir sur des données de sous-zones, la création de 50 micro-zones ajoute de la complexité sans valeur. Commencez avec 5 à 10 zones significatives et développez-vous à mesure que la maturité analytique de l'équipe augmente.
Normalisation multi-sites : Lors de la comparaison de la fréquentation entre les sites, normalisez par la taille du site (visiteurs par 100 m²) et les heures d'ouverture. Les chiffres bruts de visiteurs sont trompeurs lors de la comparaison d'un dépanneur de 500 m² à un grand magasin de 5 000 m².
Intégrer des données externes : Les données de fréquentation WiFi acquièrent une puissance analytique significative lorsqu'elles sont corrélées avec des ensembles de données externes — météo, calendriers d'événements locaux, perturbations des transports publics et calendriers de campagnes promotionnelles. Cette corrélation est ce qui distingue un système de comptage d'une véritable capacité de business intelligence.
Dépannage et atténuation des risques
| Mode de défaillance | Cause première | Atténuation |
|---|---|---|
| Fréquentation 30–50 % plus élevée que les comptages manuels | Randomisation MAC non gérée | Mettre en œuvre le regroupement temporel et encourager les sessions WiFi authentifiées |
| Précision de localisation médiocre (erreur >15 m) | Densité de points d'accès insuffisante ou mauvais placement | Effectuer une étude de site RF ; augmenter la densité de points d'accès dans les zones problématiques |
| Données manquantes de zones spécifiques | Micrologiciel AP non configuré pour la capture de sondes | Auditer les versions du micrologiciel AP ; activer les services de localisation sur tous les points d'accès |
| Échec de l'audit GDPR | Adresses MAC brutes stockées dans le cloud | Appliquer le hachage en périphérie ; effectuer des audits trimestriels des flux de données |
| Latence du tableau de bord >5 minutes | Moteur d'analyse sous-provisionné | Mettre à l'échelle la couche de calcul ; implémenter la pré-agrégation en périphérie |
| Taux d'authentification WiFi faible (<20 %) | Mauvaise UX de la page d'accueil ou portail captif lent | Tester A/B les conceptions de pages d'accueil ; optimiser le temps de chargement du portail à <2 secondes |
ROI et impact commercial
Le ROI de l'analyse de la fréquentation WiFi se matérialise à travers trois catégories : l'efficacité opérationnelle, l'optimisation des revenus et la planification des capitaux.
Du côté opérationnel, les données des heures de pointe permettent une planification précise du personnel. Une chaîne de magasins de détail régionale qui passe de plannings de personnel fixes à une planification axée sur la demande basée sur les données de fréquentation WiFi réalise généralement une réduction de 12 à 18 % des coûts de main-d'œuvre par visiteur servi, tout en améliorant simultanément les scores de satisfaction client en réduisant les temps d'attente pendant les périodes de pointe.
Du côté des revenus, les données de temps de présence sont un indicateur direct de l'intention d'achat. Les zones à forte fréquentation mais à faible temps de présence indiquent un problème de navigation ou de merchandising — les visiteurs passent sans s'arrêter. Corriger cela par des changements d'aménagement ou une signalisation numérique ciblée peut augmenter les taux de conversion de 8 à 15 % dans les zones affectées. De plus, les profils de visiteurs authentifiés générés via Guest WiFi permettent la monétisation des médias de détail sur le captivla page d'accueil du portail, créant une nouvelle source de revenus grâce à l'inventaire publicitaire.
Du côté de la planification des capitaux, l'analyse comparative de la fréquentation multi-sites fournit la base de preuves pour les décisions relatives au portefeuille immobilier. Quels emplacements sous-performent par rapport à leur potentiel de zone de chalandise ? Quels sites justifient un investissement de rénovation ? L'analyse WiFi fournit la mesure continue et objective que les compteurs de fréquentation manuels et les enquêtes périodiques ne peuvent pas offrir.
Pour comprendre comment ces principes s'étendent aux environnements de véhicules connectés et de transport, consultez Wi-Fi in Auto: The Complete 2026 Enterprise Guide et Internet of Things Architecture: A Complete Guide .
Termes clés et définitions
Probe Request
A management frame broadcast by any 802.11 WiFi-enabled device to discover available networks. Contains the device MAC address, supported data rates, and optionally a target SSID. The primary raw data source for passive WiFi footfall analytics.
IT teams encounter this when configuring AP firmware for location services. Understanding probe request behaviour — including the impact of MAC randomisation on probe frame MAC addresses — is essential for accurate footfall counting.
RSSI (Received Signal Strength Indicator)
A measurement of the power level of a received radio signal, expressed in dBm (typically ranging from -30 dBm at close range to -90 dBm at the edge of coverage). Used in WiFi footfall analytics to estimate the distance between a device and each access point, enabling trilateration-based positioning.
RSSI-based positioning is inherently noisy due to multipath interference, building materials, and human body absorption. IT teams should understand that RSSI accuracy degrades in environments with dense RF interference, and plan AP density accordingly.
MAC Address Randomisation
A privacy feature implemented in iOS 14+, Android 10+, and Windows 10+ that causes devices to use a randomly generated MAC address in probe requests rather than the device's permanent hardware MAC address. Designed to prevent passive tracking of individuals across venues.
The single biggest technical challenge for WiFi footfall analytics deployments post-2020. IT teams must ensure their chosen analytics platform implements deduplication heuristics to correct for randomised MACs, or footfall counts will be significantly overstated.
Dwell Time
The duration of a visitor's presence within a defined zone or venue, calculated as the time elapsed between the first and last probe request observation for a given device identifier within a session. Typically expressed as an average across all visitors in a reporting period.
Dwell time is one of the highest-value metrics in WiFi analytics. In retail, it correlates strongly with purchase probability. In hospitality, it measures guest engagement with F&B and leisure facilities. Operations teams use it to evaluate the effectiveness of layout changes and promotional activations.
Trilateration
A positioning technique that estimates a device's location by measuring its distance from three or more known reference points (access points), using signal strength (RSSI) or time-of-flight measurements. Distinct from triangulation, which uses angles rather than distances.
The positioning algorithm underpinning zone-level WiFi footfall analytics. IT teams should understand that trilateration accuracy is constrained by AP density, RF environment quality, and the precision of RSSI measurements. For higher accuracy, consider augmenting with BLE beacons or UWB anchors.
Captive Portal
A web page presented to users before they are granted access to a WiFi network, typically requiring authentication (social login, email registration, or voucher code) and consent to terms of service. In WiFi analytics, the captive portal is the mechanism that transitions anonymous probe data to authenticated user profiles.
The captive portal is the primary data collection point for GDPR-compliant first-party data capture. IT teams must ensure the portal presents a clear, granular consent notice and that the consent record is stored with a timestamp and linked to the user's profile.
Footfall Capture Rate
The percentage of pedestrians passing a venue's entrance who actually enter, calculated by dividing authenticated or detected in-venue visitors by the external pedestrian count from a street-level sensor or camera system. A key retail performance metric.
Capture rate requires an external pedestrian count data source in addition to WiFi analytics. IT teams deploying in retail environments should plan for integration between the WiFi analytics platform and entrance camera or infrared counter systems to enable capture rate calculation.
Return Visit Rate
The percentage of unique visitors who return to the venue within a defined time window (commonly 7, 30, or 90 days), calculated by matching device identifiers across sessions. Requires either stable MAC addresses (increasingly rare) or authenticated user session matching.
Return visit rate is a loyalty metric that WiFi analytics platforms can calculate at scale without requiring a formal loyalty programme. However, MAC randomisation significantly impacts accuracy for unauthenticated visitors. Authenticated Guest WiFi sessions provide the most reliable return rate data.
Zone
A named, bounded area of a venue floor plan defined within the analytics platform, used as the unit of analysis for footfall and dwell time reporting. Zones are mapped to physical coordinates on the floor plan and assigned to one or more access points.
Zone design is an operational decision, not a technical one. IT teams should work with venue operations managers to define zones that map to actionable business decisions — not the maximum granularity the technology supports. Over-granular zone definitions create analytical noise without operational value.
Études de cas
A 120-property hotel group wants to use WiFi footfall analytics to optimise lobby staffing and F&B outlet opening hours. Their existing Cisco Meraki infrastructure covers all public areas. How should they approach the deployment?
The deployment should proceed in four phases. Phase 1 (Weeks 1–2): Enable Cisco Meraki location services API on all MR series APs across the estate. Configure probe capture with a 30-second aggregation interval. Map all public-area floor plans into the analytics platform, defining zones for: main lobby, check-in desk area, restaurant entrance, bar, gym, and pool. Phase 2 (Weeks 3–6): Run in passive observation mode to establish baseline footfall patterns by hour, day, and property. Identify the peak check-in window (typically 14:00–18:00) and the F&B peak (19:00–21:00) with statistical confidence. Phase 3 (Week 7): Deploy the Guest WiFi captive portal with GDPR-compliant consent, offering social login and email registration. This transitions anonymous probe data to authenticated profiles, enabling return-visit tracking and guest preference capture. Phase 4 (Week 8 onwards): Configure automated staffing alerts — when lobby footfall exceeds 85% of the 90th-percentile historical peak, trigger a notification to the duty manager to deploy additional check-in staff. Set F&B outlet opening hours dynamically based on the previous four weeks' footfall data for that day of week. Integrate the analytics API with the property management system to correlate footfall with RevPAR and F&B revenue per cover.
A 12-store fashion retail chain is evaluating WiFi footfall analytics to benchmark store performance and identify which locations are candidates for lease renegotiation. Their stores use a mix of Aruba and Ruckus APs. What is the recommended implementation approach, and what metrics should they prioritise?
Given the mixed-vendor environment, the recommended approach is to use a vendor-neutral analytics platform that ingests probe data via a standardised API from both Aruba Central and Ruckus SmartZone controllers. Step 1: Audit AP firmware versions across all 12 stores and ensure location services are enabled. Step 2: Define a consistent zone taxonomy across all stores — entrance zone, front-of-store, mid-store, fitting rooms, till area — to enable like-for-like comparison. Step 3: Establish a normalised footfall metric: unique visitors per 100 m² of trading floor per operating hour. This removes the distortion caused by different store sizes and opening hours. Step 4: Track four primary KPIs: (a) Capture Rate — the percentage of pedestrians passing the store entrance who enter (requires an external pedestrian count feed or entrance-zone WiFi data); (b) Dwell Time — average minutes per visit, segmented by zone; (c) Conversion Proximity — the percentage of visitors who reach the till area (a proxy for purchase intent); (d) Return Rate — the percentage of visitors who return within 30 days. Step 5: After 90 days of data, rank stores by normalised footfall and dwell time. Stores in the bottom quartile on both metrics, in locations with strong external pedestrian counts, are candidates for lease renegotiation or format change rather than closure.
Analyse de scénario
Q1. You are the IT Director for a 25-site quick-service restaurant chain. The operations team wants to use WiFi data to optimise kitchen staffing in real time. Your current AP estate is a mix of consumer-grade routers installed by individual franchisees. What are the three most critical infrastructure decisions you need to make before the analytics project can proceed?
💡 Astuce :Consider the gap between consumer-grade and enterprise-grade AP capabilities, the need for centralised management, and the data privacy implications of collecting location data in a food service environment.
Afficher l'approche recommandée
The three critical decisions are: (1) AP estate standardisation — consumer-grade routers do not support probe request capture APIs or centralised location services. You must mandate a migration to enterprise-grade APs (e.g., Cisco Meraki, Aruba Instant-On, or equivalent) across all 25 sites before analytics deployment is feasible. Budget for this as a prerequisite capital project. (2) Centralised controller or cloud management — with 25 sites and multiple franchisees, you need a single cloud management platform that aggregates probe data from all sites into one analytics engine. Decentralised management makes cross-site benchmarking impossible. (3) GDPR and data governance framework — collecting location data in a public food service environment requires a clear legal basis (legitimate interests assessment is the most appropriate basis for anonymous footfall analytics), a privacy notice update, and a data retention policy. Franchisees are likely joint data controllers, which requires a formal data sharing agreement. Without this framework, the project carries regulatory risk that outweighs the operational benefit.
Q2. A stadium operator has deployed WiFi footfall analytics across a 60,000-capacity venue. After three months, the analytics platform reports an average of 85,000 unique devices per event — significantly higher than the ticket sales figure. The vendor claims the data is accurate. What is the most likely technical explanation, and how would you validate it?
💡 Astuce :Think about the multiple sources of device signals in a dense stadium environment and the specific challenges of MAC randomisation in high-density settings.
Afficher l'approche recommandée
The most likely explanation is a combination of three factors: (1) MAC randomisation inflation — in a dense environment with 60,000 people, each person's device may generate multiple distinct randomised MAC addresses over a 3-hour event, each counted as a unique device. Without robust temporal clustering and session stitching, this alone can inflate counts by 30–50%. (2) Multiple devices per person — stadium attendees frequently carry smartphones, smartwatches, and tablets simultaneously, each generating independent probe streams. (3) External device bleed — in an urban stadium, probe requests from devices in adjacent streets, car parks, and public transport may be captured by perimeter APs. To validate, run a controlled calibration event: sell exactly 1,000 tickets to a section of the venue, count the physical attendees manually, and compare against the WiFi count for that section's APs only. If the WiFi count exceeds 1,000 by more than 20%, the deduplication algorithm requires tuning. The vendor should be able to demonstrate their MAC randomisation handling methodology and provide calibration data from comparable dense-venue deployments.
Q3. A regional shopping centre operator wants to use WiFi footfall analytics to provide tenant retailers with monthly performance reports, benchmarking each store's dwell time and footfall against the centre average. The legal team has raised concerns about sharing this data with third-party tenants. How do you structure the data sharing to address these concerns while still delivering value to tenants?
💡 Astuce :Consider the difference between sharing raw data and sharing aggregated, anonymised benchmarks, and the contractual framework needed for legitimate data sharing with tenants.
Afficher l'approche recommandée
The legal concern is valid but manageable with the right data architecture. The solution has three components: (1) Aggregation threshold — never share data for any reporting period where the visitor count for a specific zone falls below 50 unique devices. This prevents re-identification of individuals from small-sample datasets and is consistent with GDPR anonymisation guidance from the ICO and EDPB. (2) Relative benchmarking only — share each tenant's metrics as an index relative to the centre average (e.g., 'your dwell time is 18% above the centre average for comparable retail categories'), not as absolute counts. This prevents tenants from inferring competitor performance from the benchmark data. (3) Contractual framework — include a data sharing clause in the tenant lease agreement that specifies: the legal basis for sharing (legitimate interests of the centre operator and tenant for performance management), the data categories shared (aggregated, anonymised footfall and dwell time indices), the retention period, and the prohibition on tenants attempting to re-identify individuals. With this structure, the data sharing is both legally defensible and commercially valuable.
