Es en interés de todos 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 sobrecargar los recursos limitados del dispositivo, como los recursos de procesamiento o de red, que son necesarios para cargar sitios y sus anuncios incorporados.
- Los publicadores quieren que sus sitios se carguen rápidamente y proporcionen a los usuarios una experiencia eficiente y responsiva. Los publicadores también desean publicidad eficaz para maximizar sus ingresos.
- Los anunciantes y las tecnologías publicitarias desean que sus anuncios se muestren rápidamente para proporcionar la mayor utilidad.
En este documento, se describen algunas prácticas recomendadas para la implementación de la API de Protected Audience, con el fin de garantizar que tu sitio funcione con la máxima eficiencia.
Prácticas recomendadas para compradores (oferentes)
Para asegurarte de optimizar 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 que el navegador protege diferentes orígenes en la Web con el aislamiento de sitios, el navegador usa recursos costosos (como procesos del sistema operativo) para proteger a los propietarios individuales de los grupos de interés.
Para minimizar el gasto de estos recursos muy costosos, es fundamental tener la
menor cantidad posible de propietarios de grupos de intereses. Evita tener diferentes grupos de intereses que pertenezcan a varios subdominios. Por ejemplo, si adtech.example
tuviera grupos de intereses que pertenecen a cats.adtech.example y dogs.adtech.example,
es probable que el navegador use dos procesos independientes para ejecutar sus secuencias de comandos de oferta.
Menos ofertas de grupos de intereses
El navegador debe realizar una configuración y preparación significativas antes de invocar la secuencia de comandos generateBid() de un comprador, como configurar un nuevo entorno de ejecución de JavaScript limpio y analizar y cargar el código generateBid().
- Los grupos de interés que representan a 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 intereses sin anuncios relevantes. - Combinar grupos de intereses similares disminuirá la cantidad de veces que se debe ejecutar
generateBid(). La propiedaduserBiddingSignalsde un grupo de intereses se puede usar para almacenar metadatos adicionales sobre el usuario, por lo que menos grupos de intereses no tienen por qué significar una segmentación 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 ejecutarán.
Cómo filtrar los grupos de intereses de las ofertas en tu servicio de par clave-valor
Si un comprador puede determinar en su servidor de indicadores de ofertas confiables en tiempo real que ciertos grupos de intereses no deben ofertar (p.ej., la campaña está inhabilitada, pausada o se quedó 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 confiables. Si el producto punto disperso resultante de priorityVector y prioritySignals es negativo, el navegador omitirá invocar generateBid() para este grupo de intereses. Puedes obtener más información sobre este mecanismo en la sección"Cómo filtrar y priorizar los grupos de intereses" de la explicación.
Cómo volver a usar 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. Esto puede tardar una cantidad significativa de tiempo, a la par de la cantidad de tiempo que puede tardar en ejecutarse un generateBid() mínimo. Puedes ahorrar este tiempo usando los modos de ejecución de grupo por origen o de contexto congelado.
El modo group-by-origin puede volver a usar entornos de ejecución en los casos en que los grupos de intereses se unan en el mismo origen y, probablemente, 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 la explicación. El modo de contexto congelado puede volver a usar 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 la explicación.
Cómo volver a usar secuencias de comandos de ofertas
Si es posible, usa la misma secuencia de comandos de ofertas para los grupos de intereses. Esto evita que el navegador tenga que descargar, analizar y compilar varias secuencias de comandos (lo que genera solicitudes de red adicionales). Los ofertantes aún pueden diferenciar las ofertas en función de la información del grupo de intereses (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 asegurarte de 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, sin tener en cuenta la semántica de almacenamiento en caché. Si las subastas se ejecutan de forma secuencial, el navegador se ajustará al mecanismo de almacenamiento en caché de HTTP.
Ten en cuenta que el navegador carga la secuencia de comandos de ofertas durante el tiempo de oferta (para generateBid()) y también durante el tiempo de informes (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 configures encabezados de control de caché en todas tus secuencias de comandos.
Reutilizar trustedBiddingSignalsUrls
La latencia de red y el uso de recursos pueden ser muy significativos. Menos recuperaciones de indicadores de ofertas confiables en tiempo real pueden ayudar a reducir esta latencia.
Las recuperaciones de indicadores de ofertas confiables se pueden combinar cuando se reutiliza trustedBiddingSignalsUrl entre varios grupos de intereses.
Cuando sea posible, usa el mismo trustedBiddingSignalsUrl para todos los grupos de intereses.
Especifica los encabezados de control de caché HTTP adecuados para garantizar que las recuperaciones de indicadores de ofertas de confianza se almacenen en caché en los espacios de anuncios de una página web en particular. Evita establecer trustedBiddingSignalsSlotSizeMode en slot-size, ya que esto evitará el almacenamiento en caché en los espacios de anuncios cuando los tamaños de los espacios 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 esto se ve afectado directamente por la cantidad de datos que se transfieren durante las recuperaciones de indicadores de ofertas confiables en tiempo real.
Se prefiere almacenar datos específicos del anuncio o del grupo de intereses en el grupo de intereses, en lugar de hacerlo en el servicio de indicadores de ofertas confiables en tiempo real. Reserva los datos de indicadores de ofertas confiables en tiempo real solo para los indicadores que realmente sean en tiempo real, como el presupuesto de la campaña o los interruptores de apagado.
Cualquier indicador que se pueda actualizar a diario o con mayor frecuencia se debe almacenar en el grupo de intereses y actualizar con las actualizaciones diarias.
No devuelvas indicadores de ofertas confiables para los grupos de intereses que se filtran como se describe en la sección "Cómo filtrar los grupos de intereses de las ofertas en tu servicio de par clave-valor".
Prioriza los grupos de interés
Los vendedores usarán tiempos de espera para limitar la forma en que se usan los recursos del navegador en las páginas del publicador. Cuando se usan perBuyerCumulativeTimeouts para limitar el tiempo que los compradores tienen 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 intereses para que los que tengan más probabilidades de ganar la subasta se ejecuten primero. Por ejemplo, si perBuyerCumulativeTimeouts se establece en 100 ms y la recuperación de los indicadores de ofertas confiables de un ofertante demora 50 ms, cada invocación de generateBid() demora 10 ms y tiene 10 grupos de intereses presentes en un dispositivo, solo la mitad de sus grupos de intereses tendrá la oportunidad de calcular las ofertas. En este ejemplo, el comprador debe priorizar sus grupos de intereses de la opción con más probabilidades de éxito a la que tiene menos probabilidades de éxito.
Los grupos de intereses pueden contener prioridades estáticas definidas con su campo priority. Los grupos de intereses también pueden usar prioridades dinámicas que se pueden calcular en su servicio de indicadores de ofertas confiables y mostrarse al navegador con la respuesta priorityVector a la recuperación de indicadores de ofertas confiables.
Ten en cuenta que, cuando el navegador ejecuta grupos de intereses de la prioridad más alta a la más baja, es posible que se entremezclen grupos de intereses de diferentes orígenes de unión, lo que podría anular la optimización de group-by-origin.
Prácticas recomendadas para 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 multinúcleo realizan un excelente trabajo cuando se ejecutan varias actividades de forma simultánea. El navegador puede ejecutar una subasta de Protected Audience en paralelo con otras actividades. Para facilitar esto, llama a runAdAuction() lo antes posible. Dado que es posible que algunas entradas de runAdAuction() no estén disponibles al principio, por ejemplo, las que se envían 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 promesas de JavaScript. 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 per-buyer a los vendedores que proporcionan muchas estadísticas sobre cómo se gasta 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 configurar tiempos de espera de 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 intereses, pero es posible que no puedan compararlas con las de otros ofertantes. Comparar las tasas de ganancias relativas y las tasas de rechazo de ofertas de diferentes ofertantes puede ayudar a identificar casos en los que se desperdiciaron recursos de procesamiento de ofertas debido a que los grupos de intereses nunca produjeron ofertas viables o ofertas excesivas con creatividades no aprobadas.
Protege contra las secuencias de comandos de ofertas lentas
Las secuencias de comandos de ofertas que tardan demasiado tiempo pueden ralentizar la subasta de la API de Protected Audience para todas las partes involucradas. El uso de tiempos de espera puede evitar subastas lentas y, al mismo tiempo, recuperar los ingresos cuando la subasta es lenta.
Los vendedores deben usar perBuyerCumulativeTimeouts para evitar subastas lentas y seguir aceptando ofertas cuando la subasta es lenta y alcanza el tiempo de espera. Es preferible usar perBuyerCumulativeTimeouts en lugar de perBuyerTimeouts y perBuyerGroupLimits porque perBuyerCumulativeTimeouts no tiene una opinión sobre la cantidad de grupos de interés ni la velocidad de generateBid() (p.ej., 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 configuración de subastas para implementar un tiempo de espera general de subastas para evitar subastas demasiado largas en los casos en que la recuperación de indicadores de puntuación de confianza y la ejecución de scoreAd() demoran 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.