@Bruce we analyzed the data more thoroughly and find out that the decrease is actually caused by MediaTek and Motorola chip vendors, iOS 14 was released in 09/2020 and we didn't notice the decrease till 21.1.2020.
We see the number of raw probe requests drop suddenly starting January 21 to a third of its previous volume. This can be seen happen all at once and across all our stores (over 150 in different countries), please see the chart attached.
Because of the sudden drop across so many venues, this is very unlikely to be a change in the behavior of smartphones or a change in the firmware on Meraki access points (we did not update the firmware everywhere at once). Based on our observation, this must be a change in the way that Meraki Cloud processes incoming probe requests. There is no other way that the change could be so consistent.
Please let us know the concrete changes made on the Meraki platform around that time. Because of the scale of the problem, we need to know exactly how the processing of probe requests changed in order to be able to interpret the data and explain the rapid change to our customers.
Yes, it was how Meraki process the information for Location Analytics that was changed - nothing to do with the client, or the MR firmware.
“Passersby are probing wireless devices detected by a Meraki AP, whose probes and dwell time did not meet the requirements to be considered a visitor. If clients are using randomization techniques, location analytics may be detecting falsified/anonymous client IDs, and this should be considered when analyzing location data.
With some vendors implementing MAC randomization on client devices, we made a change in the way we calculate the Passerby devices in the Location Analytics tool to keep the data accurate. A unique non-randomized MAC address needs to be detected for more than 1 minute interval for the client device to be classified as Passerby. If the device using MAC randomization the MAC address used for probe requests changes multiple times within the 1 minute interval. We will be eliminating these MAC addresses from the Location Analytics computation and the Scanning APIv2 output as well.”
Thank you for the explanation. However, we are still struggling to understand the change with respect to what we see in our data. Could you please clarify the following two points for us:
You say that the change aims to clean the data from devices with MAC randomization, why then require that devices with NON-randomized MAC addresses be detected for more than 1 minute? Wouldn't it be sufficient to only place the condition on devices with randomized addresses and keep all with non-randomized MAC addresses?
Does the minimum 1 minute presence condition also apply to devices with randomized MAC addresses or are all devices with MAC randomization removed from the data?
We see that our recent data contains a large number of devices that are detected for less than 1 minute (see the chart attached) which makes us wonder if the 1 minute condition is actually enforced on devices with non-randomized addresses. We access the data using the Scanning API v2