Les rapports de débogage Protected Audience permettent aux développeurs de technologies publicitaires de déclarer des URL distantes afin de recevoir une demande GET des appareils lorsqu'une enchère est remportée ou perdue. Cela permet les cas d'utilisation suivants :
- Recevoir des rapports sur les résultats des enchères remportées et perdues.
- Comprendre pourquoi les enchères sont perdues. Par exemple : déterminez s'il s'agit d'un problème lié à l'implémentation d'un script d'enchères ou d'attribution des scores, ou à un problème logique de base.
- Découvrir les problèmes liés à la mise à jour de la logique JavaScript
Les rapports de débogage au niveau des événements sont disponibles à des fins de test dans la version Preview développeur 9 de la Privacy Sandbox. Les rapports de débogage sont compatibles avec tous les appareils sur lesquels l'identifiant publicitaire est disponible.
L'objectif à long terme est d'autoriser la plate-forme à communiquer les résultats des enchères avec le service Private Aggregation. Cela garantit que le rapport a posteriori ne peut pas être utilisé pour associer les audiences personnalisées d'utilisateurs individuels à l'appli de l'éditeur. Les rapports au niveau des événements sont temporaires, jusqu'à ce qu'un framework de rapports approprié soit disponible.
En savoir plus sur la création de rapports de débogage dans la phase d'évaluation d'origine de FLEDGE de Chrome
Utilisation
Les rapports de débogage sont mis en œuvre à l'aide des API JavaScript suivantes, qui acceptent un argument de chaîne d'URL :
forDebuggingOnly.reportAdAuctionWin(String url)forDebuggingOnly.reportAdAuctionLoss(String url)
L'exemple suivant indique une perte d'enchères publicitaires avec l'enchère gagnante et une variable interne. Ces données peuvent ensuite être utilisées à des fins de débogage.
let someDebuggableVariable = 123;
const url = "https://example.com/reportLoss?winningBid=${winningBid}&someDebuggableVariable=" + someDebuggableVariable;
forDebuggingOnly.reportAdAuctionLoss(url);
Le modèle ${winningBid} est remplacé par la valeur réelle une fois l'enchère terminée.
Les vendeurs peuvent éventuellement renvoyer une rejectReason à partir de leur fonction scoreAds :
function scoreAd(ad, bid, auction_config, seller_signals,
trusted_scoring_signals, contextual_signal,
custom_audience_signal) {
let score = ...
return {
'status': 0,
'score': score,
'rejectReason': 'blocked-by-publisher'
}
}
Si un vendeur ne définit pas de motif de refus, not-available est envoyé à la place.
Variables URL
Les variables qui peuvent être ajoutées à l'URL de débogage correspondent à leurs équivalents dans Chrome (bien que ${topLevelWinningBid} et ${topLevelMadeWinningBid} ne sont pas disponibles, car il n'existe pas de système d'enchères de composants sur Android).
| Nom de la variable | Description |
winningBid |
Valeur de l'enchère gagnante. |
madeWinningBid |
Valeur booléenne indiquant si l'acheteur de cette audience personnalisée a défini l'enchère gagnante soit par cette audience personnalisée, soit par une autre audience personnalisée ayant le même acheteur. |
highestScoringOtherBid |
Valeur de l'enchère évaluée comme étant la deuxième plus élevée par le script scoreAd du vendeur. Notez qu'il ne s'agit peut-être pas de la deuxième valeur d'enchère la plus élevée, car les scores et les enchères peuvent être indépendants. |
madeHighestScoringOtherBid |
Valeur booléenne indiquant si l'acheteur de cette audience personnalisée a fait l'enchère ${highestScoringOtherBid}, soit par cette audience personnalisée, soit par une autre audience personnalisée associée au même acheteur. |
rejectReason |
Chaîne facultative définie par un vendeur et expliquant pourquoi il a refusé une enchère. Peut correspondre aux valeurs suivantes :
|
Contraintes
- L'hôte de l'URL doit correspondre au domaine Privacy Sandbox enregistré.
- L'URL ne doit pas dépasser 4 096 caractères, domaine inclus, un
https://le préfixe et les données d'enchères substituées. - Dans les prochaines versions, les pings de débogage ne seront envoyés que lorsque vous serez connecté au Wi-Fi.
Comportement sur l'appareil
Dans un environnement mobile, la protection de la mémoire et de l'utilisation du réseau est une priorité essentielle. Par conséquent, les rapports de débogage s'effectuent par lots.
Les propriétés système suivantes contrôlent le tarif et la taille de lot, qui peuvent être ajustés en fonction de valeurs inférieures pour le développement :
fledge_event_level_debug_reporting_batching_ratefledge_event_level_debug_reporting_batch_size
La latence estimée d'un rapport de débogage est comprise entre 15 et 60 minutes après la fin d'une enchère.
L'exhaustivité des rapports de débogage n'offre aucune garantie stricte. Si l'appareil redémarre ou que le processus adservices plante avant l'envoi d'appels au serveur, ces événements sont ignorés.
Chaque technologie publicitaire est limitée à 75 URL de débogage enregistrées par mise aux enchères. Les URL enregistrées après cette limite sont supprimées sans notification.
Enfin, si l'utilisateur a désactivé l'identifiant publicitaire, les rapports de débogage sont envoyés. Cette fonctionnalité ne sera pas implémentée dans la version Preview développeur 9, mais elle le sera dans les futures versions.
Comportement du serveur de technologie publicitaire
Les serveurs de technologie publicitaire doivent adopter les comportements suivants pour les rapports de débogage :
- L'appareil envoie des requêtes GET au serveur que vous spécifiez à l'aide des API
forDebuggingOnly.*. - Chaque demande ne représente qu'un seul rapport de débogage au niveau de l'événement : un seul gain d'enchères publicitaires ou une seule perte d'enchères.
- Chaque requête n'a pas de corps. Toutes les données se trouvent dans les paramètres de requête.
- Les charges utiles de réponse volumineuses peuvent être ignorées et avoir un impact négatif sur les performances et la consommation de données.