Protected Audience: guía de integración

Por lo general, Protected Audience (que anteriormente se denominaba FLEDGE) en las implementaciones de Android suele incluir la integración entre las apps del anunciante, las del publicador, los vendedores y los compradores. Esta guía está destinada a los socios que planean administrar públicos personalizados y ejecutar subastas, incluidas las redes de tecnología publicitaria que operan como compradores y vendedores. Las diferentes campañas de anuncios pueden tener diferentes objetivos, y no todas las funciones de Protected Audience se utilizan para todos los casos de uso. En esta guía, se destacan los pasos necesarios para admitir casos más especializados siempre que sea posible.

Para prepararse para la implementación de producción a gran escala de Protected Audience, los socios pueden comenzar a realizar pruebas simulando los puntos de integración con otras partes. Para ayudarte con la planificación de la integración, esta guía proporciona una vista integral de cómo integrar Protected Audience con tus apps para Android. Esto puede incluir funciones que aún no se implementaron en la etapa actual de Privacy Sandbox en la Versión preliminar para desarrolladores de Android. En estos casos, se proporciona orientación sobre el cronograma.

El flujo de trabajo de integración de Protected Audience consta de 4 pasos clave generados por diferentes tipos de socios de tecnología publicitaria:

1. El comprador crea públicos personalizados.
2. El proceso de selección de anuncios elige un anuncio ganador.
   1. La app del vendedor inicia la selección de anuncios.
   2. Los servicios de anuncios ejecutan el código de oferta y el filtro orientados a la compra.
   3. Los servicios de anuncios ejecutan el código de decisión orientado a la venta.
3. El anuncio ganador se renderiza en la app del vendedor.
4. Los informes de las impresiones de anuncios se ponen a disposición del comprador y del vendedor.

En el siguiente diagrama, se ilustran estos pasos:

El flujo de trabajo personalizado de administración de públicos y selección de anuncios de Protected Audience.

Terminología

• Anunciante: Es una empresa que interactúa con los usuarios a través de una compra de inventario de anuncios.
• Publicador: Es una empresa que vende inventario de anuncios que está disponible junto con su contenido.
• Comprador: Es una empresa de tecnología publicitaria que facilita a los anunciantes la compra de inventario de anuncios.
• Vendedor: Es una empresa de tecnología publicitaria que facilita a los publicadores la venta de inventario de anuncios.
• Red: Es una empresa de tecnología publicitaria que actúa como comprador y vendedor.
• Administrado y propiedad: Es una empresa que actúa como publicador, vendedor y comprador.
• Socios de integración: Es cualquier empresa con la que necesitas trabajar para integrarte con Protected Audience de forma exitosa.

Requisitos previos, participación de los socios de integración y configuración

En esta sección, se describe un conjunto de actividades iniciales para ayudarte a comprender cómo funciona Protected Audience, cómo comenzar a usar la integración de Protected Audience y cómo interactuar con tus socios de integración en una implementación de Protected Audience. Estas actividades pueden ocurrir en paralelo.

Guía de lanzamiento de las funciones de Protected Audience.

Familiarízate con Protected Audience

El primer paso es familiarizarte con las APIs y los servicios de Protected Audience.

1. Comienza por leer la propuesta de diseño para conocer la API de Protected Audience y sus capacidades.
2. Lee la guía para desarrolladores para aprender a incorporar el código y las llamadas a la API que necesitas en tus casos de uso, así como los servicios necesarios a los efectos de integrarlos con Protected Audience.
3. Envía comentarios sobre el diseño y la implementación de las APIs, los servicios y la documentación de Protected Audience.
4. Regístrate para recibir actualizaciones y mantenerte al día con las funciones más recientes de Privacy Sandbox.

Configura y prueba apps de ejemplo

Una vez que conozcas los conceptos básicos de Protected Audience tal como se describió antes, debes configurar y probar las apps de ejemplo.

1. Cuando esté todo listo para comenzar la integración, configura tu entorno de desarrollo con la Versión preliminar para desarrolladores de Privacy Sandbox más reciente.
2. Configura los extremos del servidor necesarios. Usa las muestras de ejemplo con tu solución de prueba de API preferida para iniciar este proceso.
3. Bifurca y ejecuta el código en nuestra app de ejemplo para familiarizarte con la administración de públicos personalizados, el flujo de trabajo de selección de anuncios y los informes de impresiones.

Participación de los socios de integración

Programa debates con tus socios de integración para analizar las pruebas y la adopción de Protected Audience en Android, incluida la forma de los indicadores que se pasan entre las partes. En el caso de los compradores, los debates deben incluir estrategias para crear públicos personalizados y unirse a ellos, lo que puede incluir debates acerca de la definición de los públicos. Colabora con tus socios de integración para definir cronogramas de integración, desde las pruebas iniciales hasta la adopción, y las áreas de las que cada parte será responsable en el diseño.

Configuración beta (disponible en el cuarto trimestre)

Registra tu organización con Privacy Sandbox en Android. La inscripción es necesaria para garantizar que los desarrolladores de tecnología publicitaria cumplan las políticas de Privacy Sandbox, y les permite definir su identidad en varios SDKs y dominios.

Consideraciones de la arquitectura

Para compradores y vendedores, Protected Audience presenta la capacidad de ejecutar subastas de anuncios en el dispositivo. Tú y tus socios de integración deben tener en cuenta varias consideraciones fundamentales en tus diseños:

Los públicos y los anuncios de remarketing se almacenan en el dispositivo

A diferencia de lo que sucede actualmente con el almacenamiento de anuncios en los servidores, la información del público y los anuncios de remarketing se almacenan en el dispositivo. Los anuncios contextuales que no dependen de los datos del dispositivo para la orientación continuarán estando en los servidores. Las plataformas de tecnología publicitaria deben expandirse para considerar la demanda de anuncios que se distribuye entre los servidores y los dispositivos.

Los procesos de licitación y subastas se llevan a cabo en el dispositivo

Además de ejecutar subastas en servidores, las plataformas de tecnología publicitaria ahora tienen la oportunidad de definir el precio y clasificar la demanda de anuncios almacenada en el dispositivo.

Un enfoque común consiste en que las plataformas de tecnología publicitaria publiquen subastas para anuncios contextuales como lo hacen en la actualidad. Después de completar la subasta, el vendedor puede elegir realizar una subasta en el dispositivo para evaluar la demanda de remarketing almacenada en él. Dado que estos procesos ahora se ejecutan en el dispositivo, es importante recordar los límites existentes establecidos para garantizar que las subastas se ejecuten de principio a fin según el diseño de los diferentes socios de integración, en una variedad de casos de uso de remarketing.

Estrategia de datos

Las plataformas de tecnología publicitaria deben considerar los tipos de datos que se usan en las subastas. En la actualidad, esta información se recopila de varias fuentes y, luego, se centraliza en un servidor. Las subastas de Protected Audience ofrecen varias rutas diferentes para pasar esos datos. Por ejemplo, los indicadores En tiempo real, como el presupuesto restante, provienen de un servicio de par clave-valor como indicadores de confianza, mientras que a los indicadores contextuales, como la hora del día, los envían los vendedores cuando se ejecuta una subasta. Estos indicadores se explican con más detalle en las secciones relevantes de esta guía.

Cómo compilar tu solución

Existen varias etapas clave para ejecutar una subasta con Protected Audience. Los compradores deben crear el público, proporcionar datos de ofertas, segmentar anuncios a públicos y configurar las ofertas. El vendedor debe configurar y activar la subasta, calificar los anuncios candidatos y seleccionar un ganador. Algunas de estas etapas requieren colaboración entre ambas partes para garantizar que la subasta se pueda ejecutar correctamente. En las siguientes secciones, se describe cada etapa en detalle y se menciona de forma explícita qué parte es responsable de la implementación.

Compradores: Cómo crear un público

Los compradores suelen administrar públicos personalizados. Dado que los públicos personalizados se administran en el dispositivo, la API que permite administrarlos se diseñó para invocarse en el dispositivo.

Si cuentas con tu propio SDK en la app de anunciantes, puedes implementar este código directamente a través de joinCustomAudience().

Si no tienes tu propio código de SDK en dispositivos, puedes asociarte con un socio de integración existente que también sea un proveedor del SDK. Identifica este socio y trabaja con él para definir un contrato y un flujo que permita definir y administrar públicos personalizados. En esta guía, se usa el término "comprador", independientemente del enfoque que se use. Algunos ejemplos de enfoques incluyen:

• Como comprador, pídele al anunciante que defina el público. Un SDK de socio de integración en el dispositivo puede enviar eventos de la app al comprador. Cuando se cumplen los criterios predefinidos, el comprador envía un mensaje al SDK para unirse al público personalizado en el cliente en nombre del comprador.
• El SDK puede ser propietario directo del público. Los anunciantes trabajan con un proveedor del SDK para definir el público. El SDK supervisa los eventos de la app, se une al público en el momento adecuado y notifica al comprador que un usuario se unió al público.

Prototipo de campaña de remarketing: Diseña un público personalizado

Un público personalizado es una agrupación de usuarios con intereses similares a los que se les pueden publicar anuncios personalizados. Los compradores pueden ayudar a los anunciantes a crear públicos personalizados en sus apps según la actividad del usuario.

Protected Audience establece un contenedor para el público personalizado que se asigna a una participación del usuario personalizada específica, según lo que definió el anunciante. Esto incluye una colección de anuncios candidatos que se pueden mostrar a ese público, así como una colección de lógica de ofertas personalizadas y datos que se pueden usar durante una subasta para filtrar los anuncios y establecer sus precios.

Configuración y prototipo

• Usa la API de público personalizado para crear y almacenar en el dispositivo un público que se pueda usar en una subasta más adelante.
• Consulta la guía para desarrolladores para conocer los detalles de implementación y uso de la API.

Consideraciones de diseño

Los compradores pueden admitir una variedad de casos de uso configurando públicos personalizados. Esto incluye la definición de la lógica de ofertas para el tipo de anuncio o campaña en función de los que se segmenta este público, así como la definición de la lista de anuncios candidatos y otras consideraciones similares. En esta sección, se incluyen consideraciones de diseño para propagar y usar algunos campos clave en un público personalizado.

URL de lógica de ofertas

Dado que las subastas se ejecutan en el dispositivo, los compradores deben implementar un extremo que pueda mostrar una lógica de ofertas como JavaScript. En nuestra guía para desarrolladores, se describen las firmas de método obligatorias. La lógica de ofertas tiene acceso a ciertos indicadores sobre el usuario durante la subasta, como se describe en las siguientes secciones. La lógica de ofertas y la configuración de los indicadores de usuarios se explican más adelante en este artículo.

Indicadores de ofertas del usuario

Los compradores pueden usar UserBiddingSignals para transmitir información que el anunciante o el comprador tienen sobre el usuario a subastas futuras en el dispositivo. Esto puede incluir información como la siguiente:

• Otros públicos a los que se agregó el usuario
• Estadísticas propias que el anunciante tiene sobre el usuario

Debido a que estos indicadores están disponibles durante la subasta, los compradores pueden realizar operaciones de ofertas personalizadas durante este proceso, incluidas las siguientes:

• Aumentar o disminuir la oferta según los indicadores correspondientes
• Filtrar anuncios específicos de la subasta

Datos de ofertas de confianza

Como parte de la implementación de Protected Audience, los compradores pueden acceder a la información en tiempo real durante la subasta desde un servicio de par clave-valor. Como mecanismo temporal, el comprador y el vendedor pueden recuperar estos indicadores de ofertas de cualquier servicio, incluidos los que ellos mismos operan. El ejemplo más común consiste en buscar el presupuesto restante para los anuncios. Durante el desarrollo, es posible simular este servicio, y puedes desarrollarlo a partir de este extremo de muestra. Consulta el directorio FledgeServerSpec en nuestro repositorio de apps de ejemplo en GitHub para obtener las instrucciones de configuración.

El campo TrustedBiddingData se compone de una URL y un conjunto de claves. Estas son algunas consideraciones que debes tener en cuenta a la hora de diseñar el tipo de estructura clave que usarás:

• Un enfoque simple consiste en incluir una clave que asigne 1:1 al público que se crea. El servicio de par clave-valor puede contener toda la información relevante asociada con el público.
• El presupuesto y el estado del anuncio son aspectos importantes que se deben considerar en tiempo real.
• El importe máximo de la oferta y otros indicadores se pueden usar para establecer el precio de un anuncio en una subasta. Es posible incluir esta información con el anuncio en una lista AdData, pero almacenarla en un servicio de par clave-valor permite que se actualice con mayor facilidad según sea necesario.

Lista de AdData

A la hora de crear una campaña de remarketing, por lo general, los anunciantes consideran muchos tipos diferentes de anuncios para mostrar a un usuario en un público (por ejemplo, diferentes descuentos basados en la participación previa del usuario en la app). Un público personalizado incluye una lista de AdData que contiene anuncios candidatos.

La cantidad de información que se debe incluir para cada anuncio depende de lo que decidan los compradores. Estos son algunos puntos que debes tener en cuenta:

• La lista de AdData se puede actualizar de 2 maneras:
  • Cuando la app tiene una actividad visible en primer plano, puede iniciar la lista cuando une un usuario a un público personalizado.
  • Durante una actualización diaria, la recuperación se inicia en segundo plano. El dispositivo envía una solicitud al daily_update_url incluido en la llamada a joinCustomAudience y espera una respuesta que incluya una lista actualizada de AdData.
• Se puede solicitar información adicional sobre los anuncios al momento de la subasta. Antes de la subasta, el dispositivo envía una solicitud al servicio de par clave-valor del comprador que se proporcionó en el campo trustedBiddingData de joinCustomAudience. El servicio de par clave-valor es un servicio nuevo que forma parte de la implementación de Protected Audience de los compradores. Puedes encontrar más detalles sobre este servicio más adelante en este documento.
• Incluir un ID de creatividad para tu anuncio puede ayudarte a realizar ciertas acciones en creatividades específicas. Por ejemplo, los anunciantes pueden detener creatividades específicas, y tú quieres extraer esos IDs de creatividad del servicio de par clave-valor en tiempo real y, luego, segmentarlos en función de los anuncios de la lista de AdData.

AdData debe incluir una render_url. La URL de renderización del anuncio de remarketing ganador se usa para renderizar el anuncio. Algunas consideraciones incluyen lo siguiente:

• La URL de renderización tiene un umbral de k-anonimato, por lo que debes evitar incluir parámetros limitados. Se publicará más información sobre este umbral de k-anonimato más adelante.
• Esta URL debe contener toda la información necesaria para renderizar el anuncio. Por ejemplo, si quieres mostrar productos específicos, incorpora los IDs de producto como parámetros en la URL.

Durante el prototipado, el único campo obligatorio es renderUri, que apunta a los recursos de renderización del anuncio. El campo de metadatos de AdData se puede ignorar mientras creas la solución. A medida que mueves tu solución hacia la producción, debes considerar qué metadatos son relevantes, ya que se pueden usar durante la generación de ofertas para ajustar tu precio de oferta.

Hora de activación y hora de vencimiento

Puedes usar los campos de horas de activación y de vencimiento para admitir casos de uso en los que un público personalizado solo debería poder participar en subastas durante un tiempo predefinido. Ten en cuenta que existen ciertas limitaciones en relación a cuánto se puede demorar un tiempo de activación, así como al delta entre la hora de activación y la de vencimiento. Como ejemplo, se incluyen los siguientes casos de uso:

• Usuario inactivo (p.ej., un usuario que no interactuó con la app del anunciante en los últimos 7 días)
  • Cada vez que el usuario abre la app, el comprador puede llamar a joinCustomAudience y configurar activation_time como una marca de tiempo de 7 días en el futuro.
  • El público será apto para ofertar si pasaron 7 días desde que el usuario abrió la app por última vez.
• Público de temporada (un público que solo es válido durante un período específico en el futuro cercano)
  • Un comprador puede comenzar a definir públicos personalizados por adelantado que solo deben ser aptos para ofertar durante un tiempo predeterminado en el futuro (cercano).
  • Por ejemplo, si un anunciante tiene una campaña de fin de verano en los Estados Unidos en 2022, su comprador puede llamar a joinCustomAudience y configurar activation_time como el sábado 20 de agosto de 2022. Si la campaña solo se ejecutará durante una semana, el comprador puede establecer la fecha de vencimiento al 27 de agosto de 2022, después de la cual la plataforma filtrará el público personalizado durante la selección de anuncios y, finalmente, lo asignará para la recolección de elementos no utilizados.

Compradores y vendedores: Cómo seleccionar anuncios

La selección de anuncios requiere la colaboración entre compradores y vendedores. Esto se puede ver como un proceso de cuatro pasos:

1. Los vendedores definen una estrategia de mediación.
2. Los vendedores configuran la subasta e inician la selección de anuncios.
3. Se invita a los compradores a participar en la subasta a través de la configuración que el vendedor defina. Se ejecuta la lógica de ofertas del comprador para seleccionar un anuncio y una oferta candidatos.
4. Se ejecuta la lógica de decisión del vendedor para calificar a los candidatos y seleccionar un anuncio ganador.

Con el objetivo de facilitar el desarrollo, es posible simular respuestas de servicio para compradores y vendedores, lo que incluye la lógica de ofertas y puntuación, y te permite enfocarte en desarrollar lo que es relevante para tu caso de uso. Consulta el directorio FledgeServerSpec en GitHub y obtén instrucciones para configurar extremos de muestra, o bien la guía para desarrolladores si necesitas instrucciones para anular la necesidad de recuperar JavaScript de forma remota.

Vendedores: Cómo definir la estrategia de mediación

El objetivo de Protected Audience es admitir la mediación en cascada. Esta área está en desarrollo, y se proporcionará más información cuando esté disponible. Por ahora, consulta la propuesta de diseño para la mediación en cascada en Protected Audience.

Vendedores: Cómo configurar la subasta

Los vendedores son responsables de configurar la subasta y proporcionar información al proceso de selección de anuncios. Los vendedores pueden elegir que la información esté disponible para todas las partes o solo para algunas seleccionadas. Esto puede incluir información que tengas o que incluyas en nombre de los compradores.

Configuración y prototipo

• Un vendedor puede configurar e iniciar una subasta mediante la configuración de un objeto AdSelectionConfig y el uso de la API de AdSelection. Invoca selectAds() para activar la subasta.
• Consulta la guía para desarrolladores para conocer los detalles de implementación y uso de la API.

Consideraciones de diseño

En esta sección, se incluyen consideraciones de diseño para propagar y usar campos clave en una configuración de selección de anuncios.

• El entorno de ejecución privado solo incluye anuncios para público personalizado en el dispositivo, por lo que emitir una solicitud previa de anuncios contextuales te permitirá considerar una demanda adicional.

• Antes de iniciar el flujo de trabajo de selección de anuncios, ejecuta una solicitud de anuncio para recopilar información de los compradores. Luego, usa esta información para configurar la selección de anuncios.

• Dado que muchos compradores podrían haber creado públicos personalizados en el dispositivo, los vendedores deben usar el campo Compradores de públicos personalizados para indicar qué compradores específicos incluir en el proceso. Hay muchas formas de crear esta lista. Aquí encontrarás algunos ejemplos:

  • Una lista estática de compradores que el vendedor siempre desea incluir en el proceso
  • Una lista de compradores que indica su deseo de participar en la respuesta de solicitud de anuncio. Esta opción es útil si el vendedor trabaja con Ad Exchange y quizás no tiene conocimiento completo de todos los compradores.

• El vendedor puede pasar información al proceso de varias maneras:

  • El campo de indicadores de selección de anuncios está disponible para todos los compradores y para el vendedor que participa en la subasta en el tiempo de ejecución privado. Úsalo para proporcionar información sobre la oportunidad del anuncio, como su tamaño y formato.
  • El campo indicadores por comprador se reenvía al comprador específico para que se utilice en su proceso de oferta. Esta información es proporcionada por el comprador, y tú, como vendedor, debes considerar cómo obtener esta información en el dispositivo para usarla durante la selección de anuncios.
  • El campo indicadores del vendedor es la última forma en la que el vendedor pasa información al proceso. Como vendedor, usas estos indicadores cuando calificas y filtras anuncios, como habilitar una verificación de seguridad de la marca.

Compradores: Cómo ofertar para un espacio publicitario

Configuración y prototipo

• Un comprador puede agregar su lógica de ofertas a la función generateBid() de JavaScript que se entrega desde el parámetro biddingLogicUrl configurado cuando se compila un CustomAudience. Puedes establecer un servicio simulado usando las especificaciones proporcionadas o implementar este extremo en un servidor real.
• Consulta la guía para desarrolladores para conocer los detalles de implementación y uso de la API.

Consideraciones de diseño

• La lógica de ofertas se ejecuta en el dispositivo, y algunos de los indicadores utilizados en la subasta se consultan en tiempo real. Consulta la lista de limitaciones para conocer las restricciones.
• En algunos casos de uso de anuncios, es importante trabajar con el vendedor para asegurarse de tener varios candidatos de anuncios y sus ofertas para que se consideren en el dispositivo.

Cómo diseñar la lógica de ofertas

La lógica de ofertas de los compradores debe implementarse a través de JavaScript y se ejecuta en el dispositivo. La guía para desarrolladores contiene información sobre la firma obligatoria y detalles sobre los diversos parámetros que se pasaron durante la subasta. La lógica de ofertas en el dispositivo tiene acceso a información adicional que se pasa como parámetros a la función generateBid().

Brinda datos de ofertas

Indicadores de ofertas en tiempo real con servicios de par clave-valor

Como comprador, puedes recuperar indicadores en tiempo real durante una subasta desde un servicio de par clave-valor que te pertenezca. Puedes encontrar una implementación inicial de este servicio en el repositorio público de Privacy Sandbox o puedes crear uno propio. La URL de este servicio se especifica como trustedBiddingUrl en un público personalizado, y la plataforma intenta recuperar los datos y hacer que estén disponibles para la función generateBid con el trusted_bidding_signals parameter. Debes establecer tu propia estructura clave.

Indicadores contextuales y del usuario

Tu función generateBid tiene acceso a indicadores adicionales del usuario cuando ejecuta la subasta en el dispositivo. Estos indicadores se pasan con los campos contextual_signals y per_buyer_signals. Todos estos campos son objetos JSON con formato definido por compradores y vendedores.

El campo contextual_signals incluye información que puede ser relevante sobre el usuario. Protected Audience crea el objeto que contiene estos indicadores y lo pasa a tu lógica de ofertas. Actualmente, se pasa como un objeto vacío. Si crees que un indicador contextual sobre el usuario podría ser relevante para tu caso de uso, envía comentarios para que los evaluemos.

El campo per_buyer_signals está disponible para tu lógica de ofertas. Un vendedor establece estos valores cuando crea la configuración de la subasta. Los compradores y vendedores deben colaborar para asegurarse de que estos datos estén en el dispositivo y se pasen a tu lógica de ofertas. Estos son algunos ejemplos de uso de este campo:

• Filtrado para seguridad de la marca: el vendedor puede brindar a los compradores cierta información de clasificación sobre la app que solicita un anuncio, y el comprador puede usar esta información para filtrar ciertos anuncios
• Envío de una incorporación para un modelo de AA que considere información contextual

Vendedores: Cómo puntuar y seleccionar el anuncio ganador

Configuración y prototipo

• Un vendedor puede agregar su lógica de puntuación a la función scoreAd() de JavaScript que se entrega desde el parámetro scoringLogicUrl configurado cuando se compila el AdSelectionConfig. Puedes establecer un servicio simulado usando las especificaciones proporcionadas o implementar este extremo en un servidor real.
• Consulta la guía para desarrolladores para conocer los detalles de implementación y uso de la API.

Cómo diseñar la lógica de puntuación

Los vendedores implementan la lógica de puntuación en JavaScript, que se ejecuta en el dispositivo. La guía para desarrolladores contiene información sobre la firma obligatoria y detalles sobre los diversos parámetros que se pasaron durante la subasta. Además, la lógica de puntuación en el dispositivo tiene acceso a información adicional que se pasa como parámetros a la función scoreAd.

Brinda datos de puntuación

Indicadores de puntuación en tiempo real con servicios de par clave-valor

Como vendedor, puedes recuperar indicadores en tiempo real durante una subasta desde un servicio de par clave-valor que te pertenezca. Puedes encontrar una implementación inicial de este servicio en el repositorio público de Privacy Sandbox. La URL de este servicio se especifica como trustedScoringUri en la configuración de la subasta, y la plataforma intenta recuperar los datos y hacer que estén disponibles para tu función scoreAd a través del parámetro trusted_scoring_signals. Debes establecer tu propia estructura clave.

Indicadores contextuales y del usuario

Tu función scoreAd tiene acceso a indicadores adicionales del usuario cuando ejecuta la subasta en el dispositivo. Estos indicadores se pasan a la función de puntuación a través del campo contextual_signal. Este campo contiene objetos JSON con formato definido por compradores y vendedores.

El campo contextual_signal incluye información contextual que puede ser relevante sobre el usuario. Protected Audience crea el objeto que contiene estos indicadores y lo pasa a tu lógica de puntuación. Se pasa como un objeto vacío. Si crees que un indicador sobre el usuario podría ser relevante para tu caso de uso, envía comentarios para que los evaluemos.

Vendedores: Cómo renderizar un anuncio

Los vendedores deben renderizar el anuncio ganador. Consulta la propuesta de diseño y obtén detalles adicionales para renderizar los anuncios ganadores. Esta área aún está en proceso de diseño.

Cómo informar resultados de impresiones

Configuración y prototipo

• Los compradores y vendedores pueden agregar la lógica de informes a la función reportWin() de JavaScript que se entrega desde los parámetros biddingLogicUrl o scoringLogicUrl, respectivamente. Puedes establecer un servicio simulado usando las especificaciones proporcionadas o implementar este extremo en un servidor real.
• Consulta la guía para desarrolladores para conocer los detalles de implementación y uso de la API.

Consideraciones de diseño

Los compradores y vendedores deben implementar una función reportWin en el código JavaScript que muestran los extremos configurados. Este método te permite enviar datos de vuelta a tus servidores.

Privacy Sandbox también proporciona una API de Attribution Reporting para administrar informes agregados y de nivel de eventos. Consulta la guía de integración para obtener más detalles.