Mobile : qui installe les SDK publicitaires et pourquoi ?

Certains éditeurs ont découvert à cette occasion la présence dans leurs applications de tiers de monétisation avec lesquels ils nous ont assuré, sous couvert d’anonymat, n’avoir jamais signé de contrat. Sollicitée par mind Media, la présidente d’Exodus Privacy, Esther, indique que “depuis que nous avons changé de méthode de détection, début décembre 2017, aucune société qui est venue vers nous pour contester un rapport n’a été à même de prouver que l’on s’est trompé. Nous fournissons un outil qui permet par exemple aux responsables techniques de vérifier leurs applications avant de les proposer sur Google Play. Il est arrivé qu’un éditeur découvre des SDK publicitaires installés dans le code de base utilisé par le prestataire qui a développé son application.” Mais la présence d’un pisteur ne signifie pas nécessairement qu’il soit actif. “Pour prouver l’activité d’un SDK, il faudrait utiliser l’application de façon intensive et exhaustive, avec des cas d’utilisation spécifiques”, explique Esther. Par ailleurs, certains SDK peuvent échapper à l’analyse d’Exodus en adoptant un procédé d’offuscation, c’est-à-dire d’obscurcissement de leur code. D’ordinaire utilisé pour protéger les investissements de recherche et développement d’un logiciel, certains acteurs de la publicité en ligne y ont parfois recours pour masquer leur identité.

Le rôle des adservers mobiles et des SDK tiers de monétisation

Pour monétiser leurs audiences dans l’univers applicatif, les éditeurs qui disposent de forces commerciales en interne font généralement appel à des adservers mobiles, comme Google DoubleClick, Smart (utilisé par 56 % des applications de notre panel) ou MoPub (Twitter). Un adserver leur permet de délivrer sur des emplacements publicitaires définis des campagnes, lesquelles peuvent avoir été négociées en direct par leurs commerciaux auprès des annonceurs, ou en programmatique (via des deals ID – les acheteurs bénéficient de garanties prédéfinies sur le contexte, la data, l’URL ou le prix -, ou en open auction – l’enchère est proposée aux mêmes conditions à tous les acheteurs). Pour choisir leur adserver, les éditeurs peuvent s’attacher à leur empreinte internationale, les formats qu’ils supportent, ou encore leurs certifications, comme VAST.

A côté de cet adserver primaire, un éditeur peut intégrer un autre SDK de monétisation (adnetworks, plateformes de médiation…), comme AppLovin (utilisé par 42 % des applications de notre panel), Teemo, Ogury ou Sync2Ad. Le groupe Fyber propose par exemple deux plateformes de médiation pour les applications de jeu mobile : Heyzap, spécialisé dans le gaming avec des formats interstitiels in-app, et Fyber, qui diffuse des vidéos “incentivées” (leur visionnage donne droit à une vie en plus par exemple). L’éditeur définit ensuite l’ordre de priorité entre ces acteurs. Par exemple, si Smart n’a pas réussi à trouver une marque prête à payer le prix demandé pour un emplacement donné, l’éditeur fera appel à ce SDK tiers, qui peut apporter une demande complémentaire ou supporter un format particulier. “Quand un éditeur intègre plusieurs SDK de monétisation, cela peut devenir complexe car il doit gérer à chaque fois des intégrations techniques”, note Stéphane Ruffin, directeur produit de Smart.

Des connecteurs pour faciliter l’intégration à l’adserver

Pour faciliter l’intégration de ces SDK, Smart a mis en place des ponts techniques avec eux. “Les éditeurs n’ont plus qu’à pousser la nouvelle librairie de monétisation dans le projet Smart. Ainsi, ils n’ont plus à intégrer tout un SDK. Mais c’est l’éditeur qui garde la relation technique avec le tiers de monétisation. Les connecteurs que nous embarquons peuvent éventuellement faire croire à Exodus la présence d’un SDK tiers et provoquer un faux positif. Mais nous n’avons aucune relation contractuelle avec ces tiers de monétisation, et intégrer leur code à notre SDK alourdirait le nôtre et augmenterait les risques de crash. Nous nous refusons à le faire. Seul l’éditeur peut activer l’acteur tiers de monétisation via notre connecteur”, affirme Stéphane Ruffin.

Illustration avec le traqueur d’Admoov, une société du groupe AdUX spécialisée dans le drive-to-store : “Notre SDK nous permettait de faire remonter l’information de géolocalisation, puis nous nous reposions sur Smart pour la livraison des campagnes. Nous avions un partenariat étroit avec Smart, qui simplifiait l’interfaçage lorsque l’éditeur l’utilisait comme adserver. Chez les éditeurs qui ont cessé d’utiliser Smart tout en conservant Admoov, nous avons dû utiliser des systèmes de redirection d’adserver en adserver”, explique le président d’AdUX, Cyril Zimmermann.

Smart n’est pas le seul acteur à procéder de la sorte. Admob et MoPub offrent aussi ce service. La liste des acteurs avec lesquels Smart a des ponts techniques est publique (liste disponible ici). Le 14 février 2018, il s’agissait d’AdColony, AppLovin, Google Mobile Ads (Admob), Facebook Audience Network, InMobi, Millennial (Oath), MNG Ads, MoPub (Twitter) et le français Ogury. “L’ajout de nouveaux adapteurs répond à la demande d’éditeurs avec lesquels nous travaillons”, indique Stéphane Ruffin. De plus, les éditeurs qui ont les ressources de développement suffisantes peuvent ajouter leurs propres connecteurs, sans que Smart en soit informé. “Notre but est d’intégrer directement nos SDK dans les applications des éditeurs, car cela permet de nourrir en data notre SSP mobile in-app, Inneractive, explique Vanessa Bourdillon, senior demand sales manager UK et France de Fyber. Mais en attendant une intégration, on peut se connecter via une API avec des éditeurs ou des régies premium”.

Que va changer le RGPD ?

Le RGPD, qui entrera en application le 25 mai 2018, prévoit notamment que les acteurs de la publicité en ligne doivent recueillir le consentement explicite des internautes pour utiliser leurs données personnelles, qui incluent notamment la fonction géolocalisation d’un mobile et l’identifiant publicitaire sur ce support, selon la Commission européenne. Les sociétés qui installent leurs SDK dans les applications mobiles n’ont pas tous la même appréciation du problème.

Pour Vanessa Bourdillon, (Fyber), la charge du consentement incombe aux éditeurs : “Ce sont à eux de collecter l’opt-in, et on s’assure auprès d’eux qu’ils respectent les règles, notamment dans nos contrats. Le type de consentement recueilli dépend des applications et de la stratégie de l’éditeur. La donnée ne nous appartient pas, on ne la stocke pas, on ne la vend pas, on se contente de transmettre l’information aux acheteurs dans la bid request pour maximiser l’eCPM de l’éditeur”. De même, Stéphane Ruffin (Smart) souligne que sa société “recueille seulement les données que l’éditeur veut bien faire passer via (son) SDK. Ils peuvent autoriser ou non la géolocalisation, l’identifiant utilisateur… Et nous sommes une solution 100 % technique, ce qui signifie que nous n’exploitons pas ces données pour nous-mêmes.”

Quel sera l’avenir des SDK ?

Admoov, de son côté, a pris une décision radicale en annonçant mi-février qu’il cessait d’installer son SDK dans les applications mobiles (lire sur notre site) : “A l’heure du RGPD, collecter des données de géolocalisation sans un consentement parfait sur leur utilisation publicitaire et les stocker n’est pas la meilleure idée qui soit. Et puis c’est un outil fastidieux à mettre en place pour les éditeurs. Les temps d’implémentation sont longs, les places sont chères et s’obtiennent parfois en proposant des minimums garantis aux éditeurs. Les SDK sont aussi gênants pour les utilisateurs, puisqu’au-delà du doute sur l’utilisation de leurs données, ils accélèrent la consommation de la batterie”, estime Cyril Zimmermann à mind Media.

Aymeric Marolleau

Lire aussi le premier volet de notre enquête sur les SDK publicitaires, début février 2018 : Quels SDK publicitaires figurent dans les applications mobiles des éditeurs médias ?

Et notre dossier de juin 2017, “Avantages et risques des SDK publicitaires dans les applications mobiles”