Quelles données les SDK publicitaires recueillent-ils ?

L’essor de la publicité sur mobile, dont le marché représentera en 2018 plus de 50 % du marché publicitaire en ligne français, selon l’Observatoire de l’e-Publicité du SRI, a permis le développement de plusieurs sociétés adtech spécialisées, avec des positionnements très différents, comme l’adserver Smart, le spécialiste du ciblage sur mobile Ogury, la régie mobile Madvertise, ou encore la société de drive-to-store Vectaury. Pour tenir leurs promesses aux annonceurs d’un meilleur ciblage des consommateurs et aux éditeurs d’une meilleure monétisation de leurs inventaires, ces acteurs ont besoin de recueillir des données sur les mobinautes (géolocalisation, état du réseau…) via les SDK qu’ils installent dans les applications mobiles à large audience.

Depuis quelques mois, l’association Exodus Privacy recense les traqueurs installés dans plusieurs centaines d’applications Android, le système d’exploitation présent dans près de 9 smartphones sur 10 dans le monde (voir la méthodologie et les biais possibles en encadré). Il ressort que les acteurs spécialisés français ont installé leur traqueur dans 53 applications d’éditeurs en moyenne, avec de fortes disparités : dans 3 applications pour TeleQuid à 133 pour Smart, en passant par 28 pour Teemo (voir graphique ci-dessous). Pourquoi ces sociétés ont-elles besoin d’un SDK ? Quels types de données ces outils recueillent-ils ? Existe-t-il des alternatives aux SDK ?
 

 

Pourquoi s’appuyer sur un SDK ?

Intégrer un nouveau SDK dans une application n’est pas un choix aisé pour les éditeurs, qui redoutent notamment le risque de bug et de latence. Pour les convaincre, les sociétés publicitaires doivent souvent leur promettre des revenus suffisamment attractifs. “Une fois le SDK installé, c’est souvent un bras de fer entre la régie et son prestataire, la première attendant du deuxième qu’il lui achète un minimum d’inventaire pour y conserver son SDK”, explique un connaisseur du secteur. Pourquoi se donnent-elles ce mal ? Les raisons diffèrent selon leur positionnement. “Les SDK sont la seule technologie qui récupère la géolocalisation de façon assez récurrente et juste pour mesurer les visites de manière très précise”, justifie la directrice de la société de drive-to-store Teemo, Alexandra Chiaramonti.

Paul Amsellem, fondateur de la régie mobile Madvertise, qui diffuse des publicités display, native et vidéo, explique que “ce morceau de code nous permet d’aller chercher sur un adserver la publicité qui correspondra à la cible et au support”. Pour Stéphane Ruffin, directeur produit de l’adserver Smart, “intégrer notre SDK dans l’application des éditeurs avec lesquels nous travaillons est l’assurance que la diffusion de la publicité sera optimale”.

Pour faciliter l’intégration des SDK, certains éditeurs ont recours à des méta-SDK, comme celui de Madvertise. “Notre SDK encapsule des SDK tiers, comme Smart, Google DBM, AppNexus ou AppsFlyer, ce qui fait gagner du temps d’intégration aux éditeurs. Nous pouvons les activer à distance et gérer leur niveau de priorité dans l’enchère selon les spécificités de monétisation d’une application, après une période de test de 15 jours. Ce sont les éditeurs qui choisissent quels SDK seront activés dans leur application”, explique Paul Amsellem.

Quelles permissions pour quels usages ?

Pour tenir leurs promesses, ces SDK publicitaires ont besoin de récolter des informations très précises. Mais les applications où ils sont installés doivent demander au préalable la permission des utilisateurs. Et l’obligation deviendra encore plus saillante avec l’entrée en vigueur du RGPD fin mai 2018. Il existe une quarantaine de permissions considérées comme “normales” par Android, dont l’acceptation se fait lors du téléchargement de l’application, et une trentaine considérées comme “dangereuses” (la liste de toutes les permissions). Une permission est considérée comme dangereuse si elle implique d’accéder à des informations ou des fonctionnalités qui peuvent porter atteinte à la vie privée de l’utilisateur, ou qui peuvent affecter les données stockées dans le téléphone ou l’activité d’autres applications. Ce type de permission requiert le consentement explicite de l’utilisateur non seulement lors du téléchargement de l’application, mais aussi lors de son déclenchement.

Les permissions dangereuses sont classées en neuf grandes catégories : calendrier (lire les informations du calendrier et en ajouter), appareil photo (accéder à l’appareil photo), contacts (lire les contacts, en ajouter, et recueillir les informations), géolocalisation (approximative et précise), microphone (enregistrer les sons environnants), téléphone (dont passer un appel, répondre à un appel, lire les numéros de téléphone), capteurs (accéder aux données des capteurs que les utilisateurs utilisent pour mesurer des choses comme leur rythme cardiaque), SMS (dont envoyer, recevoir, lire un SMS…) et stockage (lire et écrire dans le stockage externe). Certaines sociétés, comme Smart et Madvertise, indiquent dans leurs documentations respectives (ici pour Smart et ici pour Madvertise) que certaines permissions sont indispensables à leur fonctionnement et d’autres optionnelles. Cela signifie que les développeurs d’applications sont libres d’intégrer ou non ces dernières (voir notre tableau qui accompagne cet article).

La permission “internet”, demandée par tous les acteurs, permet à l’application de communiquer avec un serveur. La permission “Etat du réseau” permet aux prestataires qui la demandent (Smart, Ogury) de connaître la bande passante dont dispose le téléphone. “La création sera plus ou moins lourde selon que le mobinaute soit en 3G, en 4G ou sur le wifi”, explique Erwan Aullas, ingénieur logiciel mobile chez Smart. Pour les éditeurs d’applications qui utilisent le SDK de Madvertise, les géolocalisations fine et approximative sont en option.

“Cela leur permet de diffuser une publicité plus ciblée, et des créations adaptées à la localisation”, explique Paul Amsellem. Et donc de générer de meilleurs CPM. Avec la permission “Receive boot completed”, Ogury est informé du lancement de l’application. Et “Get Account” lui permet d’entraîner ses algorithmes à définir le sexe et l’âge d’un internaute en repérant les adresses emails composés d’un prénom et d’une date de naissance. “Cette permission est optionnelle. Lorsqu’elle est demandée par certaines applications avec lesquelles nous travaillons, les adresses email sont détruites dans les 24 heures et ne sont jamais stockées”, affirme Ogury.

A l’exception d’Ogury, tous les acteurs dont mind Media a obtenu la liste de permissions requièrent de façon optionnelle ou obligatoire la géolocalisation approximative (via les données envoyées par le réseau mobile par exemple) ou fine (combinaison d’informations issues de la puce GPS du téléphone, de la triangulation du réseau cellulaire et de l’emplacement des bornes wifi les plus proches). C’est particulièrement le cas des acteurs du drive-to-store, comme Teemo et FidZup. Vanessa Bourdillon, senior demand sales manager UK & France de Fyber, affirmait lors de la conférence ATS Paris, fin mars, que “les CPM des éditeurs peuvent doubler lorsqu’ils fournissent la géolocalisation de leurs utilisateurs, car c’est une donnée très demandée par les annonceurs”.

Note : Seules les permissions requises par Smart et Madvertise sont publiées en ligne dans leurs documentations respectives. Pour Teemo et Ogury, il s’agit de déclaratifs. Les permissions de FidZup et Adotmob sont des informations de mind Media. Sollicités par mind Media, les acteurs spécialisés Ad4Screen, Vectaury, TeleQuid et Kairos n’ont pas donné suite à nos demandes d’interviews.

Les alternatives aux SDK

Toutes les sociétés de publicité mobile n’ont pas besoin d’un SDK. S4M et Admoov se contentent par exemple d’écouter les bid requests (appels d’enchères par un vendeur en programmatique) pour recueillir, notamment, des identifiants publicitaires. Kairos Fire, de son côté, s’appuie sur un réseau de boîtiers beacons installés en magasin pour mesurer leur trafic. La société de mesure des performances des campagnes de drive-to-store Retency n’a pas de relation directe avec les éditeurs d’applications. Son code est embarqué par les régies mobiles Madvertise et Mobvalue dans leurs propres SDK afin d’offrir cette option à leurs clients annonceurs.

Le dispositif de Retency consiste à implanter dans les mobiliers publicitaires des boîtiers permettant de collecter, via le protocole WiFi, les adresses MAC des appareils des personnes passant à proximité, puis d’anonymiser ces données afin de les restituer sous forme de graphes de flux de passage. Même l’adserver Smart travaille parfois sans SDK. “Certains éditeurs créent leur propre brique publicitaire, puis se branchent à nos serveurs via une API pour récupérer les formats qu’ils diffusent eux-mêmes. Ce cas de figure est très rare car cela implique par exemple qu’ils gèrent l’affichage publicitaire et maîtrisent les normes MRAID et VAST”, explique Stéphane Ruffin. En outre, les acteurs du retargeting, comme Ogury, et du drive-to-store, comme Teemo et SingleSpot, peuvent se contenter d’écouter les bid requests côté DSP pour identifier leurs cibles.