A todos les conviene asegurarse de que la API de Protected Audience funcione de manera eficiente:
- Las personas que navegan por la Web quieren que los sitios se carguen rápidamente. Esto significa que los desarrolladores deben compilar con la API de Protected Audience de manera eficiente para no sobreutilizar los recursos limitados del dispositivo, como los recursos de procesamiento o de red, que son necesarios para cargar los sitios y sus anuncios integrados.
- Los publicadores quieren que sus sitios se carguen rápidamente para brindar a los usuarios una experiencia eficiente y con buena capacidad de respuesta. Los publicadores también desean que la publicidad sea eficaz para maximizar sus ingresos.
- Los anunciantes y las tecnologías publicitarias quieren que sus anuncios se muestren rápidamente para brindar la mayor utilidad.
En este documento, se describen algunas prácticas recomendadas para implementar la API de Protected Audience y garantizar que tu sitio funcione con la máxima eficiencia.
Prácticas recomendadas para los compradores (ofertantes)
Para asegurarte de que estás optimizando la eficiencia de las subastas de la API de Protected Audience, sigue estas prácticas recomendadas.
Menos propietarios de grupos de interés
Para proteger a los ofertantes de la API de Protected Audience de la misma manera en que el navegador protege diferentes orígenes en la Web con el aislamiento de sitios, el navegador usa recursos costosos (como los procesos del sistema operativo) para proteger a los propietarios de grupos de interés individuales.
Para minimizar el gasto de estos recursos tan costosos, es fundamental tener la menor cantidad posible de propietarios de grupos de interés. Evita tener diferentes grupos de interés que pertenezcan a varios subdominios. Por ejemplo, si adtech.example tuviera grupos de interés propiedad de cats.adtech.example y dogs.adtech.example, es probable que el navegador use dos procesos separados para ejecutar sus secuencias de comandos de ofertas.
Menos grupos de interés con ofertas
El navegador debe realizar una configuración y preparación significativas antes de invocar una secuencia de comandos generateBid() del comprador, como configurar un nuevo entorno de ejecución de JavaScript limpio y analizar y cargar el código generateBid().
- Los grupos de intereses que representan a los usuarios que no son el objetivo actual de una campaña publicitaria activa deben tener listas de creatividades de anuncios vacías. Esto evita que la API de Protected Audience ejecute
generateBid()para los grupos de interés sin anuncios relevantes. - Combinar grupos de interés similares disminuirá la cantidad de veces que se debe ejecutar
generateBid(). La propiedaduserBiddingSignalsde un grupo de interés se puede usar para almacenar metadatos adicionales sobre el usuario, por lo que tener menos grupos de interés no necesariamente significa que la segmentación sea menos eficaz. - La API de Protected Audience admite límites especificados por el vendedor en la cantidad de grupos de interés y una API para que los compradores especifiquen la prioridad relativa de sus grupos de interés. Estos límites se pueden usar para reducir significativamente la cantidad de secuencias de comandos de ofertas que se deben ejecutar.
Cómo filtrar grupos de interés de las ofertas en tu servicio de clave-valor
Si un comprador puede determinar en su servidor de indicadores de ofertas de confianza en tiempo real que ciertos grupos de interés no deben ofertar (p.ej., la campaña está inhabilitada, pausada o sin presupuesto, o no debe ofertar en este publicador en particular), puede indicarlo al navegador con la respuesta priorityVector a la recuperación de indicadores de ofertas de confianza. Si el producto escalar disperso resultante de priorityVector y prioritySignals es negativo, el navegador omitirá la invocación de generateBid() para este grupo de interés. Puedes obtener más información sobre este mecanismo en la sección"Filtrado y priorización de grupos de interés" del documento explicativo.
Cómo reutilizar el entorno de ejecución de JavaScript
Antes de que el navegador pueda ejecutar generateBid(), debe inicializar un nuevo entorno de ejecución de JavaScript. Este proceso puede tardar una cantidad de tiempo significativa, similar a la que puede tardar en ejecutarse un generateBid() mínimo. Este tiempo se puede ahorrar si se usan los modos de ejecución group-by-origin o frozen-context.
El modo group-by-origin puede reutilizar entornos de ejecución en los casos en que los grupos de interés se unen en el mismo origen y es probable que no requiera cambios en tu secuencia de comandos de ofertas. Para obtener más información, consulta la descripción de group-by-origin en el documento explicativo. El modo de contexto congelado puede reutilizar potencialmente todos los entornos de ejecución, pero es posible que requiera cambios en tu secuencia de comandos de ofertas. Para obtener más información, consulta la descripción de frozen-context en el explicador.
Cómo reutilizar secuencias de comandos de ofertas
Si es posible, usa la misma secuencia de comandos de ofertas para los grupos de interés. Esto evita que el navegador tenga que descargar, analizar y compilar varios secuencias de comandos (lo que genera solicitudes de red adicionales). Los postores pueden seguir diferenciando las ofertas en función de la información del grupo de interés (p.ej., name o userBiddingSignals) mientras usan la misma secuencia de comandos.
Sin los encabezados de control de caché HTTP, la secuencia de comandos de ofertas no se almacena en caché. Especifica los encabezados adecuados para garantizar que no se recupere la secuencia de comandos de forma innecesaria. Si hay varias subastas en la página que se ejecutan en paralelo, se volverá a usar la secuencia de comandos de ofertas del mismo ofertante si ya está en la memoria, y se ignorará la semántica del almacenamiento en caché. Si las subastas se ejecutan de forma secuencial, el navegador se adherirá al mecanismo de almacenamiento en caché de HTTP.
Ten en cuenta que el navegador carga la secuencia de comandos de ofertas durante el período de la oferta (para generateBid()) y también durante el período del informe (para reportWin()). Si no se configuran los encabezados de control de caché, el navegador recuperará la misma secuencia de comandos dos veces, una para cada período.
Por lo tanto, te recomendamos que establezcas encabezados de control de caché en todas tus secuencias de comandos.
Reutilizar trustedBiddingSignalsUrls
La latencia de la red y el uso de recursos pueden ser muy significativos. La reducción de las recuperaciones de indicadores de ofertas de confianza en tiempo real puede ayudar a reducir esta latencia.
Las recuperaciones de indicadores de ofertas confiables se pueden combinar cuando se reutiliza el trustedBiddingSignalsUrl entre varios grupos de interés.
Cuando sea posible, usa el mismo trustedBiddingSignalsUrl para todos los grupos de interés.
Especifica los encabezados de control de caché HTTP adecuados para garantizar que las recuperaciones de indicadores de ofertas confiables se almacenen en caché en los espacios publicitarios de una página web en particular. Evita configurar trustedBiddingSignalsSlotSizeMode como slot-size, ya que esto impedirá el almacenamiento en caché en las ranuras de anuncios cuando los tamaños de las ranuras difieran porque la URL solicitada será diferente.
Recuperaciones más pequeñas de indicadores de ofertas confiables en tiempo real
La latencia de la red puede ser muy significativa, y se ve afectada directamente por la cantidad de datos que se transfieren durante las recuperaciones de indicadores de ofertas de confianza en tiempo real.
Es preferible almacenar los datos específicos de los anuncios o de los grupos de interés en el grupo de interés, en lugar de hacerlo en el servicio de indicadores de ofertas de confianza en tiempo real. Reserva los datos de los indicadores de ofertas confiables en tiempo real solo para aquellos indicadores que sean verdaderamente en tiempo real, como los presupuestos de las campañas o los interruptores de apagado.
Cualquier indicador que se pueda actualizar a diario o con mayor frecuencia se debe almacenar en el grupo de interés y actualizarse con las actualizaciones diarias.
No devuelvas indicadores de ofertas de confianza para los grupos de interés que se filtran, como se describe en la sección "Filtra grupos de interés de las ofertas en tu servicio de clave/valor".
Prioriza los grupos de interés
Los vendedores usarán tiempos de espera para limitar el uso de los recursos del navegador en las páginas de los publicadores. Cuando se usan perBuyerCumulativeTimeouts para limitar el tiempo que tienen los compradores para recuperar sus indicadores de ofertas de confianza y ejecutar sus secuencias de comandos de ofertas, es fundamental que los compradores se aseguren de priorizar sus grupos de interés para que se ejecuten primero los que tienen más probabilidades de ganar la subasta. Por ejemplo, si perBuyerCumulativeTimeouts se establece en 100 ms y la recuperación de los indicadores de ofertas confiables de un ofertante tarda 50 ms, y cada invocación de generateBid() tarda 10 ms y hay 10 grupos de interés presentes en un dispositivo, solo la mitad de los grupos de interés tendrán la oportunidad de calcular ofertas. En este ejemplo, el comprador debe priorizar sus grupos de interés en orden de mayor a menor probabilidad de ganar.
Los grupos de interés pueden contener prioridades estáticas definidas con su campo priority. Los grupos de interés también pueden usar prioridades dinámicas que se pueden calcular en su servicio de indicadores de ofertas de confianza y devolverse al navegador con la respuesta priorityVector a la recuperación de indicadores de ofertas de confianza.
Ten en cuenta que, cuando el navegador ejecuta los grupos de interés de mayor a menor prioridad, esto puede intercalar grupos de interés de diferentes orígenes de unión, lo que podría anular la optimización de group-by-origin.
Prácticas recomendadas para los vendedores
Asegúrate de supervisar y optimizar la eficiencia de las subastas de la API de Protected Audience.
Paraleliza las subastas
Las conexiones de red modernas y los procesadores de varios núcleos hacen un excelente trabajo realizando varias actividades de forma simultánea. El navegador puede ejecutar una subasta de Protected Audience en paralelo con otras actividades. La mejor manera de facilitar esto es llamar a runAdAuction() lo antes posible. Como reconoce que es posible que algunas entradas para runAdAuction() no estén disponibles al principio, por ejemplo, las que se envían de vuelta al navegador en la respuesta contextual, el navegador permite llamar a runAdAution() antes de que estén disponibles y proporcionar estas entradas más adelante con JavaScript Promises. Para lograr la latencia de subasta más baja posible, se debe llamar a runAdAuction() cuando se conoce la entrada interestGroupBuyers. Esto permite que muchas partes de la subasta comiencen de inmediato, incluida la recuperación de los indicadores de ofertas en tiempo real del ofertante.
Supervisa tus subastas
Recopila métricas sobre tus subastas. El navegador puede informar métricas de latencia de per-buyer a los vendedores, lo que proporciona mucha información sobre cómo se emplea el tiempo en las subastas de un vendedor. Los vendedores pueden usar estas métricas para buscar formas de optimizar sus subastas, lo que incluye informar cómo establecer tiempos de espera de la manera más eficaz. Los vendedores pueden compartir las métricas de latencia de un comprador específico con él para ayudarlo a realizar más optimizaciones.
Es posible que los ofertantes tengan estadísticas sobre el rendimiento de las ofertas de sus propios grupos de interés, pero tal vez no puedan compararlo con el de otros ofertantes. Comparar las tasas de victorias relativas y las tasas de rechazo de ofertas para diferentes ofertantes puede ayudar a identificar casos en los que se desperdiciaron recursos de procesamiento de ofertas debido a que los grupos de interés nunca produjeron ofertas viables o a que se realizaron ofertas excesivas con creatividades no aprobadas.
Protección contra secuencias de comandos de ofertas lentas
Los secuencias de comandos de ofertas que tardan demasiado pueden ralentizar la subasta de la API de Protected Audience para todos los participantes. El uso de tiempos de espera puede evitar subastas lentas y, al mismo tiempo, recuperar ingresos cuando la subasta es lenta.
Los vendedores deben usar perBuyerCumulativeTimeouts para evitar subastas lentas y seguir aceptando ofertas cuando la subasta sea lenta y alcance el tiempo de espera. Es preferible usar perBuyerCumulativeTimeouts en lugar de perBuyerTimeouts y perBuyerGroupLimits porque perBuyerCumulativeTimeouts no tiene una opinión definida sobre la cantidad de grupos de interés ni la velocidad de generateBid() (por ejemplo, muchos grupos de interés que ofertan rápidamente y pocos grupos de interés que ofertan lentamente pueden completarse antes del tiempo de espera).
También es una buena idea usar el campo signal de la configuración de la subasta para implementar un tiempo de espera general de la subasta y evitar subastas demasiado largas en los casos en que la recuperación de indicadores de puntuación confiables y la ejecución de scoreAd() tardan demasiado.
¿Qué sigue?
Queremos conversar contigo a fin de asegurarnos de compilar una API que funcione para todos.
Debate sobre la API
Al igual que otras APIs de Privacy Sandbox, esta API se documenta y se analiza públicamente.
Experimenta con la API
Puedes experimentar y participar en las conversaciones sobre la API de Protected Audience.