La proposition de conception des services d'enchères et de mise aux enchères pour Android détaille l'exécution et le flux de données de la mise aux enchères sur Android à l'aide du serveur d'enchères et de mise aux enchères de confiance. Pour garantir que les données en transit ne soient gérées que par des API protégeant la confidentialité et des serveurs de confiance, elles sont chiffrées entre le client et le serveur à l'aide du chiffrement bidirectionnel de la clé publique hybride.
<ph type="x-smartling-placeholder">Pour lancer l'enchère comme indiqué précédemment, la technologie publicitaire du vendeur sur l'appareil doit procédez comme suit:
- Collecter et chiffrer les données pour la mise aux enchères sur serveur
- Envoyer une requête à un service vendeur non approuvé
- Recevoir une réponse d'un service vendeur non approuvé
- Déchiffrer la réponse à la mise aux enchères Protected Audience et obtenir le résultat de l'enchère
Protected Audience introduit deux nouvelles API compatibles afin de permettre le lancement de mises aux enchères sur serveur :
- L'API
getAdSelectionData
collecte des données pour la mise aux enchères sur serveur et génère une charge utile chiffrée contenant les données d'enchères. Le serveur d'enchères et de mise aux enchères utilise cette charge utile pour lancer une mise aux enchères, générer le résultat de l'enchère et renvoyer le résultat. - Les clients de technologie publicitaire sur l'appareil peuvent appeler l'API
persistAdSelectionResult
pour déchiffrer le résultat généré par la mise aux enchères sur serveur et obtenir l'URL de rendu de l'annonce gagnante.
La technologie publicitaire du vendeur sur l'appareil doit intégrer et créer les éléments suivants pour lancer une mise aux enchères :
- Collecter et chiffrer des données pour le vendeur de mise aux enchères sur serveur : la technologie publicitaire doit appeler l'API
getAdSelectionData
pour obtenir la charge utile chiffrée. - Envoyer une requête à l'envoi du service de vendeur non approuvé : requête
HTTP POST
ouPUT
contenant la charge utile chiffrée générée par l'APIgetAdSelectionData
à son service vendeur et à ses données non fiables requis par le service vendeur non approuvé pour générer des résultats contextuels. - Recevoir la réponse du service vendeur non approuvé : la réponse du service vendeur non approuvé contient le résultat de la mise aux enchères chiffrée et le résultat Protected Audience chiffré.
- Déchiffrez la réponse à la mise aux enchères Protected Audience et obtenez le résultat de l'enchère:
Pour déchiffrer le résultat de la mise aux enchères Protected Audience, la technologie publicitaire du vendeur doit appeler
l'API
persistAdSelectionResult
. Le résultat généré parpersistAdSelectionResult
aidera les technologies publicitaires à déterminer si le contexte l'annonce ou l'annonce Protected Audience a remporté l'enchère, et l'URI de l'annonce gagnante l'annonce Protected Audience, le cas échéant.
Fonctionnalités compatibles avec la mise aux enchères sur serveur
Notre objectif est de proposer toutes les fonctionnalités actuellement disponibles pour la mise aux enchères sur l'appareil. Voici le calendrier pour la prise en charge de ces fonctionnalités lors des enchères sur serveur :
Enchères sur l'appareil |
Enchères sur serveur |
|||
Version Preview développeur |
Bêta |
Version Preview développeur |
Bêta |
|
Rapports sur les victoires au niveau des événements |
1er trimestre 2023 |
3e trimestre 2023 |
N/A |
4e trimestre 2023 |
1er trimestre 2023 |
4e trimestre 2023 |
N/A |
1er trimestre 2024 |
|
2e trimestre 2023 |
3e trimestre 2023 |
N/A |
4e trimestre 2023 |
|
Transmission des annonces contextuelles au workflow de sélection des annonces pour le filtrage |
2e trimestre 2023 |
1er trimestre 2024 |
N/A |
N/A |
2e trimestre 2023 |
3e trimestre 2023 |
N/A |
4e trimestre 2023 |
|
3e trimestre 2023 |
4e trimestre 2023 |
N/A |
4e trimestre 2023 |
|
Facturation autre qu'au CPM |
3e trimestre 2023 |
4e trimestre 2023 |
||
Création de rapports |
3e trimestre 2023 |
4e trimestre 2023 |
3e trimestre 2023 |
4e trimestre 2023 |
Médiation Open Bidding |
N/A |
N/A |
N/A |
1er trimestre 2024 |
2e trimestre 2023 |
1er trimestre 2024 |
N/A |
1er trimestre 2024 |
|
Gestion des devises |
N/A |
N/A |
N/A |
1er trimestre 2024 |
Intégration de K-anon |
N/A |
1er trimestre 2024 |
N/A |
1er trimestre 2024 |
Intégration du service Private Aggregation |
N/A |
N/A |
N/A |
3e trimestre 2024 |
Mise aux enchères sur serveur à l'aide des API Protected Audience
Dans la version Preview développeur, AdSelectionManager propose deux nouvelles API : getAdSelectionData
et persistAdSelectionResult
. Ces API permettent aux SDK de technologies publicitaires de s'intégrer aux serveurs d'enchères et de mise aux enchères.
Collecter et chiffrer les données pour une mise aux enchères sur serveur
L'API getAdSelectionData
génère l'entrée requise pour les composants d'enchères et de mise aux enchères tels que BuyerInput
et ProtectedAudienceInput
, puis chiffre les données avant de rendre le résultat accessible à l'appelant. Pour éviter toute fuite de données entre les applis, ces données contiennent les informations de tous les acheteurs présents sur l'appareil. Pour en savoir plus sur cette décision, consultez la section Considérations liées à la confidentialité et les stratégies pour l'optimiser dans la section Considérations liées à la taille.
Pour accéder à l'API, l'accès à l'API Protected Audience doit être activé, et l'autorisation ACCESS_ADSERVICES_CUSTOM_AUDIENCE
doit être définie dans le fichier manifeste de l'appelant.
public class AdSelectionManager {
public void getAdSelectionData(
GetAdSelectionDataRequest getAdSelectionDataRequest,
Executor executor,
OutcomeReceiver<GetAdSelectionDataOutcome, Exception> receiver) {}
}
GetAdSelectionDataRequest
- L'appelant doit définir le champ
seller
dans la requête, car il permet d'exécuter des vérifications d'inscription avant de répondre à la requête. - Le champ
coordinatorOriginUri
est facultatif.- Si ce champ est défini, il doit correspondre au schéma, au nom d'hôte et au port de la l'URL du coordinateur configurée Déployer le serveur d'enchères et de mise aux enchères du vendeur.
- Le coordinateur doit faire partie de la liste des coordinateurs approuvés:
Fournisseur URI Origine de l'URI Par défaut Google Cloud https://publickeyservice.pa.gcp.privacysandboxservices.com/.well-known/protected-auction/v1/public-keys https://publickeyservice.pa.gcp.privacysandboxservices.com Oui Amazon Web Services https://publickeyservice.pa.aws.privacysandboxservices.com/.well-known/protected-auction/v1/public-keys https://publickeyservice.pa.aws.privacysandboxservices.com Non - Si aucune origine de coordinateur n'est indiquée, le coordinateur par défaut est utilisé.
- Même s'il est très peu probable que l'URL de Coordinate soit modifiée, nous vous recommandons vivement de mettre en place un mécanisme de gestion dynamique de cette URL. Ainsi, toute modification future apportée à l'URL pourra être prise en compte sans nécessiter de nouvelle version du SDK.
public class GetAdSelectionDataRequest {
public setSeller(AdTechIdentifier seller);
public setCoordinatorOriginUri(Uri coordinatorOriginUri)
}
Une fois la requête validée, les données des acheteurs sur l'appareil sont composées dans BuyerInput
et ProtectedAudienceInput
. L'objet de charge utile final est ensuite chiffré à l'aide du chiffrement bidirectionnel de la clé publique hybride.
GetAdSelectionDataOutcome
GetAdSelectionDataOutcome
est généré comme résultat de l'API getAdSelectionData
. Elle contient les éléments suivants :
adSelectionId
: entier opaque pour identifier cette invocation degetAdSelectionData
. Le client de technologie publicitaire doit conserver cette valeuradSelectionId
, qui sert de pointeur vers l'appelgetAdSelectionData
. Cet identifiant est nécessaire à l'APIpersistAdSelectionResult
pour déchiffrer le résultat d'enchères du serveur d'enchères et de mise aux enchères. Il est également requis par les APIreportImpression
etreportEvent
.adSelectionData
: il s'agit des données d'enchères chiffrées requises par le serveur d'enchères et de mise aux enchères pour lancer des enchères. Cette méthode contient :- Les données d'audience personnalisée filtrées en fonction de la limitation de la fréquence d'exposition, des filtres d'installation de l'appli et des exigences liées aux enchères sur le serveur pour les audiences personnalisées.
- Dans une prochaine version, elle contiendra les données d'installation de l'appli.
public class GetAdSelectionDataOutcome {
Public getAdSelectionId(long adSelectionId);
public byte[] getAdSelectionData();
}
Traitement des erreurs, des exceptions et des échecs
Si la génération des données de sélection des annonces ne peut pas être terminée pour des raisons telles que des arguments non valides, des délais d'inactivité ou une utilisation excessive des ressources, le rappel OutcomeReceiver.onError()
fournit une AdServicesException
avec
les comportements suivants :
- Si
getAdSelectionData
est initié avec des arguments non valides,AdServicesException
indique une exception IllegalArgumentException comme étant la cause. - Toutes les autres erreurs reçoivent une
AdServicesException
avecIllegalStateException
pour cause.
Envoyer une requête à un service vendeur non approuvé
À l'aide d'AdSelectionData
, le SDK de l'appareil peut envoyer une requête au service publicitaire de son vendeur en incluant les données dans une requête POST
ou PUT
:
fetch('https://www.example-ssp.com/auction', {
method: "PUT",
body: data,
...
})
Le SDK sur l'appareil est responsable de l'encodage de ces données. Nous vous recommandons d'utiliser une solution efficace, telle que l'envoi de la requête au service publicitaire du vendeur en tant que multipart/form-data.
Recevoir une réponse d'un service vendeur non approuvé
Comme indiqué dans la section Explication du système d'enchères et de mise aux enchères, lorsque le service vendeur non approuvé reçoit la demande, il appelle les acheteurs partenaires pour obtenir des annonces contextuelles.
Le service vendeur non approuvé transfère les éléments chiffrés adSelectionData
et AuctionConfig
au service SellerFrontEnd du serveur d'enchères et mise aux enchères s'exécutant dans un TEE.
Une fois l'enchère Protected Audience terminée, le service SellerFrontEnd chiffre le résultat de l'enchère et le renvoie en réponse au service vendeur non approuvé.
Le service vendeur non approuvé envoie une réponse à l'appareil contenant l'annonce contextuelle et/ou le résultat chiffré de l'enchère Protected Audience.
Lorsqu'il reçoit la réponse, le code de technologie publicitaire du vendeur sur l'appareil peut choisir d'utiliser uniquement l'annonce contextuelle dans la réponse ou, s'il estime que le résultat Protected Audience présente un intérêt supplémentaire, il peut choisir de déchiffrer le résultat Protected Audience en appelant l'API PersistAdSelectionResult
.
API PersistAdSelectionResult
Pour déchiffrer le résultat Protected Audience, la technologie publicitaire du vendeur peut appeler la deuxième API Protected Audience persistAdSelectionResult
. L'API déchiffre le résultat et renvoie un AdSelectionOutcome
, le même objet renvoyé aujourd'hui par une mise aux enchères sur l'appareil.
Pour accéder à l'API, l'appelant doit activer l'accès à l'API Protected Audience et définir l'autorisation ACCESS_ADSERVICES_CUSTOM_AUDIENCE
dans son fichier manifeste.
public void persistAdSelectionResult(
PersistAdSelectionResultRequest persistAdSelectionResultRequest,
Executor executor,
OutcomeReceiver<AdSelectionOutcome, Exception> receiver) {}
PersistAdSelectionResultRequest
L'appelant doit définir les éléments suivants dans la requête :
public final class PersistAdSelectionResultRequest {
Public setAdSelectionId(long adSelectionId);
public setSeller(AdTechIdentifier seller);
public setAdSelectionResult(byte[] adSelectionResult);
}
adSelectionId
: l'identifiant opaque généré par l'appelgetAdSelectionData
dont l'appelant souhaite déchiffrer le résultat.seller
: l'identifiant du vendeur de technologies publicitaires doit être défini dans la requête pour exécuter les vérifications d'inscription avant de la traiter.adSelectionResult
: le résultat d'enchères chiffré généré par le serveur d'enchères et de mise aux enchères que l'appelant souhaite déchiffrer.
Réponse AdSelectionOutcome
Si une annonce Protected Audience l'emporte, AdSelectionOutcome
renvoie l'URI de rendu de l'annonce gagnante. Une fois l'adSelectionResult
déchiffré, les données de rapport sont conservées en interne. Le rappel OutcomeReceiver.onResult()
renvoie un AdSelectionOutcome
contenant les éléments suivants :
URI
: s'il existe une annonce Protected Audience gagnante, une URL de rendu pour l'annonce gagnante est renvoyée. En l'absence de gagnant, "Uri.EMPTY" est renvoyé.adSelectionId
: l'adSelectionId
associé à cette mise aux enchères sur serveur.
Traitement des erreurs, des exceptions et des échecs
Si la génération des données de sélection des annonces ne peut pas être terminée pour des raisons telles que des arguments non valides, des délais d'inactivité ou une utilisation excessive des ressources, le rappel OutcomeReceiver.onError()
fournit une AdServicesException
avec
les comportements suivants :
- Si
getAdSelectionData
est initié avec des arguments non valides,AdServicesException
indique uneIllegalArgumentException
comme étant la cause. - Toutes les autres erreurs reçoivent une
AdServicesException
avecIllegalStateException
pour cause.
Considérations liées à la confidentialité
adSelectionData
est chiffré pour que les données en transit ne soient accessibles qu'aux API protégeant la confidentialité et aux serveurs de confiance.
Malgré le chiffrement, des fuites de données peuvent se produire en raison de la taille d'adSelectionData
. La taille d'adSelectionData
peut varier pour les raisons suivantes :
- Modifications des données
CustomAudience
présentes sur l'appareil. - Modifications apportées à la logique de filtrage
CustomAudience
. - Modifications apportées à l'entrée de l'appel
getAdSelectionData
.
La modification de la taille d'adSelectionData
peut être utilisée pour générer un identifiant multi-applications, comme indiqué dans la discussion à propos de la fuite 1 bit. De nombreuses mesures d'atténuation applicables aux fuites 1 bit s'appliquent également ici.
Pour gérer ces fuites, nous prévoyons de générer les mêmes adSelectionData
pour tous les appels à l'API getAdSelectionData
. Dans les versions initiales, toutes les CustomAudiences
de l'appareil sont utilisées pour créer les adSelectionData
, et la charge utile chiffrée est complétée pour masquer les variations de taille. Nous allons également limiter l'influence des paramètres d'entrée de GetAdSelectionData
sur les adSelectionData
générées.
Cependant, générer les mêmes adSelectionData
pour toutes les technologies publicitaires à l'aide de toutes les
les données d'enchères sur l'appareil créent une charge utile volumineuse qui doit maintenant être transférée
dans chaque appel
au serveur ad tech. L'utilisation de toutes les audiences personnalisées sur l'appareil pour générer la charge utile des enchères ouvre également l'écosystème aux utilisations abusives d'entités malveillantes. Nous avons abordé ces problèmes dans les sections Optimisations de la taille et Atténuation des utilisations abusives ci-dessous.
Optimisations de la taille
Le SDK client de technologie publicitaire doit empaqueter les octets chiffrés des adSelectionData
dans l'appel contextuel HTTP PUT/POST
effectué auprès du serveur de technologie publicitaire. Pour réduire la latence et les coûts du délai aller-retour, il est nécessaire de réduire autant que possible la taille des adSelectionData
sans nuire à l'utilité.
Nous prévoyons d'explorer et potentiellement d'introduire les optimisations suivantes dans les versions à venir afin de réduire la taille des adSelectionData
:
Charge utile générée dans un ensemble fixe de tailles de buckets avec marge intérieure : pour réduire les fuites liées aux variations de taille tout en permettant des charges utiles moins élevées, nous vous suggérons d'utiliser un binning de taille fixe pour la charge utile générée. Si vous limitez le nombre de buckets, par exemple, à 7, le nombre de bits d'entropie divulguée par appel à
getAdSelectionData
sera inférieur à 3.Si les données sur l'appareil dépassent la taille maximale du bucket, les stratégies mentionnées ci-dessous, telles que les valeurs de priorité, seront utilisées pour décider des données à supprimer.
Configuration de l'acheteur : nous évaluons la possibilité de laisser les acheteurs définir une configuration de charge utile par acheteur. Cette configuration est utile pour identifier les enchères auxquelles un acheteur souhaite participer. Si possible, lors de l'inscription, une technologie publicitaire d'acheteur peut enregistrer un point de terminaison à partir duquel Protected Audience récupère la configuration de la charge utile à une fréquence régulière quotidienne. Les API protégeant la confidentialité exposent également une API pour permettre aux technologies publicitaires des acheteurs d'enregistrer ce point de terminaison.
Cette configuration permet ensuite d'évaluer la contribution d'un acheteur aux
adSelectionData
générées pour chaque requêtegetAdSelectionData
.La configuration de la charge utile de l'acheteur permet aux acheteurs de spécifier les éléments suivants :
- Liste des vendeurs autorisés : les CustomAudiences de l'acheteur ne sont ajoutées à la charge utile que si un vendeur de la liste d'autorisation est à l'origine de l'appel
getAdSelectionData
. Nous récupérerions la configuration de la charge utile à une cadence quotidienne pour maintenir la liste d'autorisation à jour. - Limite de taille par vendeur : l'acheteur peut spécifier une taille maximale par vendeur afin de déterminer la taille de données à envoyer dans la charge utile lorsqu'une mise aux enchères est initiée par un certain vendeur. Cela peut être utile si un acheteur souhaite consacrer plus de ressources au traitement des données de mise aux enchères de certains vendeurs. L'interface SellerFrontendService transfère uniquement les données spécifiques à l'acheteur vers chaque BuyerFrontendService. Par conséquent, en définissant une limite de taille par vendeur, un acheteur peut explicitement contrôler la quantité de données ingérées et traitées par le BuyerFrontendService de son serveur d'enchères et de mise aux enchères lancées par un vendeur.
- Liste des vendeurs autorisés : les CustomAudiences de l'acheteur ne sont ajoutées à la charge utile que si un vendeur de la liste d'autorisation est à l'origine de l'appel
Configuration du vendeur : nous évaluons la faisabilité d'une configuration de mise aux enchères par vendeur qui permettrait à ces derniers de définir des paramètres d'enchères afin de contrôler la taille de la charge utile ainsi que les participants. Si possible, lors de l'inscription, la technologie publicitaire du vendeur pourrait spécifier le point de terminaison à partir duquel Protected Audience pourrait récupérer la configuration de la mise aux enchères par vendeur à un rythme régulier. Cette configuration permet ensuite de déterminer la composition et les limites des
adSelectionData
générées pour chaque requêtegetAdSelectionData
.Comme pour la configuration de l'acheteur, une configuration par vendeur permet aux vendeurs de spécifier l'ensemble d'acheteurs qu'ils souhaitent voir dans une mise aux enchères et d'indiquer des limites de contribution par acheteur à la taille de la charge utile.
La configuration de la mise aux enchères permet aux vendeurs de spécifier les éléments suivants :
- Liste d'acheteurs autorisés : pour les enchères initiées par le vendeur donné, seuls les acheteurs de la liste d'autorisation peuvent contribuer aux CustomAudiences pour l'enchère. La configuration de l'enchère doit être mise à jour quotidiennement afin de maintenir la liste d'autorisation à jour en fonction de la liste d'autorisation de l'acheteur côté serveur.
- Limite de taille par acheteur : les vendeurs peuvent spécifier une limite par acheteur pour réguler la taille des données importées par chaque acheteur dans la charge utile envoyée à SellerFrontendService. Si l'acheteur dépasse la limite de taille par acheteur, la priorité CustomAudience définie dans la configuration de la charge utile de l'acheteur sera utilisée afin d'obtenir les données dans les limites prévues.
- Priorité par acheteur : autorisez les vendeurs à définir la priorité par acheteur. La priorité par acheteur permet d'identifier les données de l'acheteur à conserver dans la charge utile si la taille de la charge utile dépasse la limite définie.
- Limite de taille maximale pour la charge utile : l'allocation des ressources peut varier d'un vendeur à l'autre, et vous pouvez définir une limite de taille maximale pour la charge utile de l'enchère par requête. La limite de taille maximale respecte les buckets de taille fixe définis par l'API Protected Audience.
Modifications de l'audience personnalisée
- Spécifier la priorité de l'audience personnalisée : permet aux acheteurs de spécifier une valeur de priorité dans une audience personnalisée. Le champ
priority
permet d'identifier les audiences personnalisées à inclure dans une mise aux enchères si l'ensemble des audiences personnalisées de l'acheteur dépasse les limites de taille par vendeur ou par acheteur. Une valeur de priorité non spécifiée dans une audience personnalisée serait0.0
par défaut.
- Spécifier la priorité de l'audience personnalisée : permet aux acheteurs de spécifier une valeur de priorité dans une audience personnalisée. Le champ
Modifications des données de charge utile
- Réduire les données envoyées dans la charge utile : comme indiqué dans la section Optimisation de la charge utile des services d'enchères et de mise aux enchères, une charge utile plus élevée est générée par les données
ads
de l'audience personnalisée, par les signaux d'enchères utilisateur et par les signaux Android. Une charge utile plus élevée peut être réduite en :- Demandant au client d'envoyer les ID de rendu des annonces (au lieu des objets d'annonces) dans la charge utile.
- Faisant en sorte que le client n'envoie aucune donnée publicitaire dans la charge utile.
- N'envoyant pas les signaux d'enchères de l'utilisateur dans la charge utile du client.
- Réduire les données envoyées dans la charge utile : comme indiqué dans la section Optimisation de la charge utile des services d'enchères et de mise aux enchères, une charge utile plus élevée est générée par les données
Bien que les stratégies mentionnées ci-dessus permettent aux technologies publicitaires de définir des configurations pour gérer la composition et les limites de la charge utile des adSelectionData
, elles peuvent également devenir un facteur de modulation de la taille des adSelectionData
en modifiant les paramètres de configuration. Pour éviter cela, la configuration est récupérée quotidiennement par Protected Audience à partir du point de terminaison configuré.
Optimisation de la latence
Pour que les mises aux enchères sur serveur aient un niveau d'utilité souhaitable, nous devons nous assurer que les API getAdSelectionData
et persistAdSelectionResult
présentent une faible latence par appel. Bien que nous souhaitions proposer la prise en charge de fonctionnalités pour les API en 2023, notre prochaine version se concentrera sur les analyses comparatives et les optimisations de latence pour les API.
Nous étudions les stratégies suivantes pour maintenir la latence dans des limites acceptables :
prégénération de données Protected Audience par vendeur : la configuration des mises aux enchères du vendeur et de la charge utile de l'acheteur sera stable pour une durée considérable (quotidienne), la plate-forme peut précalculer et stocker les données Protected Audience éligibles.
La plate-forme devrait donc créer un mécanisme permettant de surveiller les mises à jour de l'audience personnalisée et de modifier les données Protected Audience prégénérées en fonction des mises à jour. La plate-forme doit aussi déclarer les SLO retarder la technologie publicitaire entre les mises à jour d'audiences personnalisées et l'apparition variation du
adSelectionData
généré pour la mise aux enchères sur serveur.Étant donné qu'un appareil fournit un modèle de calcul de ressources limité avec des priorités de processus variables, nous reconnaissons que cette installation de prégénération doit s'accompagner de garanties de fiabilité et de SLO élevées.
La prégénération des données Protected Audience se baserait donc sur
- L'acceptation par le vendeur de générer à l'avance des données Protected Audience.
- L'éligibilité des acheteurs à participer à une enchère lancée par un vendeur en particulier.
- L'identification des audiences personnalisées par acheteur qui feront partie de la charge utile, compte tenu des éléments suivants :
- Limites de taille par acheteur, priorité par acheteur et limites de taille maximales définies dans la configuration du vendeur.
- Limite de taille par vendeur, priorité d'audience personnalisée définie dans la configuration de l'acheteur.
Une meilleure application du filtrage négatif : si le vendeur le souhaite, la plate-forme pourrait précalculer les
adSelectionData
en générant à l'avance des données Protected Audience et en appliquant un filtrage négatif sur les appels critiquesgetAdSelectionData
. Cela permettrait aux vendeurs de trouver un équilibre entre la réduction de la latence et l'obsolescence dans le filtrage négatif.La plate-forme pourrait fournir cette assistance en fournissant une option par défaut dans la configuration du vendeur, avec une limite d'obsolescence et une option de forçage dans
getAdSelectionData
pour permettre des calculs plus récents si nécessaire. La plate-forme pourrait également fournir une API d'initialisation supplémentaire à appeler avantgetAdSelectionData
pour préparer l'enchère.Calcul de la charge utile pour plusieurs enchères : dans certains cas, il peut être préférable d'utiliser une API performante en termes de latence, au détriment de l'obsolescence des données. Pour ce faire, la plate-forme peut introduire une API d'initialisation permettant de calculer la charge utile complète et fournir une référence à la charge utile calculée à l'appelant.
Pour les appels suivants à
getAdSelectionData
, l'appelant pourrait fournir une référence à la charge utile précalculée à utiliser pour la génération desadSelectionData
.
Les trois stratégies mentionnées ci-dessus se trouvent à la phase d'exploration et visent à décrire la direction que la plate-forme peut prendre pour optimiser la latence. À mesure que nous étudions les profils de latence plus détaillés de l'API et des exigences de la technologie publicitaire, nous continuerons à proposer d'autres stratégies.
Atténuation et identification des utilisations abusives
Comme indiqué dans les considérations liées à la confidentialité, adSelectionData
est généré à l'aide de toutes les données de l'acheteur sur l'appareil.
Toutefois, si toutes les données de l'acheteur sur l'appareil sont utilisées pour générer le
adSelectionData
, alors une entité malveillante peut se faire passer pour un acheteur et
créer des données d'acheteurs frauduleuses afin de
dégrader les performances d'Android, surcharger la charge utile pour
augmenter le coût d'une technologie publicitaire
pour mettre aux enchères ou définir des enchères, etc.
Atténuation
Certaines mesures mentionnées dans la section sur les considérations liées à la taille, comme la configuration de la charge utile de l'acheteur contenant les vendeurs de la liste d'autorisation et la configuration de la mise aux enchères du vendeur contenant les acheteurs de la liste d'autorisation, aideraient à exclure les données inattendues dans la charge utile.
D'autres mesures prises en compte, telles qu'autoriser les SSP à spécifier la priorité de l'acheteur, à placer un quota par acheteur dans la charge utile générée et à définir une taille maximale par charge utile pour les enchères, peuvent également aider à atténuer l'impact des surcharges malveillantes de la charge utile. Ces mesures sont destinées à permettre aux technologies publicitaires de définir les technologies publicitaires avec lesquelles elles collaborent et de définir des limites acceptables pour la charge utile à traiter.
Comme indiqué précédemment, toutes les mesures d'atténuation mises en place pour lutter contre les abus, ainsi que les restrictions de taille, doivent respecter les considérations liées à la confidentialité.
Identification d'entités malveillantes
Bien que les mesures d'atténuation mentionnées ci-dessus protègent la génération des adSelectionData
pour les mises aux enchères sur serveur, elles n'aident pas à identifier les entités malveillantes ni à protéger la plate-forme des utilisations abusives telles que la création d'un nombre sans précédent d'audiences personnalisées d'un acheteur.
Pour garantir la stabilité et la santé de la plate-forme, nous devons trouver un mécanisme permettant d'identifier les entités malveillantes, les vecteurs d'abus et la motivation des attaques spécifiques. Dans les versions suivantes, nous présenterons les explications des vecteurs d'abus potentiels et les protections en place pour les contrer.