Respuestas a preguntas frecuentes relacionadas con las APIs de relevancia y medición de Privacy Sandbox
¿Cómo se compara Topics con los públicos definidos por el vendedor (SDA)?
Los temas y el SDA proporcionan tipos de información complementarios, y ambos están bajo el control del publicador. No creemos que compitan entre sí. En cambio, trabajan en paralelo o en contextos diferentes para maximizar las oportunidades de compra. Los compradores consideran y usan muchos indicadores cuando evalúan las impresiones de manera programática, y esperamos que Topics sea una de esas consideraciones. Históricamente, los vendedores no incluyen segmentos de público en subastas abiertas de mercados, sino que se usará Topics en un lugar probable. En cambio, los vendedores ponen a disposición sus públicos para compras programáticas en acuerdos con anunciantes, agencias o DSP. En esos casos, el vendedor y el comprador realizan transacciones intencionadas en el SDA. Si se usan Topics en estos casos, podría corresponder a una o más de las siguientes opciones:
- El vendedor amplía su definición de público con Topics.
- El comprador utiliza Topics como indicador para saber cuánto ofertar
- El comprador usa Topics para validar si el SDA es preciso.
¿Protected Audience le da a Google el control de la creación de públicos?
No. Los sitios pueden seguir creando sus propios públicos dentro y fuera de Privacy Sandbox. Cuando los sitios crean públicos dentro de Privacy Sandbox, el propietario del sitio o el proxy elegido determina quién puede crearlos, cuáles son esos públicos, cómo se actualizan, cómo se ofertarán por ellos y si se quitarán los usuarios del público.
¿Protected Audience admite grupos de intereses creados por el publicador?
Sí. Entendemos que los publicadores son reacios a colocar a sus públicos en subastas basadas en OpenRTB hoy en día por temor a la filtración de datos. Los publicadores pueden crear públicos hoy en día en Protected Audience que no le brindan al ofertante una vista de varios sitios de ese usuario editor individual. Nos entusiasma seguir explorando formas en las que los publicadores pueden aprovechar el entorno reducido de filtración de datos de Protected Audience.
¿Cómo se aplican las reglas de calidad de los anuncios en las subastas de Protected Audience?
Existen varias formas de aplicar las reglas de calidad de los anuncios en las subastas de Protected Audience. Cada una de estas opciones es similar a la manera en que las SSP aplican las reglas de calidad de los anuncios en la actualidad. Una forma es permitir que una subasta con una creatividad desconocida active la creatividad para que entre en una cola para su análisis. Recibimos comentarios de que las SSP quieren una mejor compatibilidad para este caso práctico y estamos diseñando un mecanismo que pueda crear un feed de renderUrls que la SSP pueda auditar fuera de banda y, luego, almacenar la información en su servidor de par clave-valor. Otra forma es solicitar el registro previo de los anuncios. Al igual que en el caso anterior, una vez que se analiza la creatividad, los resultados pueden vincularse al servidor de par clave-valor. Más adelante, cuando un comprador oferta con esa creatividad (como lo indica un ID de creatividad que probablemente siga el mismo formato que OpenRTB), la lógica de puntuación del vendedor puede realizar una búsqueda en el servidor de par clave-valor y decidir cómo calificar según corresponda.
¿Protected Audience admite anuncios de video?
Sí. Las URLs de VAST se pueden pasar dentro y fuera de Protected Audience. A medida que se lanza una URL de VAST, la tecnología orientada a la venta puede coordinar cómo unirán la URL de VAST del comprador antes de enviarla al reproductor. Antes del requisito de cambiar a Fenced Frames (a partir de 2026) y fortalecer aún más las protecciones de la privacidad de los usuarios, esperamos que el ecosistema participe en debates de diseño que incluirán videos.
¿Protected Audience admite anuncios nativos?
Sí. Las URLs JSON se pueden pasar dentro y fuera de Protected Audience. A medida que se lanza una URL de JSON, la tecnología orientada a la venta puede coordinar cómo agregan los eventos deseados antes de que se pase el JSON final al código de renderización. Antes del requisito de cambiar a Fenced Frames (no antes de 2026) para reforzar aún más las protecciones de la privacidad de los usuarios, esperamos que el ecosistema participe en debates de diseño que probablemente incluirán anuncios nativos.
¿La renderización de anuncios de Protected Audience inhibe la innovación?
No. La renderización de anuncios siempre dependió de las tecnologías de los navegadores. Eso no cambia. Quizás esta preocupación sea específica para los planes que requieren el uso de marcos protegidos junto con Protected Audience en el futuro. Parte de la razón por la que estos planes son "en el futuro" es porque queremos que la tecnología de Fenced Frames respalde la innovación y la diferenciación del ecosistema cuando se trata de la renderización de anuncios. Hay tiempo para que los desarrolladores y las empresas interesados analicen la dirección de los marcos vallados, lo que incluye cómo admitir los enfoques de anuncios nativos.
¿Protected Audience permite aplicar enfoques sofisticados de ritmo y valoración de ofertas que existen actualmente en las subastas tradicionales?
Protected Audience ofrece una opción en tiempo real para que los compradores comprendan el ritmo y los presupuestos de las campañas. Desde la perspectiva del inventario, el vendedor puede proporcionar indicadores de subasta al comprador acerca del contexto de la página y otros aspectos. Si un vendedor decide enviar una solicitud de oferta contextual, el comprador también puede obtener información sobre el inventario a través de ese mecanismo y, luego, proporcionarse indicadores contextuales (a través de perBuyerSignals) que podrían usarse en la generación de ofertas de Protected Audience. Los usuarios pioneros ya están conectando los sistemas de aprendizaje automático con Protected Audience. Entendemos que llevará tiempo ajustar estos sistemas a las ofertas en entornos de Protected Audience, pero es fundamental tener en cuenta que el ajuste es posible y ya se está realizando.
¿El estándar de OpenRTB funcionará en Protected Audience?
Sí. Este trabajo se encuentra en curso en IAB Tech Lab a través de un grupo con buena asistencia de DSP y SSP representativas. Parece que la ruta a seguir será usar partes del protocolo OpenRTB como estándar de comunicación dentro de las subastas de Protected Audience, y sabemos que los usuarios pioneros ya lo están haciendo.
¿Protected Audience requiere que las empresas mantengan dos arquitecturas distintas para la publicación de anuncios?
No. Protected Audience no requiere mantener dos arquitecturas separadas. Tus elecciones arquitectónicas son tuyas. A medida que la publicidad en línea ha progresado a lo largo de los años, también lo ha hecho la complejidad de los sistemas que la utilizan. Hacer que Internet sea más privada para los usuarios presenta más complejidad y requiere trabajo. Las empresas de tecnología publicitaria pueden optar por mantener dos arquitecturas separadas o compilar Protected Audience en una arquitectura combinada con subastas tradicionales.
¿Qué sucederá con las subastas tradicionales una vez que más empresas de tecnología publicitaria admitan Protected Audience?
Esperamos que las subastas contextuales sigan siendo relevantes por infinidad de motivos, incluidos los acuerdos, las campañas segmentadas por público no propio y muchas otras situaciones contextuales. También siguen siendo valiosas cuando no hay grupos de intereses presentes o cuando las ofertas en Protected Audience no alcanzan los mínimos o cumplen con las reglas de calidad de los anuncios.
¿La subasta de Protected Audience es contraria a las iniciativas de optimización de la ruta de suministro (SPO) del ecosistema para reducir la cantidad total de intermediarios entre un anunciante y un publicador, o bien la duplicación de una oportunidad de anuncio determinada?
No. Un anuncio ganador en Protected Audience pasará como máximo a dos entidades de vendedor (por ejemplo, una plataforma de proveedores (SSP) y un servidor de anuncios del publicador) y tan pocas como ninguna, si el comprador crea una integración directa con el publicador.
La duplicación de la misma solicitud con varios intermediarios sigue siendo la elección del publicador. Protected Audience no debería afectar de una manera ni la otra.
Las subastas de Protected Audience ocurren fuera del sistema en tiempo real de servidor a servidor actual para no filtrar datos del usuario entre sitios. Algunos pueden decir que esto duplica una solicitud de anuncio. Lograr una privacidad técnica demostrable requiere algunas compensaciones. Sin embargo, es posible que a largo plazo el ecosistema decida usar Protected Audience sin las subastas tradicionales del servidor. Esta elección podría optimizar aún más las rutas de suministro.
¿Protected Audience reduce el valor de la infraestructura existente que define el tráfico?
Según lo que entendemos, lo que está cambiando con respecto a las consultas por segundo es que muchas SSP usan los IDs entre sitios como una función para determinar si deben enviar o no una solicitud a una DSP. Por lo tanto, la reducción de los IDs entre sitios afecta las técnicas existentes de determinación de tráfico. Esto sería cierto independientemente de si el publicador desea ejecutar o no una subasta de Protected Audience.
Exploramos la determinación por tráfico con muchas SSP y encontramos soluciones como el almacenamiento en caché y el filtrado basado en el contexto. Con el tiempo, esperamos que los desarrolladores aprovechen la agregación privada para facilitar aún más la comprensión de las preferencias de ofertas de la DSP y filtrar según corresponda.
En última instancia, cierta infraestructura heredada compilada en torno a identificadores entre sitios ya no será útil.
¿Las solicitudes nuevas que resulten de una subasta de Protected Audience limitarán la capacidad de la SSP?
Algunas SSP nos comentaron que la capacidad no es un problema o una pieza importante de la propuesta de valor de la SSP desde el punto de vista de la integración. Para las SSP a las que les preocupan las llamadas nuevas en el proceso de subasta, conocemos empresas que ya ayudan a las SSP con problemas de capacidad y buscan expandir esos servicios para admitir Protected Audience. Comunícate con nosotros si deseas que te pongamos en contacto con una de esas empresas.
¿Cómo se aborda la prioridad en Protected Audience cuando hay recursos que compiten en el navegador?
En general, Protected Audience siguió el paradigma estándar de controles de compilación que permiten a los vendedores decidir cuánto tiempo y recursos pueden consumir los ofertantes, así como herramientas de compilación que permiten a los compradores decidir la mejor manera de utilizar los recursos que tienen disponibles. Estos controles y herramientas ya están disponibles en la actualidad, pero todos los beneficios se obtendrán tras la adopción por parte de los compradores y vendedores. Además, Chrome sigue trabajando en una variedad de mejoras de infraestructura para la velocidad de subasta (por ejemplo, crrev.com/1190815, crrev.com/1199839, crrev.com/1201837, crrev.com/1198339, crrev.com/119).
¿Cómo aborda Protected Audience los problemas de latencia?
En el pasado, antes de Protected Audience, las licitaciones en tiempo real que se llevaban a cabo en servidores tenían vendedores que especificaban tiempos de espera estrictos en las respuestas de los compradores para mantener la latencia bajo control. Agregamos una variedad de controles de tiempo de espera muy similares específicos por el vendedor (consulta la documentación de perBuyerCumulativeTimeouts, perBuyerTimeouts y sellerTimeout) a Protected Audience para lograr el mismo objetivo de mantener la latencia bajo control. Estos controles también animan a los participantes de la subasta a optimizar su lógica para garantizar que los recursos se usen de la manera más eficiente para respaldar el ecosistema de tecnología publicitaria y una experiencia del usuario de alta calidad.
Chrome también sigue trabajando en una variedad de mejoras de infraestructura en la velocidad de subasta (p.ej., crrev.com/1190815, crrev.com/1199839, crrev.com/1201837, crrev.com/1198339, crrev.com/1197323). Invitamos a que nos envíes comentarios sobre ambas partes de este esfuerzo de latencia: herramientas adicionales que resultarán útiles para compradores y vendedores, e informes de cuellos de botella observados que los ingenieros de Chrome deberían investigar.
¿Es un esfuerzo desperdiciado crear para Protected Audience integrado en el dispositivo cuando existen servicios de ofertas y subastas (B&A)?
No. Integrar en el dispositivo es suficiente para los casos de uso de tecnología publicitaria. Los servicios de ofertas y subastas son una solución opcional de escala horizontal cuando las tecnologías publicitarias desean invertir más en recursos de procesamiento de ofertas de lo que permite el navegador. El desarrollo integrado en el dispositivo es una buena inversión, ya que la mayor parte del trabajo se podría reutilizar incluso si los desarrolladores deciden más adelante participar en los entornos de servicios de ofertas y subastas. La mayoría de las canalizaciones y la infraestructura compiladas seguirían funcionando de manera similar.
¿Los requisitos de los entornos de ejecución confiables (TEE) basados en la nube para Protected Audience impulsarán a las empresas a usar Google Cloud?
Privacy Sandbox diseñó las APIs para proporcionar una privacidad y seguridad sólidas, y no tomamos ninguna decisión de diseño para beneficiar a Google Cloud. Nuestra asistencia para proveedores de servicios en la nube comenzó con AWS porque reconocemos cuántos proveedores de tecnología publicitaria eligen Amazon. Además de AWS y Google Cloud, esperamos admitir otros proveedores de servicios en la nube en el futuro y estamos dispuestos a recibir sugerencias para otros proveedores de servicios en la nube. Si la latencia es una preocupación, las nubes ofrecen a los clientes opciones de ubicación que reducen las distancias a otros proveedores de servicios en la nube.
¿Privacy Sandbox permitirá que se ejecuten entornos de ejecución confiables (TEE) en centros de datos en la nube no pública?
Los entornos de ejecución confiables (TEE) auditables forman parte de nuestro modelo de privacidad y seguridad. Comenzamos con los TEE que ofrecen los proveedores de servicios en la nube pública debido a sus rigurosas medidas de seguridad. Para ser claros, las únicas APIs que requieren el uso de entornos de ejecución confiables a corto plazo son la API de Attribution Reporting y la API de Private Aggregation, y ninguna implica llamar al TEE en tiempo real en una configuración de subasta. Seguimos explorando la compatibilidad con otras opciones más allá de las soluciones basadas en la nube pública.
¿No será más costoso ejecutar entornos de ejecución confiables en nubes públicas que en centros de datos de tecnología publicitaria locales?
Nuestro modelo de privacidad de TEE actual se beneficia de las prácticas de seguridad de las implementaciones en la nube pública, y nos preguntamos cualquier suposición de que es menos costoso operar un entorno de ejecución confiable en las instalaciones. Estas son algunas consideraciones sobre los costos de estas prácticas:
Los proveedores de servicios en la nube pública deben cumplir con un estándar muy alto en cuanto a seguridad. Por ejemplo, AWS es un proveedor de servicios en la nube respetable con prácticas de seguridad establecidas. En particular, AWS Nitro cuenta con un modelo de seguridad documentado para garantizar que los enclaves de Nitro impidan que los operadores accedan a los datos procesados en el enclave. Además, los recursos protegidos (como las claves de desencriptación) solo están disponibles para el código autorizado que se ejecuta en el enclave. También hay un acceso físico a tener en cuenta. AWS ha diseñado e implementado mitigaciones para los riesgos de acceso físico, incluidos los de los empleados de Amazon. Es posible que los TEE existentes basados en hardware no se defiendan de todos los ataques físicos, algo que las nubes públicas están diseñadas para hacer. Además, Amazon recientemente contrató al Grupo NCC, una empresa de investigación independiente, para revisar sus diseños de Nitro, centrados en las declaraciones de seguridad relacionadas con el acceso de empleados internos. El informe público indica que los diseños de AWS cumplen con sus reclamaciones.
La implementación, el apoyo y la mejora de estas prácticas cuesta dinero. Con nubes públicas distribuidas de forma global y ampliamente disponibles, esos costos se distribuyen entre una amplia base de clientes.
¿Privacy Sandbox cambia la facturación?
No. Las empresas de tecnología publicitaria y otros llamadores de API pueden seguir viendo si se renderiza algo en una página y a qué precio.
¿Es posible la limitación de frecuencia en Privacy Sandbox?
Protected Audience admite la limitación de frecuencia entre sitios dentro del mismo grupo de interés a través del objeto prevWinsMs. La función generateBid() de un comprador dentro de la subasta de Protected Audience puede crear una lógica que fundamenta la estrategia de ofertas en función del resultado de exposiciones anteriores del anuncio para el mismo navegador.
Hay algunas soluciones que se pueden usar para la limitación de frecuencia fuera de Protected Audience, pero no se asignan por completo a las técnicas entre sitios que tienen las tecnologías publicitarias con cookies de terceros.
- Cookies propias: Las tecnologías publicitarias pueden usar sus propios datos de origen para limitar la frecuencia en su propio sitio.
- CHIP: Las tecnologías publicitarias pueden administrar las limitaciones de frecuencia a nivel de cada sitio mediante una cookie particionada.
- Almacenamiento compartido
SelectURL(): Después de que una tecnología publicitaria gane una subasta y antes de renderizar la creatividad, puede llamar al almacenamiento compartido para acceder a los datos de varios sitios y elegir la creatividad adecuada en función de la frecuencia a través de la puerta Select URL output.
Una solución de limitación de frecuencia enfocada en la privacidad y no de Protected Audience que proporciona una utilidad de tecnología publicitaria significativa es un desafío por los siguientes motivos:
- Por el momento, en función de los comentarios de la tecnología publicitaria, no está claro si una señal de frecuencia podría tolerar ruido.
- Recibimos comentarios coherentes de las tecnologías publicitarias que indican que un indicador de frecuencia entre sitios debería estar disponible durante la subasta, lo que requiere que los indicadores sin ruido entre sitios estén disponibles para su uso en cualquier subasta de publicidad. Esto podría revelar una gran cantidad de información sobre la actividad del usuario en los sitios, lo que socavaría los objetivos de privacidad de Privacy Sandbox.
- Somos sensibles a la introducción de latencia, y una solución en el dispositivo que podría proporcionar este indicador podría causar latencia e interrumpir el entorno de la subasta.
- Es probable que una solución deba ser una API nueva, que tendría que pasar por el proceso de propuesta de W3C.
Por lo tanto, la creación de una solución de limitación de frecuencia fuera de Protected Audience no está en nuestra hoja de ruta inmediata, pero estamos abiertos a los comentarios sobre posibles formas de resolver este caso de uso.
¿Qué sucede con los casos de uso que no cubre Privacy Sandbox?
Las APIs de Privacy Sandbox proporcionan componentes básicos clave para la publicidad que preserva la privacidad, en la que los desarrolladores tienen la flexibilidad de determinar cómo se agrupan. El enfoque de componentes básicos permite a las empresas innovar y desarrollar soluciones que ofrezcan valor a sus clientes. Privacy Sandbox no pretende ser una solución de extremo a extremo para todos los casos de uso. Creemos que sería un mal resultado. En cambio, los desarrolladores y las empresas continuarán dando vida a sus ideas a través de una variedad de tecnologías, incluidas las APIs de Privacy Sandbox que integren en sus soluciones.