Los informes de depuración de Protected Audience permiten que los desarrolladores de tecnología publicitaria declaren URL remotas para recibir una solicitud GET de los dispositivos cuando se gana o se pierde una subasta. Esto permite los siguientes casos de uso:
- Recibir informes de los resultados de subastas ganadas o perdidas
- Comprender por qué se pierden las subastas (por ejemplo, entender si se trata de un problema con la implementación de una oferta o de una secuencia de comandos de puntuación, o un problema de lógica principal)
- Descubrir problemas cuando se actualiza la lógica de JavaScript
Los informes de depuración a nivel del evento están disponibles para realizar pruebas en Privacy Sandbox en la Versión preliminar para desarrolladores 9. Los informes de depuración son compatibles con todos los dispositivos en los que está disponible el ID del anuncio.
El plan a largo plazo es permitir que la plataforma informe los resultados de la subasta con el servicio de agregación privada. Esto garantiza que los informes posteriores no se puedan usar para unir los públicos personalizados de usuarios individuales a la app del publicador. Los informes a nivel del evento serán temporales hasta que se lance un framework de informes adecuado.
Obtén más información sobre los informes de depuración en la propuesta original de prueba de origen de FLEDGE de Chrome.
Uso
Los informes de depuración se implementan con las siguientes APIs de JavaScript, que toman un argumento de cadena de URL:
forDebuggingOnly.reportAdAuctionWin(String url)forDebuggingOnly.reportAdAuctionLoss(String url)
En el siguiente ejemplo, se informa una pérdida de subasta de anuncios con la oferta ganadora y una variable interna. Estos datos se pueden usar con fines de depuración.
let someDebuggableVariable = 123;
const url = "https://example.com/reportLoss?winningBid=${winningBid}&someDebuggableVariable=" + someDebuggableVariable;
forDebuggingOnly.reportAdAuctionLoss(url);
La plantilla ${winningBid} se sustituye por el valor real después de que se completa la subasta.
De manera opcional, los vendedores pueden mostrar un rejectReason desde su función 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 vendedor no establece un motivo del rechazo, se envía not-available.
Variables de URL
Las variables que se pueden agregar a la URL de depuración correspondan a sus equivalentes en Chrome (aunque ${topLevelWinningBid} y ${topLevelMadeWinningBid} no están disponibles, ya que no hay un concepto de las subastas de componentes en Android).
| Nombre de la variable | Descripción |
winningBid |
Es el valor de la oferta ganadora. |
madeWinningBid |
Es un valor booleano que representa si el comprador de este público personalizado realizó la oferta ganadora, haya sido este público personalizado, o bien otro distinto con el mismo comprador. |
highestScoringOtherBid |
Es el valor de la oferta que obtuvo la segunda puntuación más alta según la secuencia de comandos scoreAd del vendedor. Ten en cuenta que tal vez este no sea el segundo valor de oferta más alto, ya que las puntuaciones y las ofertas pueden ser independientes. |
madeHighestScoringOtherBid |
Es un valor booleano que representa si el comprador de este público personalizado hizo la oferta ${highestScoringOtherBid}, haya sido este público personalizado, o bien otro distinto con el mismo comprador. |
rejectReason |
Es una cadena opcional que estableció un vendedor para explicar por qué se rechazó una oferta. Puede ser cualquiera de los siguientes valores:
|
Restricciones
- El host de la URL debe coincidir con el dominio de Privacy Sandbox inscrito.
- La URL no debe superar los 4,096 caracteres, incluidos el dominio, un prefijo
https://y los datos de subasta sustituidos. - En versiones futuras, los pings de depuración solo se envían cuando hay una conexión Wi-Fi establecida.
Comportamiento en el dispositivo
En un entorno de dispositivos móviles, proteger el uso de la red y la memoria es una prioridad. Por lo tanto, los informes de depuración se realizan en lotes.
Las siguientes propiedades del sistema controlan la velocidad y el tamaño del lote, que se pueden ajustar a valores más bajos para el desarrollo:
fledge_event_level_debug_reporting_batching_ratefledge_event_level_debug_reporting_batch_size
La latencia esperada de un informe de depuración es de entre 15 y 60 minutos después de que se completa una subasta.
No hay garantías estrictas sobre la finalización de los informes de depuración. Si el dispositivo se reinicia o el proceso de los servicios de anuncios falla antes de que se envíen las llamadas al servidor, se descartarán estos eventos.
Cada tecnología publicitaria tiene un límite máximo de 75 URLs de depuración registradas por subasta. Las URLs registradas después de que se alcanza ese límite se descartan en silencio.
Por último, si el usuario inhabilitó el AdId, se enviarán los informes de depuración. Esto no se implementa en la Versión preliminar para desarrolladores 9, pero se implementará en versiones futuras.
Comportamiento del servidor de tecnología publicitaria
Los servidores de tecnología publicitaria deben tener los siguientes comportamientos para los informes de depuración:
- El dispositivo envía solicitudes GET al servidor que especificas con las APIs de
forDebuggingOnly.*. - Cada solicitud representa un solo informe de depuración a nivel del evento: una sola subasta de anuncios o la pérdida de una subasta.
- Cada solicitud no tiene cuerpo. Todos los datos se encuentran en los parámetros de consulta.
- Las cargas útiles de respuesta grandes se ignoran, ya que pueden afectar de manera negativa el rendimiento y el uso de datos.