In what follows we will provide answers to the most pressing topics around privacy, security, GDPR and the likes... This information is updated regularly to reflect our views, current efforts and roadmap related to these matters.
We acknowledge that location data is sensitive data, so we take privacy very seriously. The location domain we are working in has historically been run by ad tech companies collecting and monetizing location data in a lack of a 'privacy by design' mindset. It is our ambition and daily behaviour to tackle these matters differently.
It all starts with being as open and transparent about it. Hence some FAQ answered below. In case you have additional questions for us, feel free to get in contact via email@example.com.
Our goal is to help our publisher customers build great product experiences with location context, whether that is via personalized content or relevant advertising. We do not sell any data we collect, and we do not share location data across customers.
We do however have a 'insights sharing partnership' which aggregates the data of end users over different customers to give an aggregated overview of real-world behavioural patterns of end-users. This helps brands to better understand their audiences and improve their services consequently. No personal data is ever shared and our clustering algorithms require at least 50 users.
We initially collect data about the user such as his adid, consent state and location permission. Once tracking starts - for opt-inned users with location permissions enabled - we collect location data. Depending on several optimisation settings, our algorithms collect multiple data points per hour. The data collected contains latitude & longitude (coordinate), the adid, a timestamp, the OS (Android vs iOS), OS version (e.g. iOS 13.3.1), device manufacturer (e.g. iPhone or Samsung), device id (e.g. A500), cellular network (e.g. Proximus) and wifi network (in case of a connection with a network).
Multiple data points are directly used for matching users (when and where), others are used to optimize the tracking (e.g. battery optimisation for specific device types) or improve the probability of a visit (e.g. a wifi connection to 'Quick' indicated a potential visit to Quick).
The data we collect for our customers are considered first party data. We are a processor for their data and do not sell any data we collect. We do not share location data across customers either. Our customers are bound to the laws of the GDPR and can only use the personal data for its intended use cases to whom a user consents. We track and store consent in our systems with revisioning tracking in order to have a clear understanding of the rights granted.
We never track users without their explicit consent. The tracking only starts once consent has been provided - whether that is via our automated flow or the custom integration by our customers. An example of our consent flow is outlined below. A similar flow is used for Android and increasingly so since Android 10 (location permissions can be granted on a temporary, in-app or always basis).
We have an extensive list of procedures to handle the rights of the end-users we track. We summarize briefly our approach:
Whilst matching & profiling users, coordinates are compared with a blacklist of sensitive locations. If a user is considered to have visited a hospital, a church, a political party's or trade union's headquarter, that match is never stored in our systems.
On top of that, if a customer wants to create a (temporary) point of interest that is located where our blacklist holds a location, this POI is never stored. This practice helps us to avoid profiling users based on locations that are considered to provide insights on a user's political or sexual preferences or health state.
We make a distinction between storing the raw data we collect (e.g. coordinates) and storing the resulting processed data (e.g. matches). Raw data collection is stored for a shorter period of time, depending on the customer his expectations (between 30 days and 1 year). Processed data is stored for a period of 3 years.
We believe every company should act by a 'privacy by design' standard. On top of that, we have some personal beliefs that we value in such a matter that we made sure our algorithms will never profile users in specific audiences that we deem non-ethical. E.g. when a user visits a casino, we will not store this information so betting offices can not target users this way.
We have taken different measures to protect the data we collect, process and store by following best practices in terms of procedures - both administrative and physical (no computers can be left unlocked), encryption (HMAC), authentication of users (via OAuth), limit data transfer (once or twice a day on average), limitation of data access (even our CEO and DPO have no access!), limitation of trusted sources (via IP targeting or VPN access), limiting risks by implementing TFA (two factor authentication), SSO solutions (SAML 2.0) or by de-constructing data and storing it separated (e.g. home locations are stored separated from a user's adid). We even plan further steps in anonymisation and further encryption of all data collected & processed.
The raw data (coordinates) is stored in Big Query which has extensive encryption in place by default. Other data is stored with a user token instead of the ad id making it harder to connect the dots in case of a breach or similar. Additionally, we have plans to further encrypt all data end-to-end.
For authentication we use HMAC - considered one of the best authentication algorithms existing to date - for our SDK-API connections. Increasingly we are limiting the use of the API to IP addresses, using VPN or the SDK to specific apps. All traffic is end-to-end encrypted over SSL/TLS.
Our DPO is Tim De Bock, working as a legal consultant at Deloitte Belgium. He can be reached via firstname.lastname@example.org.