Rapports sur l'attribution : mesures entre applications et Web

Envoyer un commentaire

Informations récentes

Comme décrit dans la proposition de conception de l'API Attribution Reporting, les chemins de déclenchement suivants peuvent être attribués sur un seul appareil Android :

  • App-to-app: : l'utilisateur voit une annonce dans une application, puis effectue la conversion dans cette application ou dans une autre application installée.
  • App-to-web: : l'utilisateur voit une annonce dans une application, puis effectue une conversion dans un navigateur mobile ou d'application.
  • Web-to-app: : l'utilisateur voit une annonce dans un navigateur mobile ou d'application, puis effectue une conversion dans une application.
  • Web-to-web: : l'utilisateur voit une annonce dans un navigateur mobile ou d'application, puis effectue une conversion dans le même navigateur ou dans un autre navigateur sur le même appareil.

"Web" correspond ici au contenu Web diffusé dans une application. Le contenu Web peut être présenté dans le contexte d'une application de navigateur mobile ou sous forme de sites Web intégrés affichés dans des applications autres que des navigateurs.

Les chemins de déclenchement précédents se traduisent par les exigences suivantes :

  • Pour les technologies publicitaires : mises à jour des appels d'API et des rapports pour permettre les chemins "Application/Web".
  • Pour les applications et les navigateurs : possibilité de transmettre l'enregistrement des sources d'attribution Web et des déclencheurs Web à Android.

Ce document explique comment l'API Attribution Reporting est compatible avec les chemins de déclenchement de type "Application/Web", "Web/application" et "Web/Web". Il décrit également les modifications que les technologies publicitaires et les applications doivent apporter pour répondre aux exigences liées à la prise en charge de ces chemins de déclenchement.

Obtenir l'accès aux API Attribution Reporting

Les plates-formes de technologie publicitaire doivent demander l'accès aux API Attribution Reporting. Pour en savoir plus, consultez la section Créer un compte Privacy Sandbox.

Une fois le processus d'inscription finalisé, l'API supprime l'enregistrement si un appel d'enregistrement désinscrit est reçu.

Lors de l'inscription, les plates-formes de technologie publicitaire doivent s'assurer qu'elles s'inscrivent avec toutes les URL de serveur qu'elles sont susceptibles d'utiliser dans l'application et sur le Web pour enregistrer les sources d'attribution et les déclencheurs. Plusieurs URL d'enregistrement de serveur sont acceptées, mais une seule origine est acceptée pour les rapports. Cette origine est dérivée du domaine de l'une des URL d'enregistrement de serveur.

Modifications pour les technologies publicitaires

Modifications apportées à l'enregistrement et à l'attribution

Lors de l'enregistrement d'une source d'attribution, les technologies publicitaires spécifient actuellement un champ de destination qui correspond au nom du package de l'application où se produit l'événement déclencheur. Pour permettre la mesure des chemins Application/Web, nous prévoyons de prendre en charge un champ de destination d'application (nom de package d'application) et un champ de destination Web (eTLD+1).

Lors de l'enregistrement des sources d'attribution Web ou des déclencheurs, l'API ne permet pas les redirections, car chaque application hébergeant du contenu Web peut disposer de son propre modèle d'autorisations. Chaque application est chargée de suivre les redirections (si elles sont prises en charge) et d'appeler les API de contexte Web pour chaque saut de redirection.

En outre, cette intégration permet aux technologies publicitaires d'utiliser une logique d'attribution spécifique aux applications au niveau des sources d'attribution Web. Par exemple, vous pouvez désormais spécifier des périodes d'attribution après installation au niveau d'une source d'attribution Web.

Recevoir des rapports sur les conversions d'application et les conversions Web

L'API Android Attribution Reporting permet d'envoyer des rapports pour les conversions d'application et les conversions Web. Si les technologies publicitaires ne souhaitent pas aligner les données de déclencheur et les clés/valeurs d'agrégation sur les plates-formes Web et d'application, elles peuvent faire la distinction entre une conversion sur le Web et une conversion d'application :

  • Pour les rapports au niveau de l'événement, nous acceptons un champ de destination qui spécifie si le déclencheur s'est produit sur le Web (la destination correspond alors à eTLD+1) ou sur l'application (la destination correspond alors à un nom du package de l'application).
  • Pour les rapports agrégables, la destination est envoyée en texte clair.

Implications des mesures Web/Web

Les applications déterminent quand transmettre l'enregistrement à l'API Attribution Reporting. Plusieurs éléments sont à prendre en compte :

  • L'API Attribution Reporting est-elle disponible sur cet appareil ? Nous présentons un nouveau signal aux applications, qui indique si l'API Attribution Reporting est disponible sur cet appareil. Consultez la section Modifications pour les applications pour découvrir comment les applications peuvent transmettre l'enregistrement à l'API Attribution Reporting.
  • Quelle partie des sources d'attribution et des déclencheurs doit être transmise à l'API ? Cette décision est prise par chaque application ou par la technologie publicitaire, si l'application le permet. Si l'application possède sa propre solution de mesure, elle peut souhaiter que cette solution soit utilisée à la place. Au bout du compte, l'attribution de tous les enregistrements de source et de déclencheur à l'API Android Attribution Reporting, le cas échéant, permet d'obtenir l'attribution la plus précise possible dans l'application et sur le Web.

L'exemple suivant montre comment les applications de navigateur peuvent interagir avec l'API Attribution Reporting pour fournir des mesures précises lorsque l'utilisateur clique sur une annonce dans une application de navigateur et dans une application autre qu'un navigateur :

Exemples de clics et de conversions utilisateur sur une période de trois jours
Exemple d'enregistrement de la source et du déclencheur dans un navigateur et une application
  • Le premier jour, l'utilisateur clique sur une annonce dans l'application du navigateur.
    • Le navigateur peut choisir d'utiliser sa propre solution de mesure ou de transmettre l'enregistrement du clic sur l'annonce Web à l'API Attribution Reporting.
  • Le deuxième jour, l'utilisateur clique sur une annonce dans une application autre qu'un navigateur.
    • Le clic est enregistré en tant que source d'attribution auprès de l'API. Le navigateur n'a pas accès à ce clic, car l'événement s'est produit dans une autre application.
  • Le troisième jour, l'utilisateur effectue la conversion dans l'application de navigateur.
    • Si l'application de navigateur enregistre à la fois le clic et la conversion à l'aide de sa propre solution de mesure, puis transmet ces informations à l'API Attribution Reporting, il est peu probable qu'une technologie publicitaire puisse dédupliquer les rapports sur les conversions entre les solutions de mesure. En outre, une technologie publicitaire peut consommer à la fois les limites de débit des applications du navigateur et celles de l'API Attribution Reporting. Par conséquent, nous recommandons aux applications de transmettre tous les événements d'annonce et toutes les conversions à enregistrer au niveau de l'API, le cas échéant.

Enregistrer la source d'attribution et le déclencheur depuis WebView

Si l'application utilise WebView pour afficher du contenu Web plutôt qu'une annonce Android native, elle peut demander à rejoindre la liste d'autorisation pour registerWebSource() et fournir l'origine de niveau supérieur du site Web à associer à la source d'attribution plutôt que le nom du package d'application.

Comme pour les navigateurs, WebView est compatible avec registerWebTrigger() pour les enregistrements de déclencheur, ce qui associe le déclencheur à l'origine de niveau supérieur. WebView ne permet pas d'enregistrer un déclencheur d'application. Contactez-nous si vous pensez que ce serait utile. Pour obtenir la liste complète des combinaisons compatibles avec WebView, consultez la section Enregistrement de la source d'attribution et du déclencheur à partir de WebView.

Contrairement aux navigateurs, WebView ne permet l'enregistrement avec le système d'exploitation dans l'en-tête Attribution-Reporting-Eligible que si l'API Attribution Reporting d'Android est disponible. Dans le cas contraire, WebView ne définit pas d'en-tête Attribution-Reporting-Eligible, et aucun enregistrement n'est effectué.

Pour enregistrer une source / déclencheur d'attribution à l'aide de l'OS:

  • Les technologies publicitaires doivent répondre aux enregistrements de source à l'aide de l'en-tête Attribution-Reporting-Register-OS-Source, qui lance un appel d'API secondaire à partir de la WebView vers registerSource() ou registerWebSource().
  • Les technologies publicitaires peuvent également répondre aux enregistrements de déclencheurs à l'aide de l'en-tête Attribution-Reporting-Register-OS-Trigger, qui lance un appel d'API secondaire à partir du composant WebView vers registerWebTrigger() ou registerTrigger().

Notez que si la réponse n'inclut pas les en-têtes précédents ou qu'elle inclut également les en-têtes Attribution-Reporting-Register-Source / Attribution-Reporting-Register-Trigger, même si le Web n'est pas disponible, l'enregistrement complet échouera.

Pour savoir si WebView utilisera registerSource()/registerWebSource() et registerTrigger() / registerWebTrigger() (et pour savoir comment modifier ce comportement), consultez Source d'attribution et déclencher l'inscription à partir de WebView.

Rapports de débogage de transition

L'API Attribution Reporting est compatible avec une fonctionnalité facultative appelée rapports de débogage de transition, qui permet aux technologies publicitaires d'en savoir plus sur les rapports sur l'attribution lorsqu'un identifiant publicitaire est disponible. Il existe deux types de rapports de débogage : attribution-success et verbose. Ces rapports sont compatibles avec l'attribution Web et entre applications, et contiennent les mêmes informations. La seule différence réside dans les autorisations qui s'appliquent lors de l'envoi des rapports de débogage.

Pour une attribution Web/Web ayant lieu dans une seule application (par exemple, dans la même application de navigateur), les rapports "attribution-success" et "verbose" ne sont proposés que lorsque des cookies tiers sont disponibles. Ils ne dépendent pas de la disponibilité de l'identifiant publicitaire.

Pour l'attribution application/Web, Web/application et Web/Web entre applications, les rapports "attribution-success" et "verbose" sont disponibles si l'identifiant publicitaire est disponible côté application, tandis que la technologie publicitaire peut transmettre le même identifiant publicitaire (correct) du côté Web. Vous trouverez ci-dessous un exemple d'attribution application/Web dans laquelle la source a lieu dans une application d'éditeur, mais le déclencheur se produit sur le site d'un annonceur dans une application de navigateur.

Pour activer un rapport de débogage "attribution-success" pour l'attribution application/Web, les trois conditions ci-dessous doivent être remplies :

  • L'utilisateur ne doit pas avoir désactivé la personnalisation basée sur l'identifiant publicitaire.
  • L'application de l'éditeur doit avoir déclaré les autorisations de l'identifiant publicitaire.
  • La technologie publicitaire doit transmettre la valeur de l'identifiant publicitaire dans l'enregistrement du déclencheur (à partir d'un contexte Web).

Pour activer les rapports de débogage "verbose" pour l'attribution application/Web:

  • Les rapports "verbose" de la source dépendent uniquement des autorisations côté éditeur. Pour qu'ils soient envoyés, l'utilisateur ne doit pas avoir désactivé la personnalisation des identifiants publicitaires, et l'application de l'éditeur doit avoir déclaré les autorisations de l'identifiant publicitaire.
  • Les rapports "verbose" du déclencheur ne dépendent que des autorisations côté déclencheur (dans cet exemple, le Web). Les cookies tiers doivent être disponibles dans le navigateur pour déclencher l'envoi de rapports "verbose" du déclencheur.
  • Pour les rapports "verbose" du déclencheur, qui peuvent inclure un élément source_debug_key, source_debug_key est ajouté si l'identifiant publicitaire est disponible pour l'application de l'éditeur.

Notez que dans tous les cas, la technologie publicitaire doit toujours activer la réception des rapports de débogage de type "verbose" via le champ de dictionnaire debug_reporting dans les en-têtes d'enregistrement de la source et du déclencheur.

Modifications pour les applications

L'attribution entre les plates-formes d'applications et Web sera possible en permettant aux applications de transmettre l'enregistrement des sources d'attribution Web et des déclencheurs Web à l'API Attribution Reporting sur Android à l'aide d'un nouvel ensemble d'appels d'API de contexte Web.

Une fois que les étapes d'enregistrement décrites dans les sections suivantes auront été suivies, les sources d'attribution sur le Web et dans l'application, ainsi que les déclencheurs, seront stockés sur l'appareil. De plus, l'API Attribution Reporting pourra procéder à une attribution au dernier contact basée sur la source pour l'application et le Web.

Pour découvrir comment les navigateurs peuvent s'intégrer à l'API Attribution Reporting d'Android afin de permettre les mesures entre les applications et le Web, consultez l'article Proposition de Privacy Sandbox pour le Web. Dans cette proposition, le navigateur ajoute les en-têtes de requêtes suivants :

  • Attribution-Reporting-Eligible indique si l'attribution au niveau du système d'exploitation est disponible. Dans ce cas, l'en-tête indique si l'API Attribution Reporting d'Android est disponible.
  • Le cas échéant, les technologies publicitaires peuvent éventuellement répondre à l'aide d'Attribution-Reporting-Register-OS-Source, qui lance un appel d'API secondaire à partir de l'application de navigateur vers registerWebSource().
  • Les technologies publicitaires peuvent également répondre aux enregistrements de déclencheurs à l'aide de l'en-tête Attribution-Reporting-Register-OS-Trigger, qui lance un appel d'API secondaire à partir de l'application de navigateur vers registerWebTrigger().

Enregistrement de la source d'attribution

Lors de l'enregistrement d'une source d'attribution, les applications peuvent appeler registerWebSource(), qui attend les paramètres suivants :

  • URI de la source d'attribution : la plate-forme envoie une requête à chaque URI de cette liste afin de récupérer les métadonnées associées à la source d'attribution.

    Chaque URI doit accompagner un indicateur Debug booléen pour indiquer si les clés de débogage fournies par les technologies publicitaires doivent être incluses ou non dans le rapport.
  • Événement d'entrée : objet InputEvent (pour un événement de clic) ou null (pour un événement de vue).
  • Origine de la source : origine à partir de laquelle la source a eu lieu (site Web de l'éditeur).
  • Destination OS : nom de package de l'application dans lequel se produit l'événement déclencheur.
  • Destination Web : eTLD+1 où l'événement déclencheur se produit.
  • Destination validée : intent d'OS ou d'URI de destination Web utilisé pour la navigation lors du clic de l'utilisateur.

Lorsque l'API envoie une requête à l'URI de la source d'attribution, la technologie publicitaire doit répondre avec les métadonnées de la source d'attribution dans l'en-tête HTTP, Attribution-Reporting-Register-Source. Cet en-tête utilise les mêmes champs que l'enregistrement de la source d'attribution "Application/application", avec quelques modifications :

  • L'API valide les destinations spécifiées par la technologie publicitaire par rapport à celles spécifiées par l'application. Si elles sont différentes, l'API annule l'enregistrement de la source d'attribution.

    Les applications doivent valider des destinations Web avant d'appeler l'API de contexte Web. Pour les clics, les applications doivent s'assurer que la destination spécifiée correspond à celle vers laquelle l'utilisateur se dirige.
  • L'API ignore tous les URI de redirection fournis dans Attribution-Reporting-Redirects. Les applications doivent suivre elles-mêmes les redirections et appeler registerWebSource() pour chacune d'elles, afin qu'elles puissent appliquer leurs propres règles d'autorisation, si nécessaire.

Les applications doivent rejoindre une liste d'autorisation pour pouvoir appeler registerWebSource(). Pour la rejoindre, remplissez ce formulaire. Cette liste d'autorisation vise à réduire les considérations de confidentialité permettant d'établir la confiance pour le contexte Web.

Enregistrement du déclencheur (conversion)

Lors de l'enregistrement d'un déclencheur, les applications peuvent appeler registerWebTrigger(), qui attend les paramètres suivants :

  • URI du déclencheur : la plate-forme envoie une requête à chaque URI de cette liste afin de récupérer les métadonnées associées au déclencheur.
  • Origine de la destination : origine du déclencheur (site Web de l'annonceur).

Enregistrement de la source d'attribution et des déclencheurs depuis WebView

Par défaut, WebView utilisera registerSource() et registerWebTrigger(). Cette opération associe les sources à l'application et les déclencheurs à l'origine de premier niveau de la WebView lorsque le déclencheur se produit.

Si une application nécessite un comportement différent (par exemple, celles qui hébergent du contenu Web dans une WebView), elle doit utiliser la méthode setAttributionRegistrationBehavior sur la classe androidx.webkit.WebViewSettingsCompat. Cette méthode spécifiera si WebView doit appeler registerWebSource() ou registerSource(), et registerWebTrigger() ou registerTrigger().

Les options disponibles pour setAttributionRegistrationBehavior sont les suivantes :

Valeur Description Exemple de cas d'utilisation
APP_SOURCE_AND_WEB_TRIGGER (par défaut) Permet aux applications d'enregistrer des sources d'application (sources associées au nom du package de l'application) et des déclencheurs Web (déclencheurs associés à l'eTLD+1) à partir de WebView. Applications qui utilisent WebView pour diffuser des annonces au lieu de permettre la navigation Web.
WEB_SOURCE_AND_WEB_TRIGGER Permet aux applications d'enregistrer des sources Web et des déclencheurs Web à partir de WebView.
Remarque: Les applications qui utilisent cette option devront demander à rejoindre la liste d'autorisation pour utiliser registerWebSource().		 Applications de navigateur basées sur WebView pour lesquelles des impressions et des conversions d'annonces peuvent se produire sur des sites Web dans WebView.
APP_SOURCE_AND_APP_TRIGGER Permet aux applications d'enregistrer des sources d'application et des déclencheurs d'application à partir de WebView. Applications basées sur WebView pour lesquelles les impressions et les conversions d'annonces doivent toujours être associées à l'application plutôt qu'à l'eTLD+1 du composant WebView.
DISABLED Désactive l'enregistrement des sources et des déclencheurs à partir de WebView.
Notez que l'appel réseau initial aux URI de la source d'attribution ou du déclencheur peut toujours se produire, mais toutes les réponses sont supprimées et rien ne sera stocké sur l'appareil.

Points à prendre en compte concernant la confidentialité et la sécurité

Impact sur les mécanismes de protection de la confidentialité appliqués aux rapports

Comme décrit dans la proposition de conception principale, l'API applique aux rapports des limites de débit qui protègent la confidentialité. Certaines limites sont partitionnées entre les applications sources et de destination. Lorsqu'une source d'attribution Web ou un déclencheur est enregistré, la limite de débit est partitionnée par le site source ou de destination plutôt que par l'application.

Si l'application gère des limites de débit distinctes, il est possible qu'un adversaire consomme les limites de débit spécifiques à l'application en plus de celles de l'API. Pour résoudre ce problème, les applications doivent s'assurer qu'une source d'attribution donnée n'est pas enregistrée à la fois dans la solution de mesure de l'application et dans l'API Android Attribution Reporting.

Établir la confiance pour le contexte Web

Dans les appels d'API de contexte Web, l'API fait confiance à l'application pour détecter et spécifier les origines de la source et de la destination. Cela peut avoir des implications en termes de confidentialité et de sécurité :

  • Un adversaire peut revendiquer l'hébergement de sites Web dont il dit être le propriétaire afin d'essayer de contourner les limites de débit concernant la quantité d'informations que toute source peut transférer.
  • Plusieurs adversaires peuvent s'entendre pour enregistrer des sources d'attribution distinctes et revendiquer le même site source. Cela peut amener le site source à atteindre les limites de débit de la plate-forme publicitaire et l'empêcher d'enregistrer des sources d'attribution légitimes.

Pour pallier à ce problème, nous limitons l'appel de registerWebSource() aux navigateurs ou aux applications qui attestent que le site source utilisé lors de l'enregistrement représente le véritable site présenté à l'utilisateur. Remplissez ce formulaire pour rejoindre la liste d'autorisation et pour pouvoir ainsi appeler registerWebSource().

Toute application peut appeler registerWebTrigger(), car les considérations de confidentialité et de sécurité côté déclencheur ne sont pas applicables sans la coopération du côté source.

Commandes utilisateur

Les applications peuvent continuer à prendre en charge les commandes utilisateur ou les règles d'autorisation, à condition qu'elles soient définies au moment de l'enregistrement. Par exemple, si des autorisations au niveau du site ou de l'utilisateur sont accordées, elles doivent les évaluer et déterminer si elles doivent appeler les API de contexte Web.

De plus, nous prévoyons d'ajouter un appel d'API à partir des applications afin de supprimer les sources d'attribution, les déclencheurs et les rapports en attente correspondants stockés sur l'appareil. Par exemple, si les applications permettent à l'utilisateur d'effacer leur historique de navigation, cette API pourra être appelée pour supprimer les sources d'attribution, les déclencheurs et les rapports en attente stockés pour ces applications sur l'appareil de l'utilisateur.

Questions à venir et questions ouvertes

L'interopérabilité entre l'application et le Web pour l'API Attribution Reporting est en cours de développement. Nous aimerions connaître l'avis de la communauté concernant quelques idées :

  1. Sur un appareil compatible avec la Privacy Sandbox d'Android, comment prévoyez-vous d'utiliser les solutions de mesure du navigateur avec l'API Android Attribution Reporting ? Préférez-vous tout transmettre à Android ?
  2. Le fait que deux pings puissent être reçus pour chaque source d'attribution et chaque déclencheur (l'un provenant du navigateur ou de l'application et l'autre de l'API Attribution Reporting) vous inquiète-t-il ?
  3. Que pouvons-nous faire pour faciliter le débogage entre différentes API ?
  4. Cette proposition n'inclut aucune validation indiquant que les destinations de l'application et du Web sont affiliées. À l'avenir, il se peut que nous les validions en vérifiant les associations à l'aide de Digital Asset Links. Cela bloquerait-il l'un de vos cas d'utilisation ? Est-il judicieux d'utiliser Digital Asset Links pour effectuer cette validation ?
  5. Lorsque vous enregistrez une source d'attribution, vous devez spécifier une destination. En cas d'attribution selon un modèle Web/application, vous pouvez associer une application. Quels formats utilisez-vous pour spécifier cette association d'application ?
  6. Lorsque vous enregistrez une source d'attribution de type Application/Web, vous devez enregistrer cet événement depuis l'application auprès de l'API Android Attribution Reporting. Par exemple, si l'utilisateur clique sur une annonce et que le clic est ouvert dans un navigateur ou dans l'onglet personnalisé d'un navigateur, ce clic (événement source) doit être enregistré à partir de l'application plutôt que dans le contexte du navigateur. Veuillez nous contacter si vous avez des inquiétudes à ce sujet ou si d'autres cas d'utilisation ne font pas partie des catégories couvertes dans ce problème décrivant les flux pris en charge.