Lo más conveniente para todos es garantizar que la API de Protected Audience funcione de manera eficiente:
- Las personas que navegan en la Web desean 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 usar en exceso los recursos limitados del dispositivo, como los recursos de procesamiento o de red, que son necesarios para cargar los sitios y sus anuncios incorporados.
- Los publicadores quieren que sus sitios se carguen rápidamente para brindarles a los usuarios una experiencia eficiente y responsiva. Los editores también quieren que una publicidad eficaz maximice sus ingresos.
- Los anunciantes y las tecnologías publicitarias desean 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 a fin de garantizar que tu sitio opere con la máxima eficiencia.
Prácticas recomendadas para compradores (ofertantes)
Para asegurarte de que realizas optimizaciones en función de 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 los diferentes orígenes en la Web mediante el aislamiento de sitios, el navegador usa recursos costosos (como los procesos del sistema operativo) para proteger a los propietarios individuales de grupos de interés.
Para minimizar el gasto de estos recursos muy costosos, es fundamental tener la menor cantidad 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 intereses que eran propiedad de cats.adtech.example y dogs.adtech.example, el navegador probablemente usaría dos procesos independientes para ejecutar sus secuencias de comandos de ofertas.
Ofertas para menos grupos de interés
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 limpio de JavaScript, 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 intereses sin anuncios relevantes. - La combinación de grupos de intereses 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, de manera que una menor cantidad de grupos de interés no necesariamente significa una segmentación menos eficaz. - La API de Protected Audience admite límites que especifique 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 pueden usarse para reducir significativamente la cantidad de secuencias de comandos de ofertas que se ejecutarán.
Filtra 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 de confianza en tiempo real que ciertos grupos de intereses no deben ofertar (p.ej., la campaña se inhabilitó, se detuvo, se agotó, o no debería ofertar para este publicador en particular), puede indicarlo al navegador con la respuesta priorityVector a la recuperación de indicadores de ofertas confiables. Si el producto de punto disperso resultante de priorityVector y prioritySignals es negativo, el navegador omitirá la invocación de generateBid() para este grupo de interés. Puede obtener más información sobre este mecanismo en la sección"Cómo filtrar y priorizar los grupos de interés" de la explicación.
Reutiliza 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 bastante tiempo, a la par con la cantidad de tiempo que puede tardar en ejecutarse un generateBid() mínimo. Este tiempo se puede ahorrar con los modos de ejecución de agrupación o contexto congelado.
El modo group-by-origin puede reutilizar entornos de ejecución en los casos en que los grupos de intereses 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 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.
Reutilice las secuencias de comandos de ofertas
Si es posible, usa el mismo guion de ofertas para los grupos de interés. Esto evita que el navegador tenga que descargar, analizar y compilar varias secuencias de comandos (lo que genera solicitudes de red adicionales). Aun así, los ofertantes pueden diferenciar las ofertas en función de la información del grupo de interés (p.ej., name o userBiddingSignals) mientras utilizan la misma secuencia de comandos.
Reutilizar trustedBiddingSignalsUrls
La latencia de red y el uso de recursos pueden ser muy significativos. Una menor cantidad de recuperaciones de indicadores de ofertas confiables en tiempo real puede ayudar a reducir esta latencia.
Las recuperaciones de indicadores de ofertas confiables se pueden combinar cuando trustedBiddingSignalsUrl se vuelve a usar en 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 confiables se almacenen en caché en los espacios publicitarios de una página web específica. Evita configurar trustedBiddingSignalsSlotSizeMode como slot-size, ya que esto impedirá el almacenamiento en caché en los espacios publicitarios cuando los tamaños de los espacios difieran debido a que la URL solicitada será diferente.
Recuperaciones de indicadores de ofertas confiables en tiempo real más pequeñas
La latencia de red puede ser muy significativa y esto se ve directamente afectado por la cantidad de datos que se transfieren durante las recuperaciones de indicadores de ofertas confiables en tiempo real.
Es preferible almacenar los datos específicos del anuncio o del grupo de interés en el grupo de interés, en lugar de hacerlo en el servicio de indicadores de ofertas confiables en tiempo real. Reserva datos de indicadores de ofertas confiables en tiempo real solo para aquellos que son realmente en tiempo real, como el presupuesto de la campaña o los interruptores finales.
Cualquier indicador que se pueda actualizar de forma diaria o en una base más larga debe almacenarse en el grupo de interés y actualizarse mediante las actualizaciones diarias.
No muestre indicadores de ofertas confiables para los grupos de intereses que se filtran como se describe en la sección "Cómo filtrar grupos de intereses de las ofertas en su servicio de par clave-valor".
Priorizar 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 las perBuyerCumulativeTimeouts para limitar el tiempo que tienen los compradores para recuperar sus indicadores de ofertas confiables 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, la recuperación de indicadores de ofertas confiables de un ofertante tarda 50 ms, y cada invocación de generateBid() tarda 10 ms y tiene 10 grupos de intereses presentes en un dispositivo, solo la mitad de sus grupos de intereses tendrán la oportunidad de calcular ofertas. El comprador de este ejemplo debe priorizar sus grupos de intereses en orden de mayor a menor probabilidad.
Los grupos de interés 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 se devuelven al navegador con la respuesta de priorityVector a la recuperación de indicadores de ofertas confiables.
Ten en cuenta que, cuando el navegador ejecuta grupos de intereses de mayor a menor prioridad, es posible que se intercalan grupos de interés de diferentes orígenes de unión, lo que puede frustrar 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 de varios núcleos hacen un gran trabajo cuando realizan varias actividades en simultáneo. El navegador puede ejecutar una subasta de Protected Audience en paralelo con otras actividades. La mejor manera de realizar esta acción es llamar a runAdAuction() lo antes posible. Dado que es posible que algunas entradas a runAdAuction() no estén disponibles al principio, por ejemplo, aquellas que se devuelven al navegador en la respuesta contextual, el navegador permite llamar a runAdAution() antes de que estén disponibles y proporcionar esas entradas más adelante mediante promesas de JavaScript. Para lograr la menor latencia de subasta posible, se debe llamar a runAdAuction() cuando se conoce la entrada de interestGroupBuyers. De esta manera, muchas partes de la subasta pueden comenzar de inmediato, incluida la recuperación de los indicadores de ofertas en tiempo real del ofertante.
Cómo supervisar 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 invierte 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 forma más eficaz. Los vendedores pueden compartir las métricas de latencia de un comprador específico con el comprador para ayudarlo a optimizar aún más.
Los ofertantes pueden tener estadísticas sobre el rendimiento de las ofertas de sus propios grupos de intereses, pero es posible que no puedan comparar esta información con la de otros ofertantes. La comparación de las tasas de éxito 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 las ofertas debido a que los grupos de intereses nunca produjeron ofertas viables o ofertas excesivas con creatividades no aprobadas.
Protéjase contra las secuencias de comandos de ofertas lentas
Las secuencias de comandos de ofertas que toman demasiado tiempo pueden ralentizar la subasta de la API de Protected Audience para todos los involucrados. Usar tiempos de espera puede evitar que las subastas sean lentas y, al mismo tiempo, recuperar los ingresos cuando estas son lentas.
Los vendedores deben usar perBuyerCumulativeTimeouts para evitar subastas lentas y aceptar 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 se expresa sobre la cantidad de grupos de interés ni la velocidad de generateBid() (p.ej., muchos grupos de interés que ofertan rápido y pocos grupos de interés que ofertan lentamente pueden completarse antes del tiempo de espera).
Usar el campo signal de la configuración de la subasta para implementar un tiempo de espera general también es una buena idea para evitar subastas demasiado largas en los casos en que la puntuación de confianza indique que las recuperaciones y la ejecución de scoreAd() llevan demasiado tiempo.
¿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.