L'ère des identifiants touche à sa fin sur Android

Pendant des années, le ciblage et la mesure des publicités mobiles ont reposé sur des identifiants stables et inter-applications — principalement le Google Advertising ID (GAID). Ce modèle est en train d'être démantelé. Le Privacy Sandbox sur Android de Google vise à diffuser des publicités pertinentes et à mesurer les conversions sans partager d'identifiants au niveau de l'utilisateur entre les applications.

Pour les éditeurs qui financent des applications et des jeux gratuits grâce à la publicité, il ne s'agit pas d'une simple mise à jour de SDK. Cela change la façon dont les partenaires de demande comprennent votre audience, dont l'attribution remonte vers les annonceurs et dont votre inventaire est valorisé. Apprendre dès maintenant les briques de base — pendant que les anciens signaux fonctionnent encore en partie — est la meilleure façon de protéger vos revenus pendant la transition.

Topics API : des signaux d'intérêt sans suivi

La Topics API remplace le profilage d'intérêt inter-applications. Au lieu que les annonceurs assemblent un profil comportemental à partir de nombreuses applications, l'appareil déduit un petit ensemble de thèmes d'intérêt grossiers (par exemple « Jeux mobiles » ou « Voyage ») à partir de l'utilisation récente. Les thèmes sont stockés sur l'appareil et seul un nombre limité est partagé avec les SDK appelants par période.

Concrètement :

• Le ciblage devient plus large et contextuel plutôt que propre à chaque personne.
• Les thèmes sont grossiers, changent au fil du temps et excluent par conception les catégories sensibles.
• Le système d'exploitation arbitre quel signal atteint la demande — vous ne possédez plus le profil.

Attendez-vous à ce que les CPM basés sur les centres d'intérêt dépendent davantage de la pertinence contextuelle et du contexte first-party que vous pouvez légitimement fournir dans les requêtes publicitaires.

SDK Runtime : isoler les SDK publicitaires

Le SDK Runtime déplace les SDK publicitaires et d'analyse dans un processus distinct et isolé (sandbox) avec des autorisations limitées. Aujourd'hui, un SDK publicitaire intégré s'exécute avec le même niveau d'accès que votre application — il peut lire les données de l'application, les signaux de l'appareil, et bien plus encore. Le SDK Runtime restreint cela, réduisant ce qu'un SDK peut collecter en silence et limitant la corrélation inter-applications.

Pour les éditeurs, cela entraîne deux réalités. Les SDK de médiation et de publicité doivent être mis à jour vers des versions compatibles avec le runtime, une dépendance à suivre pour chaque partenaire. Et les signaux que les SDK récupéraient implicitement ne seront plus disponibles, de sorte qu'il devient encore plus important de transmettre un contexte first-party propre et consenti via les API prises en charge.

Attribution Reporting : la mesure sans identifiants

L'Attribution Reporting API reconstruit la mesure des conversions sur l'appareil. Plutôt que d'associer un clic publicitaire à une installation via un identifiant partagé, elle enregistre les événements d'attribution localement et renvoie des rapports agrégés ou des rapports au niveau de l'événement bruités et différés — prouvant que les campagnes fonctionnent tout en empêchant la ré-identification au niveau de l'utilisateur.

Les compromis auxquels votre demande devra s'adapter incluent :

• Des délais dans les rapports au lieu d'une attribution instantanée et déterministe.
• Du bruit statistique qui nécessite des volumes plus importants pour être lu correctement.
• Des résumés agrégés remplaçant la correspondance individuelle clic-vers-installation.

Attendez-vous à une période où les annonceurs feront tourner l'attribution du Privacy Sandbox en parallèle des méthodes existantes pour les calibrer. L'inventaire qui se mesure bien avec les nouvelles API conservera les budgets ; l'inventaire qui dépend de signaux obsolètes subira des pressions.

Ce que les éditeurs d'applications devraient faire dès maintenant

La transition récompense la préparation. Mesures concrètes :

• Auditez vos SDK. Vérifiez que vos SDK de médiation, de réseau publicitaire et d'analyse proposent des versions prêtes pour Privacy Sandbox & SDK Runtime, et planifiez les mises à niveau.
• Inscrivez-vous et testez. Utilisez l'inscription au Privacy Sandbox de Google et testez sur les préversions développeur afin de ne pas déboguer en production.
• Renforcez le contexte first-party. Investissez dans des signaux contextuels et consentis que vous pouvez transmettre légitimement, puisque les identifiants inter-applications n'assureront plus la charge.
• Évaluez la mesure tôt. Comparez les résultats de l'Attribution Reporting à votre attribution actuelle pour fixer des attentes réalistes aux acheteurs.
• Gérez bien le consentement. Le Sandbox réduit le partage silencieux de données mais ne supprime pas votre obligation légale de recueillir et de respecter le consentement pour les traitements qui subsistent.

Pourquoi le consentement et une CMP restent essentiels

Une idée fausse répandue est que le Privacy Sandbox rend le consentement obsolète. Ce n'est pas le cas. Le Sandbox limite la façon dont les données circulent, mais en vertu du RGPD, des règles ePrivacy et des propres politiques de Google, vous devez toujours obtenir et signaler une base légale valide — et les partenaires de demande exigent toujours des signaux de consentement interopérables pour enchérir. Google Consent Mode v2 et IAB TCF 2.3 restent le tissu conjonctif entre votre interface de consentement et la stack publicitaire.

C'est là que FlexyConsent trouve sa place. En tant que plateforme de gestion du consentement certifiée par Google et prenant en charge l'IAB TCF 2.3 et le Consent Mode v2, elle centralise la façon dont le consentement est collecté et propagé sur l'ensemble de vos applications et sites web. Une seule configuration émet les signaux standardisés qu'attendent vos partenaires de médiation et de mesure, de sorte qu'à mesure que les API du Privacy Sandbox sont déployées, vous envoyez un consentement propre, cohérent et auditable — et non une logique fragile, propre à chaque application, qui casse à chaque mise à jour de SDK.

Points clés à retenir

• Le Privacy Sandbox remplace les identifiants inter-applications par des Topics sur l'appareil, un SDK Runtime isolé et un Attribution Reporting bruité.
• Le ciblage s'oriente vers des signaux contextuels et first-party consentis ; l'attribution déterministe cède la place à des rapports agrégés et différés.
• Auditez et mettez à niveau vos SDK publicitaires dès maintenant, inscrivez-vous aux tests et comparez la nouvelle mesure à l'ancienne avant que l'abandon ne se fasse sentir.
• Le consentement reste obligatoire — une CMP compatible TCF 2.3 et Consent Mode v2 comme FlexyConsent maintient vos signaux de consentement valides et interopérables sur chaque propriété.