All in all considered, the field accuracy of a contact tracing system based on an app leveraging BLE and voluntarily adoption, is affected by different factors.

We've created our math model that takes into account the most relevant limitations. We'll disclose some result in the next page.

Only 43% of people would install the app

Download and install are big frictions. Local government will sponsor the adoption of the app and incentives could be roll out to foster it even more. We assume that the likelihood to install the app would be as equal as the trust in the government. The OECD account that globally only 43% of citizens trust their government (2015). So we expect that 57% of citizens wouldn’t install the app.

To let the app work, the smartphone must prompt the user to explicitly allow using fine location services. Yes, even if we are not really geo-locating the device, the app potentially could do it. So it requires this scary and contradictory permission to access the Bluetooth hardware. In our experience, on average, every permission request could cost about 10% of the user base, and we acknowledge that 43% could be quite optimistic.

iOS speaks iBeacon but can only hear Eddystone

There are two prominent BLE beacon profiles, Google's Eddystone and Apple's iBeacon. While Andorid smartphones can broadcast and scan both of them, iOS comes with a hard limitation (we didn't find a workaround for it) in which it cannot receive iBeacons advertisement packet. This only affects unknown devices (not paired) but it represents exactly our use case. iOS can only broadcast iBeacon and receive Eddystone.

Assuming the global quotas of the two operating systems is 25% iOS / 75% Android, it means that 25% of the population will be unable to detect other iOS users presence.

App foreground vs background,
and phone idle

Android and iOS policies prevent the use of some essential BLE features when an app is not running in foreground. Here is a glimpse at Android scanning limits. iOS totally blocks the scanning of unknown advertisement signals.

We've seen in our model that overcoming this limitation will boost dramatically the effectiveness of the app.

Average contact time vs scan frequency

When an Android app goes to the background or phone is in idle mode, BLE scans happen on average every 15 minutes. That means we can potentially lose contacts (between 2 people with the app in one of such states) if those contacts last less than 15 minutes (the scan frequency).

This limitation is less important as we understand that transmission of the virus is more likely to happen in a longer period of time. However, we will miss entirely brief contacts.