Informe trimestral del 1ᵉʳ trimestre de 2024 que resume los comentarios del ecosistema recibidos sobre las propuestas de Privacy Sandbox y la respuesta de Chrome.
Como parte de sus compromisos con la CMA, Google acordó proporcionar públicamente informes trimestrales sobre el proceso de participación de las partes interesadas para sus propuestas de Privacy Sandbox (consulta los párrafos 12 y 17(c)(ii) de los Compromisos). Estos informes de resumen de comentarios de Privacy Sandbox se generan a partir de la agregación de los comentarios que recibe Chrome de las diversas fuentes que se indican en la descripción general de los comentarios, incluidos, sin limitaciones, los problemas de GitHub, el formulario de comentarios disponible en privacysandbox.com, las reuniones con las partes interesadas de la industria y los foros de estándares web. Chrome recibe con gusto los comentarios que recibe del ecosistema y explora activamente formas de integrar los aprendizajes en las decisiones de diseño.
Los temas de los comentarios se clasifican según su prevalencia por API. Para ello, se realiza una agregación de la cantidad de comentarios que recibió el equipo de Chrome sobre un tema determinado y se organiza en orden descendente de cantidad. Para identificar los temas de comentarios comunes, se revisaron los temas de debate de las reuniones públicas (W3C, PatCG, IETF), los comentarios directos, GitHub y las preguntas frecuentes que surgieron a través de los equipos internos de Google y los formularios públicos.
Más específicamente, se revisaron los actas de las reuniones de los organismos de estándares web y, para los comentarios directos, se consideraron los registros de Google de las reuniones 1:1 con las partes interesadas, los correos electrónicos recibidos por ingenieros individuales, la lista de distribución de la API y el formulario de comentarios público. Luego, Google coordinó entre los equipos involucrados en estas diversas actividades de divulgación para determinar la prevalencia relativa de los temas que surgieron en relación con cada API.
Las explicaciones de las respuestas de Chrome a los comentarios se desarrollaron a partir de las preguntas frecuentes publicadas, las respuestas reales a los problemas planteados por las partes interesadas y la determinación de una posición específica para los fines de este ejercicio de informes públicos. Como reflejo del enfoque actual del desarrollo y las pruebas, se recibieron preguntas y comentarios en particular con respecto a las APIs de Topics, Protected Audience y Attribution Reporting.
Es posible que los comentarios recibidos después del final del período de informes actual aún no tengan una respuesta de Chrome.
Glosario de acrónimos
- ARA
- API de Attribution Reporting
- CHIPS
- Cookies con estado particionado independiente
- DSP
- Plataforma orientada a la demanda
- FedCM
- Administración de credenciales federadas
- FPS
- Conjuntos propios
- IAB
- Interactive Advertising Bureau
- IDP
- Proveedor de identidad
- IETF
- Internet Engineering Task Force
- IP
- Dirección de protocolo de Internet
- openRTB
- Licitaciones en tiempo real
- TS
- Prueba de Origin
- API de PAT
- API de Protected Audience (antes conocida como FLEDGE)
- PatCG
- Grupo de la comunidad de tecnología publicitaria privada
- Acceso al
- Usuario de confianza
- RWS
- Conjuntos de sitios web relacionados (anteriormente, Conjuntos propios)
- SSP
- Plataforma de proveedores
- TEE
- Entorno de ejecución confiable
- UA
- Cadena de usuario-agente
- UA-CH
- Sugerencias de clientes de usuario-agente
- W3C
- World Wide Web Consortium
- WIPB
- Ceguera IP intencional
Comentarios generales, sin API ni tecnología específicas
| Tema de los comentarios | Resumen | Respuesta de Chrome |
|---|---|---|
| Administración | Interés en un período de comentarios públicos para las actualizaciones de gobernanza de Privacy Sandbox | Estamos abiertos a comentarios razonables de las partes interesadas sobre cualquier desarrollo significativo relacionado con Privacy Sandbox, incluida la gobernanza futura de Privacy Sandbox. |
| Prueba | Fases de prueba adicionales para 3PCD, además del 1% actual de pruebas facilitadas por Chrome. | No tenemos la intención de ofrecer pruebas facilitadas por Chrome más allá del 1% actual del tráfico de Chrome habilitado desde principios de enero. |
| Redireccionamiento de la Web a la app | La 3PCD en dispositivos móviles no debe ocurrir antes de que se logre la interoperabilidad total entre la Web y la app. | Creemos que es conveniente admitir la interoperabilidad entre apps y la Web, por lo que lanzamos la medición de atribución entre apps y la Web, y estamos explorando soluciones de segmentación de la Web a la app. Sin embargo, no tenemos previsto retrasar la implementación de 3PCD en la Web móvil. No tenemos un objetivo de cobertura del 100% al final del 3PCD. En cambio, esperamos que la compatibilidad en Android para la medición entre apps y la Web sea razonablemente alta en 3PCD y que aumente con el tiempo a medida que los usuarios actualicen sus teléfonos. |
| Rol del navegador | Al parecer, Chrome está asumiendo el rol de un servidor de anuncios o una SSP. | Chrome no asumirá el rol de un servidor de anuncios ni de una SSP. Con la API de PA, Chrome proporciona un contenedor para que los servidores de anuncios, las SSP, las DSP y otras tecnologías publicitarias implementen su propia lógica de puntuación y ofertas. |
| Orientación sobre casos de uso | Orientación más clara sobre los casos de uso que admitirán las APIs de Privacy Sandbox. | Al comienzo del proyecto de Privacy Sandbox, la documentación para desarrolladores se enfocaba principalmente en integrar a los desarrolladores en los procesos de debate y comentarios de todas las propuestas. Esto significaba que el contenido se estructuraba en general en torno a la comprensión de la motivación y los conceptos detrás del proyecto, seguidos de detalles del desarrollo inicial y de las pruebas de cada propuesta. Esto fue eficaz para establecer una colaboración real del ecosistema en el desarrollo de las propuestas, pero a medida que las APIs avanzaron hasta la disponibilidad general, hay un nuevo público de desarrolladores que está aquí principalmente para compilar en las APIs en lugar de contribuir a su desarrollo subyacente. Recientemente, actualizamos la navegación del sitio para desarrolladores de Privacy Sandbox para que se centre en los casos de uso, con categorizaciones similares a las de IAB Tech Lab en su reciente informe de la Fuerza de Tareas de Privacy Sandbox. Ese enfoque de documentación basado en casos de uso es algo que seguiremos aplicando en el futuro. |
| Entorno de desarrollo local | ¿Cómo podemos seguir desarrollando y probando nuestro frontend de forma local en http://localhost cuando la cookie es SameSite=Secure y el backend está al frente de una CDN? | Estamos analizando este problema aquí y agradecemos los comentarios adicionales del ecosistema. |
| Mitigación de 3PCD | ¿Existe una forma programática de saber si los 3PC están bloqueados o cuándo están activas las heurísticas? | En Chrome, tanto la detección de atributos como la llamada a document.hasStorageAccess en un iframe permiten que un desarrollador sepa si el origen en el iframe tiene acceso a 3PC. |
| Pruebas de video | Actualmente, no es posible probar anuncios de video en Privacy Sandbox. | Chrome publicó una discusión y una demostración de varias formas posibles en las que se puede lograr el video con la API de PA hoy (consulta 242 y 254 en nuestro repositorio de demostraciones en GitHub). Ten en cuenta que no se trata de un código de muestra que las tecnologías publicitarias adoptarían de forma masiva, sino de una prueba de concepto y una demostración de las técnicas que podrían admitir la renderización de videos VAST con la API de PA. Durante el transcurso de esta discusión, también quedó claro que, si bien la renderización de videos ya es posible en la actualidad, Chrome podría realizar cambios que simplificarían la implementación con la API de PA. Por ejemplo, las actualizaciones de la sustitución de macros (que se analizaron aquí) que ya planeábamos abordar en función de los comentarios sobre los casos de uso de seguridad de la marca de verificadores de anuncios de terceros también abordarían los comentarios en el caso de uso de video, en el que el comprador busca qué macros del vendedor usar en la renderización. La mayoría de los debates hasta la fecha se han centrado en la renderización de anuncios de video VAST. La renderización de anuncios nativos podría usar los mismos enfoques y es más fácil de muchas maneras. En la actualidad, los anuncios nativos parecen recibir menos atención que los de video, pero esto es solo una cuestión de prioridades de la industria de la tecnología publicitaria, no de ninguna barrera técnica para la implementación. |
| Medición de no anuncios | La 3PCD puede afectar las soluciones de medición de públicos que no están relacionadas con los anuncios. | Las APIs de medición no requieren que el caso de uso esté relacionado con los anuncios. Si bien la ARA es más específica para un recorrido publicitario típico,la agregación privada es de uso general. Estos dos elementos básicos se pueden usar para abordar una amplia variedad de actividades de medición. |
| Creadores de contenido | Privacy Sandbox está estructurado para alentar a los creadores de contenido a producir más contenido para YouTube y menos en sus propios sitios. | La iniciativa Privacy Sandbox se enfoca en mantener la privacidad de la actividad de las personas en un entorno de Internet abierto y gratuito. Sabemos que los publicadores dependen de los anuncios para producir contenido y que esté disponible lo más ampliamente posible. Los anunciantes ayudan a las personas a descubrir productos o ofertas nuevos que podrían interesarles. Las funciones de Privacy Sandbox permiten que sitios web de todo tipo, incluidos los que trabajan con creadores de contenido, muestren a las personas anuncios útiles en función de su actividad con diferentes partes, sin revelar la identidad del usuario a esas partes. |
| Cronogramas más claros | Cronogramas de lanzamiento más claros y detallados para las tecnologías de Privacy Sandbox | La documentación de la API de Privacy Sandbox incluye páginas de estado y disponibilidad de la API. En estas páginas, se enumeran las próximas funciones y sus cronogramas (p.ej., API de PA, ARA). Puedes ver una vista central de estos estados aquí. |
| Aprendizaje automático | Las tecnologías publicitarias no pueden entrenar correctamente los modelos de aprendizaje automático hasta que el 3PCD se extiende más allá del 1%. | Expandir la 3PCD a más navegadores para realizar pruebas no garantizaría que las APIs tengan más uso, que es lo que probablemente buscan las tecnologías publicitarias para entrenar aún más los modelos de aprendizaje automático. Si el uso más amplio del ecosistema no es lo que buscan las tecnologías publicitarias para entrenar aún más los modelos de aprendizaje automático, no hay razón para expandir el 3PCD, ya que una tecnología publicitaria que desee entrenar modelos con más tráfico puede hacerlo hoy sin aumentar el 3PCD. Esto se puede hacer sin que Chrome parezca avanzar en 3PCD antes de que finalice la inactividad. |
| Caso de uso no admitido | Actualmente, no se están considerando casos de uso de DSP de autoservicio. | Existen varias DSP de autoservicio que proporcionan comentarios públicos sobre las APIs con regularidad. Varias de esas DSP que proporcionan comentarios públicos con regularidad también se registraron como verificadores. Además, Chrome participa activamente en temas típicos de las DSP de autoservicio, como los servidores de anuncios de video y de terceros. En las llamadas recientes a la API de PA semanales, se abordaron estos temas. |
| Prueba de origen | Solicitud de OT para sitios que deseen una implementación más agresiva y una cobertura de prueba para 3PCD. | Actualmente, Chrome está desarrollando una OT propia, que permitirá que los orígenes habiliten el comportamiento de eliminación gradual de las cookies de terceros. Los orígenes de nivel superior que se registren para esta prueba y que implementen tokens tendrán bloqueadas las 3PC como si el dispositivo del usuario tuviera habilitada la protección contra el seguimiento. Esta OT brindará una oportunidad valiosa para que los sitios realicen pruebas más amplias de alternativas a largo plazo a los 3PC, antes de la eventual baja gradual de los 3PC, que se realizará después de consultar con la CMA. Aún estamos trabajando para finalizar el cronograma del lanzamiento de la OT. |
| Informe de IAB Tech Lab | Comentarios sobre Privacy Sandbox recibidos del informe de IAB Tech Lab | Respondimos al informe de IAB Tech Lab en detalle aquí. También reconocemos que "el informe plantea preguntas sobre la documentación fragmentada, los requisitos comerciales, las auditorías de terceros, la acreditación de la industria, la escalabilidad, la transparencia y la gobernanza futura, sobre los que trabajaremos con el ecosistema y actualizaremos nuestras preguntas frecuentes públicas según corresponda". Ya abordamos la documentación fragmentada anteriormente. Aquí abordamos los requisitos comerciales en "Garantías de datos" y algunos productos de Google Ads compartieron sus enfoques. Aquí abordamos las auditorías de terceros en el artículo "Garantía de integridad del algoritmo". En cuanto a la acreditación, esperamos que esos organismos sigan acreditando productos, incluido su uso de tecnologías, en lugar de las tecnologías en sí. En cuanto a la escalabilidad, seguimos abiertos a los datos de los desarrolladores que demuestren problemas. En cuanto a la transparencia y la gobernanza, seguimos desarrollando nuestras iniciativas de forma pública en GitHub y en foros como el W3C, mientras interactuamos con la CMA en virtud de los compromisos. |
| Acceso con Google | Los accesos de Google permitirían que Google use datos de acceso de identificación cruzada en contra de los Compromisos. | Acceder con Google no permite que Google use datos contrarios a los Compromisos. |
| Compatibilidad | ¿Cuáles son los planes para la compatibilidad con las APIs de Privacy Sandbox y la retrocompatibilidad? | Una vez que Chrome lanza una función para la disponibilidad general, nuestro objetivo es mantener la compatibilidad con ella. Por supuesto, no siempre es posible mantener la retrocompatibilidad y, en esos casos, tenemos un proceso claro para la baja y la eliminación de las funciones existentes, que se describe aquí. Esperamos seguir agregando más funciones a las APIs de Privacy Sandbox con el tiempo, en respuesta a los comentarios del ecosistema sobre casos de uso que se beneficiarían de una mejor compatibilidad. En esos casos, solemos incluir algún tipo de técnica de detección de funciones, de modo que una tecnología publicitaria interesada en experimentar con una función nueva pueda preguntarle directamente al navegador si es compatible. Esto es mejor que pedirles a los desarrolladores que verifiquen un número de versión específico de Chrome, ya que es posible que algunas funciones no se lancen para todos los usuarios de Chrome al mismo tiempo. Por ejemplo, nuestro trabajo de detección de componentes para la API de PA se puede encontrar aquí. |
| Implementación del servidor | En lugar de acoplarse a su propia implementación, Chrome debe especificar los comportamientos que debe cumplir una implementación satisfactoria de un servidor de indicadores de confianza, un servidor de agregación y cualquier otro componente no del navegador requerido. Esto permitiría la innovación dentro de límites de privacidad aceptables. | Agradecemos y damos la bienvenida al deseo de innovación de las partes externas. Para todas las APIs y los servicios, nuestro objetivo es proporcionar flexibilidad a las tecnologías publicitarias para implementar su funcionalidad. Por ejemplo, permitimos que las tecnologías publicitarias usen información empresarial confidencial para diseñar la lógica de ofertas para las subastas. Además, interactuamos continuamente con los comentarios de las tecnologías publicitarias y, cuando corresponde, los incorporamos a nuestros diseños. Para permitir que otras personas ejecuten su propio código en entornos de ejecución confiables, Privacy Sandbox deberá revisar el código (y cualquier cambio) para confirmar que cumple con las garantías de privacidad. Esto requerirá un esfuerzo significativo del equipo de Privacy Sandbox. Por lo tanto, nos gustaría comprender qué beneficios busca lograr la parte interesada, que no estamos cumpliendo en la actualidad. |
| Heurísticas | ¿Cuáles son los planes a largo plazo para las heurísticas? | De acuerdo con lo que indicaron otros navegadores, tenemos la intención de retirar estas heurísticas a medida que las soluciones alternativas se vuelvan de uso general, sujeto a un análisis de viabilidad adicional. Compartimos esta información aquí. |
| Volumen de prueba | Volumen de tráfico diferente cuando se comparan diferentes dimensiones. | El experimento del 1% tiene criterios de exclusión que generan diferencias en la elegibilidad para el experimento entre diferentes poblaciones de clientes de Chrome. Por ejemplo, el experimento expulsa a los usuarios de Chrome Enterprise, por lo que se espera que la fracción de tráfico con etiquetas de experimento sea mayor los fines de semana. Es esperable ver diferentes porcentajes de tráfico en diferentes segmentos de datos (como ubicación geográfica, fecha y plataforma), lo que está en línea con lo que observamos en los datos de Chrome. |
| Cómo volver a habilitar 3PC de forma manual | ¿Los sitios podrán saber cuántos usuarios (%) volvieron a habilitar manualmente las cookies después de que se aplique la 3PCD? | Los usuarios podrán volver a habilitar el acceso de 3PC a nivel del sitio mediante la Omisión del usuario si se produce una interrupción. Los 3PC también se pueden volver a habilitar con otras medidas, como la API de Storage Access. Existen medidas técnicas, como hasStorageAccess(), que permiten que los sitios detecten si los 3PC están habilitados o inhabilitados. Sin embargo, Chrome no facilitará una forma para que los sitios web conozcan los motivos de la rehabilitación. |
| Protección contra seguimiento | ¿Durante cuánto tiempo estará disponible la función de la IU de la Protección contra seguimiento de Chrome? | Se espera que la IU de la Protección contra seguimiento en la barra de direcciones permanezca después de que los 3PC dejen de estar disponibles. |
| (También se informó en trimestres anteriores) Compatibilidad con varios navegadores |
Otros proveedores de navegadores que adoptan las APIs de Privacy Sandbox | Otros proveedores de navegadores, como Apple, Mozilla y Microsoft, participan activamente en los foros públicos en los que se analizan los principios de privacidad y los enfoques basados en navegadores. Nos alientan los debates colaborativos en foros como la reciente reunión anual de TPAC del W3C y los foros de PATCG del W3C en curso, en los que vemos signos de convergencia. Por ejemplo, Microsoft Edge anunció recientemente su plan, que “tiene como objetivo maximizar la compatibilidad sintáctica” con la API de PA y ARA, a la vez que ofrece funciones adicionales para los desarrolladores. |
| Opción de resguardo para incorporaciones incompatibles después del 3PCD | Proporciona hooks de API para detectar si un iframe o una incorporación de terceros cumplen con el 3PCD. | Estamos analizando la solicitud aquí y recibimos con gusto comentarios adicionales del ecosistema. |
| Prueba | Solicita marcas adicionales en instancias administradas de Chrome que desactiven temporalmente los comportamientos personalizados. | Estamos considerando esta solicitud para instancias administradas de Chrome y recibimos con gusto las entradas adicionales del ecosistema si esta marca fuera útil. |
Inscripción y certificación
| Tema de los comentarios | Resumen | Respuesta de Chrome |
|---|---|---|
| Verificación de certificación | ¿Cómo garantizará Google la autenticidad de las certificaciones? | Todos los registrantes deben mantener el archivo de certificación mientras usan las APIs. Google valida que el archivo esté en su lugar y que la sintaxis sea correcta, pero no valida el comportamiento de la tecnología publicitaria con respecto al lenguaje de certificación. |
| Proceso de inscripción en la API de Private Aggregation | ¿Existe alguna forma de verificar el estado de la inscripción a la API de Private Aggregation? | Una vez que se haya validado la inscripción, el equipo de asistencia al cliente de la inscripción notificará por correo electrónico a todos los estudiantes aprobados. Si el registrante tiene alguna pregunta durante el proceso, puede comunicarse con el equipo de asistencia al cliente (con el que se comunica cuando envía el formulario de inscripción). El equipo de asistencia al cliente responderá tus preguntas y te brindará la orientación adicional que necesites. |
Muestra anuncios y contenido relevantes
Temas
| Tema de los comentarios | Resumen | Respuesta de Chrome |
|---|---|---|
| (También se informa en trimestres anteriores) Cronología y documentación del clasificador |
Debería haber algún tipo de mecanismo para revisar la clasificación o, al menos, más transparencia sobre cómo el modo de clasificación determina las categorías. | Nuestra respuesta no ha cambiado desde los trimestres anteriores: "La clasificación incorrecta de los sitios puede hacer que el indicador de temas sea un poco menos útil en general, pero los sitios específicos que se clasifican de forma incorrecta no se ven afectados más ni menos que cualquier otro sitio. Esto se debe a que la información contextual de un sitio siempre estará disponible para las subastas en su sitio, lo que proporcionaría información comparable al tema correcto, incluso en el caso de una clasificación incorrecta. Aceptamos comentarios sobre este tema aquí". |
| Google Ad Manager | Google Ad Manager ya está incorporado en la mayoría de los sitios y tendrá información mucho más amplia sobre los temas de los usuarios que la de la competencia, que está presente en menos sitios. | El requisito de observación existe para garantizar que la API de Topics no genere que los datos del usuario se compartan con más entidades que las tecnologías que reemplaza la API (incluidas las 3PC). Otras soluciones de la industria, como Prebid, funcionan con 10,000 de sitios y permiten que los participantes del mercado llamen a la API de Topics a través de su tecnología. Además, vale la pena señalar que el límite de hasta 5 temas principales por semana puede tener un efecto de igualación, ya que los participantes del mercado presentes en muchos sitios que podrían aprender más de 5 temas equivalentes con 3PC se limitarán a 5. |
| (También se informa en trimestres anteriores) Utlilidad para diferentes tipos de partes interesadas |
Preocupaciones sobre el valor creado y la distribución de ese valor para los sitios según su nivel de tráfico o qué tan especializado es su contenido. | Reconocemos que es más probable que los sitios especializados incluyan temas más detallados que los dominios de interés general. Sin embargo, no todos los sitios especializados aportan temas comercialmente valiosos. Además, esta dinámica refleja el statu quo y es completamente independiente del fin de la compatibilidad con 3PC en Chrome. También en el entorno actual, algunos sitios proporcionan más valor que otros en los sistemas de relevancia de anuncios basados en 3PC. Además, los temas entre los sitios especializados pueden ser mutuamente beneficiosos, ya que diversos anunciantes pueden publicar campañas en diversos conjuntos de temas, y la lógica de ofertas puede observar el valor en una amplia variedad de temas. |
| Nombres de host en comparación con URLs completas | ¿La clasificación basada en los nombres de host de los sitios web es lo suficientemente eficaz y reduce el riesgo de privacidad en comparación con las URLs completas? | Consideramos usar URLs de información o títulos de páginas además de los nombres de host, y determinamos que los riesgos para la privacidad y seguridad de los usuarios superaban los posibles beneficios. Un ejemplo de riesgos de privacidad del usuario es la clasificación de la información sensible incluida en la URL o el título de la página en los temas de un usuario. |
| Temas como indicadores | Solicita orientación sobre cómo combinar Topics con otros indicadores y qué otros indicadores podrían ser útiles. | Las soluciones de tecnología publicitaria pueden obtener los mejores resultados combinando todas las herramientas disponibles, como el aprendizaje automático y los indicadores que preservan la privacidad de las APIs que protegen la privacidad, junto con los datos contextuales, los datos de creatividad y los datos de origen. Puedes encontrar más información sobre este tema aquí. |
API de Protected Audience (antes conocida como FLEDGE)
| Tema de los comentarios | Resumen | Respuesta de Chrome |
|---|---|---|
| Volumen de tráfico de prueba | Los verificadores informan un volumen bajo de respuestas de ofertas para la subasta de la API de PA. | 1. La densidad de ofertas se correlaciona con la participación del ecosistema en la API de PA, que prevemos que seguirá aumentando durante el 2024 y más allá. En última instancia, depende de los anunciantes, sus agencias y proveedores de tecnología determinar cómo asignar los presupuestos de las campañas. Esperamos que algunos participantes del ecosistema retrasen su inversión en varias soluciones "sin cookies", incluida la API de PA, hasta después del 3PCD. En ese momento, esperamos que aumenten la asignación del presupuesto de su campaña a esas soluciones. 2. El volumen de solicitudes de ofertas en las subastas de la API de PA puede verse afectado por (1), ya que los publicadores y sus proveedores de tecnología publicitaria pueden decidir no iniciar subastas de la API de PA si consideran que la demanda es baja. Depende de los publicadores determinar la prioridad de actualizar sus páginas y participar. Por estos motivos, anticipamos que los publicadores pueden tomarse un tiempo para probar y aumentar el tráfico gradualmente. Este informe también incluye una respuesta de Google Ad Manager sobre sus controles para publicadores para participar en la API de PA. |
| (También se informó en trimestres anteriores) Fraude o abuso |
¿Cómo puede el ecosistema reducir los riesgos y evitar que los compradores o las personas que actúan de mala fe se posicionen como un público deseable? | Los mecanismos de informes de los anuncios de la API de PA retienen la información que se usa actualmente para distinguir entre el tráfico humano y el de bots. Además, las técnicas actuales basadas en dominios para incluir o excluir dominios se pueden usar en la API de PA. Esto se describe con más detalle en nuestra respuesta al informe de IAB Tech Lab sobre Privacy Sandbox. |
| Restricción del mismo origen en el propietario de IG y la URL de la lógica de ofertas | Con el requisito de origen, los extremos de un propietario de IG se verán obligados a pasar por el mismo balanceador de cargas, lo que puede provocar que se rechacen los redireccionamientos. | El requisito de mismo origen para la carga de secuencias de comandos es una protección de seguridad importante. Aquí encontrarás algunos detalles sobre una solución propuesta que equilibra los comentarios del ecosistema y otras consideraciones. |
| Subasta privada de varios segmentos | Hay mucho espacio para permitir subastas privadas de varios espacios dentro de los límites de privacidad mediante el uso de ruido y una integración más estrecha con las prácticas publicitarias actuales. | Estamos considerando estos comentarios y evaluando la solicitud de subastas de múltiples etiquetas en función de la mayor complejidad y los riesgos de privacidad asociados con esta función. Analizamos este problema en más detalle durante una llamada del grupo comunitario de Web Incubator de la API de PA (WICG) aquí. |
| Vendedores de nivel superior | La estructura actual de la API de PA proporciona a cualquier vendedor de nivel superior muchos más datos y una mejor comprensión del valor relativo de las impresiones que los publicadores o los vendedores de componentes. | En una subasta de varios vendedores, cada vendedor tendrá una oferta más alta. Además, descubrimos que los publicadores podrían considerar la demanda vendida directamente junto con las mejores ofertas de cada vendedor con el que trabajan. Para determinar qué anuncio publicar, es necesario analizar todas estas posibles oportunidades de monetización. Esta situación, en la que es necesario que algún actor vea el conjunto completo de opciones para elegir un anuncio que se publicará, es anterior a la API de PA. La API de PA busca admitir subastas de varios vendedores y el deseo de los publicadores de considerar la mejor oferta de cada vendedor junto con las campañas publicitarias vendidas directamente, cuando corresponda. Esto significa que debe haber un mecanismo para elegir entre esas oportunidades de monetización, como lo hay hoy en día. No creemos que sea el rol del navegador seleccionar qué anuncio publicar. Por lo tanto, el concepto de vendedor de nivel superior es necesario para seleccionar un anuncio ganador entre muchas posibilidades. La lógica de ese vendedor de nivel superior debe poder considerar las mejores ofertas de cada vendedor con el que el publicador elija trabajar. Además, la lógica de ese vendedor puede optar por proporcionar información sobre las campañas vendidas directamente por el publicador cuando esa información esté disponible. Toda esta información se podría considerar en la lógica de selección de anuncios de nivel superior. Esto significa que la lógica de nivel superior ve las mejores ofertas de la subasta de la API de PA y, cuando corresponda, cualquier opción de anuncio vendido directamente por el publicador para determinar un ganador. Google Ad Manager detalla su implementación de la API de PA como vendedor de nivel superior en este informe, en el tema "Acceso a la información". |
| Separación de anuncios de la competencia | Solicitud de separación de anuncios competitivos, como evitar que los anuncios de marcas que compiten aparezcan uno junto al otro | No conocemos una forma de garantizar la separación competitiva en el ecosistema actual de publicidad digital programática, con ofertas y varios vendedores. Sin embargo, la API de PA permite que los vendedores recuperen indicadores adicionales en tiempo real basados en una combinación de renderURL y nombre de host (que representa el dominio del publicador) que se puede usar durante scoreAd() cuando se califican las creatividades. Los vendedores pueden usar esta función para evitar que los anuncios de marcas de la competencia aparezcan uno junto al otro, siempre y cuando el publicador desee aplicar esta regla. |
| Información limitada | La API de PA reduce la información disponible para los publicadores, como el valor del anuncio, el nombre del comprador de componentes, el nombre del anunciante, la URL de la página de destino, el tamaño de la creatividad, el tiempo de respuesta y la tasa de ofertas, así como las ofertas perdidas. | Proponemos algunas posibles soluciones aquí y recibimos con gusto los comentarios adicionales del ecosistema. |
| Informes a nivel del evento | Los publicadores no pueden obtener suficiente información sobre el anuncio publicado después de que se dio de baja la API de PA de informes a nivel del evento. | Sabemos de los diferentes casos de uso de los informes que debemos seguir admitiendo cuando se den de baja los informes a nivel del evento. Por este motivo, establecimos que la fecha de baja de los informes a nivel del evento sea a partir de 2026. Mientras tanto, te invitamos a participar activamente mientras nos involucramos con el ecosistema en caminos duraderos que podrían incluir nuevas ideas para obtener información de una manera que preserve la privacidad. |
| Varias SSP | El valor agregado de tener varias SSP será demasiado bajo para los publicadores. | No creemos que esto sea correcto y nos complacería recibir más comentarios del ecosistema para comprender el fundamento de esta afirmación. |
| Actividades de selección | Las actividades de selección no son posibles con la API de PA. | Recibimos comentarios sobre la capacidad de los vendedores de usar la API de PA para mostrar la información de su público a los compradores en la Web (también conocida como extensión de público). Creemos que esto es posible hoy en día, con la funcionalidad de delegación de la PA junto con los acuerdos comerciales. Al mismo tiempo, estamos considerando activamente si podemos adaptarnos mejor a estos tipos de casos de uso y cómo hacerlo. |
| Inhabilitación del comprador | Es probable que la inhabilitación predeterminada del comprador cause resultados más bajos en las subastas de componentes. | Ya sea que definas una subasta de PA de un solo vendedor o de varios vendedores, el vendedor debe enumerar explícitamente a los compradores en el campo interestGroupBuyers de AuctionConfig. Esto se basa en los comentarios del ecosistema que indican que los vendedores tienen acuerdos contractuales con algunos compradores y no con otros, por lo que se necesitaría un control explícito sobre qué compradores incluir en la subasta. Nos complace debatir más sobre este tema en GitHub. |
| Adsize | No se puede aplicar un filtro previo en función de adsize y adSlotSize. | Estamos trabajando para agregar esta función. Obtén más información aquí. |
| Compatibilidad con la segmentación negativa de IG | Una API para admitir la segmentación negativa de IG: muestra anuncios solo si un usuario no pertenece a un IG. | En este problema de GitHub, se propuso una forma alternativa de implementar la segmentación negativa, en la que el navegador le indica directamente al servidor de anuncios qué reglas de segmentación negativa deben estar vigentes para una solicitud de anuncio en particular. Si bien este parece un enfoque atractivo, todas las versiones de esta idea que investigamos permiten que el servidor identifique al usuario de forma exclusiva. |
| Ley de Servicios Digitales | ¿Cómo puede un publicador usar marcos delimitados y, al mismo tiempo, evitar que se rendericen las respuestas que contengan información sujeta a la Ley de Servicios Digitales? | Al igual que con cualquier tecnología nueva, cada empresa es responsable de garantizar que su uso de Privacy Sandbox cumpla con la ley. Google no puede brindar asesoramiento legal a terceros. Para cada API, publicamos una amplia documentación técnica, que debería proporcionar la base para realizar las evaluaciones legales necesarias. Los marcos delimitados no son obligatorios para usar en la API de PA antes de 2026, lo que les permite a las partes interesadas tiempo adicional para asegurarse de que el uso de esta tecnología cumpla con toda la legislación relevante. |
| Documentación | ¿updateAdInterestGroups() es temporal? | No anunciamos ningún plan para dar de baja updateAdInterestGroup. En el futuro, es posible que apliquemos protecciones de privacidad similares a las que mencionamos públicamente para otros mecanismos de actualización de IG, p.ej., usar una dirección IP como proxy y agregar un retraso antes de que se produzca la actualización. |
| Compatibilidad con metadatos y propiedad de la lógica del comprador para plataformas que no son DSP | Solicita una forma de actuar como proxy para las DSP. | Estamos al tanto de estos comentarios de segmentos que no son de DSP y estamos considerando esta solicitud. Agradecemos los comentarios adicionales del ecosistema. |
| Informes | Solicitud para agregar la función de controlador personalizado para el bucket o el valor de los indicadores en los informes de agregación privada. | Estamos al tanto y esta solicitud de función está en nuestra lista de espera para que se le dé más visibilidad. Aquí puedes enviarnos tus comentarios adicionales sobre el ecosistema. |
| Documentación | ¿Hay un vínculo en el que se puedan ver todos los encabezados de respuesta que debe configurar el anunciante y el dominio del propietario (delegado)? | Estamos planificando actualizaciones de la documentación para aclarar este tema y recibimos con gusto más comentarios del ecosistema. |
| Ofertas de varias torres | Solicita una explicación del flujo de trabajo (entrenamiento y deducción) a través de un diagrama de arquitectura o de bloques sobre cómo se concibe un enfoque de varias torres en el contexto de la API de PA. | Gracias por enviar tus comentarios. Tenemos algunas presentaciones sobre el tema a partir de las cuales esperamos crear documentación adicional. |
| Segmentación negativa | Capacidad de Privacy Sandbox para proteger a los públicos sensibles y a los menores de edad de los anuncios inapropiados, por ejemplo, sobre juegos de apuestas. | La API de PA no considera el contenido de los anuncios que se muestran. Los desarrolladores de tecnología publicitaria que usan PA tienen el control de este proceso. En general, el publicador y sus proveedores de tecnología publicitaria pueden bloquear las creatividades de anuncios en las subastas de Protected Audience con información contextual de la página y conjuntos de reglas del publicador. Esto refleja nuestra comprensión del enfoque del ecosistema para abordar estos desafíos en la actualidad. Para los compradores, la función de segmentación negativa de IG también puede ser útil en algunos casos de uso de cumplimiento. |
| Diseño de API | Google se opone y quiere que las tecnologías publicitarias usen una función de ofertas universales, lo que aumenta la latencia, en lugar de diferentes biddingLogicURLs en diferentes IGs, lo que está permitido. | Durante nuestras conversaciones sobre la latencia de la subasta, destacamos que reutilizar la misma secuencia de comandos en todos los IGs de un comprador haría que las ofertas de ese comprador se ejecutaran más rápido. Esto se explica con más detalle aquí, junto con nuestras otras recomendaciones para mejorar la latencia de la subasta de la API de PA. |
| Marketing basado en las cuentas | La API de PA no es una API sencilla para los casos de uso de marketing basado en cuentas. | Agradecemos los comentarios del ecosistema sobre cualquier caso de uso específico que consideren imposible y les recomendamos a los participantes del ecosistema que continúen con esta discusión a través de nuestro repositorio público de GitHub o de las llamadas semanales. |
| Prueba A/B | Cuando la API de PA se configura en GAM para un publicador, actualmente debe estar habilitada para todo el inventario o para ninguno. Esto limita la capacidad de los publicadores para ejecutar una prueba A/B viable. | Respuesta proporcionada por Google Ad Manager: Los controles de la API de PA en Google Ad Manager (GAM) afectan la capacidad de GAM para usar la API, siempre que esta esté disponible para su uso. Por lo tanto, los publicadores pueden ejecutar pruebas A/B con la funcionalidad de la política de permisos de Chrome para inhabilitar el uso de la API en un subconjunto de tráfico que se usará como grupo de control para una prueba A/B. |
| Aprendizaje automático | Los publicadores necesitan más control sobre el uso propuesto de aprendizaje automático por parte de GAM. | Respuesta proporcionada por Google Ad Manager: En enero de 2024, lanzamos un control que les ofrece a los publicadores la posibilidad de inhabilitar nuestro regulador de aprendizaje automático y habilitar las subastas de la API de PA con vendedores que no son de Google en todo su tráfico. Puedes encontrar más detalles sobre este control en nuestro Centro de ayuda. |
| (También se informa en trimestres anteriores) Subastas de nivel superior |
Posibilidad de usar el servidor de anuncios del publicador de Google sin darle a GAM el control de la subasta de la API de PA de nivel superior | Respuesta proporcionada por Google Ad Manager: Por los motivos que se explican en el informe del tercer trimestre de 2023 de Google, los planes de GAM para la integración de la API de PA no incluyen la compatibilidad con los publicadores que usan GAM como su servidor de anuncios del publicador sin control de la subasta de nivel superior. |
| Acceso a la información | La GAM tiene acceso a información valiosa de la competencia, incluidos los precios de subasta contextuales, los indicadores que los compradores proporcionan a las SSP para la subasta de la API de PA y los parámetros de configuración de las SSP. | Respuesta proporcionada por Google Ad Manager: Durante años, nos hemos enfocado en la equidad de las subastas, lo que incluye nuestra promesa de que ningún precio de ninguna de las fuentes publicitarias no garantizadas de un publicador, incluidos los precios de las líneas de pedido no garantizadas, se compartirá con otro comprador antes de que realice una oferta en la subasta, lo que reafirmamos más adelante en nuestros compromisos con la Autoridad de Competencia de Francia. En el caso de las subastas de la API de PA, tenemos la intención de cumplir nuestra promesa y no compartir la oferta de ningún participante de la subasta con ningún otro participante antes de que se complete la subasta en subastas de varios vendedores. Para que quede claro, no compartiremos el precio de la subasta contextual con ninguna subasta de componentes, incluida la nuestra, como se explica en esta actualización. Además, no usamos información sobre la configuración de subastas de componentes, incluidos los indicadores que los compradores proporcionan a las SSP, como parte de nuestra propia subasta. De hecho, nos complacería que se realicen cambios en la API de PA que permitan a los vendedores de componentes especificar sus configuraciones de subasta de componentes de una manera que no sea visible para el vendedor de nivel superior. |
| Subastas de componentes | Como subasta de nivel superior, GAM controlará qué SSPs ejecutan subastas de componentes para cada oportunidad publicitaria. | Respuesta proporcionada por Google Ad Manager: Como servidor de anuncios del publicador, GAM ofrece una API liviana para las SSP con las que un publicador podría estar trabajando para especificar la configuración de subasta de sus componentes a través de la API de la etiqueta del publicador de Google (GPT). Aquí puedes consultar más detalles al respecto. Si una SSP proporciona una configuración de subasta de componentes a través de esta API, se incluirán en la lista de subastas de componentes para esa oportunidad publicitaria. GAM no impone ninguna restricción a las subastas de componentes incluidas. Cualquier SSP que desee ejecutar una subasta de componentes podrá hacerlo, siempre y cuando el publicador le haya permitido ejecutar el código necesario en su página. |
| Subastas de componentes | GAM podría aplicar un precio mínimo específico y no revelado a cada oferta ganadora de la subasta de componentes. | Respuesta proporcionada por Google Ad Manager: GAM se ha enfocado en la equidad de las subastas durante años. Como parte de nuestro compromiso de mantener una subasta justa y transparente, no admitimos precios mínimos que solo se apliquen a segmentos específicos de la demanda. Ese es un principio coherente en nuestro producto y seguirá siendo así para las subastas de la API de PA. |
| Servidores de anuncios de terceros | Los servidores de anuncios de terceros no tendrían acceso a la participación de Google en la subasta de nivel superior, lo que limitaría su capacidad para beneficiarse de la demanda de la SSP de Google en el contexto de la API de PA. | Respuesta proporcionada por Google Ad Manager: Actualmente, GAM admite la prueba de la API de PA con varios vendedores en GAM a través de la API que se describe aquí. Actualmente, no se admite la participación de GAM como subasta de componentes en otras subastas de nivel superior. |
| (También se informó en trimestres anteriores) Rendimiento de las subastas de la API de PA |
Los verificadores informan que las subastas de la API de PA tienen una latencia alta. | Escuchamos inquietudes sobre la latencia, y esta es una de las razones por las que desarrollamos varias funciones como parte de la API de PA, que permitirán que las SSP establezcan límites en la latencia de la DSP y realicen mejoras que pueden disminuirla. Recientemente, actualizamos nuestra guía de prácticas recomendadas sobre latencia, que incluye más información para aprovechar estas funciones. También seguimos desarrollando nuevas mejoras de latencia, algunas de las cuales se pueden ver aquí. |
| (También se informa en trimestres anteriores) Renderización de video |
Compatibilidad con la renderización de video con la API de PA y marcos delimitados. | En enero, publicamos una demostración de cómo podría funcionar un video in-stream en una subasta de PA, con detalles adicionales sobre los enfoques alternativos. También vemos que los actores del ecosistema comienzan a proponer cómo funciona la renderización de video para los socios que se integran con ellos, como las propuestas de GAM sobre la construcción de renderURL compatible con video o el proceso E2E completo. Además, escuchamos los comentarios del ecosistema sobre los cambios que podemos hacer para aumentar la adopción, y uno de esos cambios se detalla en GitHub. Seguimos participando activamente en el ecosistema para identificar cualquier otro obstáculo para la adopción que podamos encontrar y abordarlo de manera oportuna. |
| (También se informó en trimestres anteriores) Política de Manejo de Datos |
¿Cuál es la política de manejo de datos de la API de IG o PA? | En el diseño de la API de PA, todos los datos almacenados en los IG o sobre qué personas están en qué IG (i) permanecen en el dispositivo o (ii) se procesan en los servicios de ofertas y subastas (B&A) que se ejecutan dentro de un entorno de ejecución confiable (TEE). En ambos casos, ninguna otra parte puede leer los datos ni usarlos de ninguna otra manera que no sea para generar ofertas en la subasta. Algunas mejoras de privacidad que está explorando Chrome implican la interacción con un servidor de k-anonimato administrado por Google. Esa interacción se está diseñando cuidadosamente para evitar compartir información sobre los usuarios y ejecutarse en un TEE para garantizar la paridad de la información en todo el ecosistema de anuncios. Google se comprometió con la CMA a diseñar e implementar las propuestas de Privacy Sandbox de una manera que no distorsione la competencia dando preferencia a su propio negocio, y a tener en cuenta el impacto en la competencia en la publicidad digital y en los publicadores y anunciantes. Seguimos trabajando en estrecha colaboración con la CMA para garantizar que nuestro trabajo cumpla con estas obligaciones. |
| (También se informa en trimestres anteriores) Vida útil de IG |
Solicita la extensión de la vida útil de los IG de 30 a 90 días. | Este tipo de cambio requiere una evaluación cuidadosa en la que se ponderen los beneficios para la industria en función del impacto en los usuarios de Chrome y otras partes interesadas. Estamos considerando esta solicitud y agradecemos los comentarios adicionales que nos envíes aquí. |
| (También se informa en trimestres anteriores) modelingSignals |
Solicita un campo nuevo además de modelingSignals que solo pueda codificar información de clics y de Display. | Respondimos a estos comentarios con una contrapropuesta aquí. Estamos interactuando de forma activa con la industria para comprender sus puntos de vista sobre nuestra propuesta y, actualmente, estamos sopesando los beneficios para la industria en función del impacto en los usuarios de Chrome y otras partes interesadas. |
| Bits adicionales en reportWin() | Proporciona bits adicionales en reportWin() desde el límite actual de 12 antes de 3PCD. | Actualmente, estamos explorando enfoques para admitir este caso de uso. Esto lleva tiempo, ya que también buscamos enfoques que puedan ayudarnos a garantizar que tengamos un plan de privacidad a largo plazo. |
| Diseño de subastas | Son solicitudes de una sola subasta que muestran URLs de renderización con su puntuación correspondiente. | Consideramos compartir varias renderURLs y sus respectivas puntuaciones desde una sola subasta de PA, pero no lo implementamos debido a preocupaciones de privacidad. Entendemos el deseo de evitar mostrar el mismo anuncio varias veces a un usuario en una sola página y nos complace continuar la conversación en GitHub. |
| reportWin | registrar campos arbitrarios en la función reportWin(). | Esto ya está sucediendo durante el período de prueba. Una vez que Chrome finalice la compatibilidad con 3PC, la versión forDebuggingOnly de la API migrará para habilitar la depuración con muestreo reducido, que se especifica aquí. |
| Vendedores de componentes | Tener un mecanismo independiente para registrar sus propias impresiones y otros eventos, y no tener que depender únicamente de los informes de las tecnologías publicitarias | Esta solicitud de función está en nuestra lista de espera para que se le dé más atención. No prevemos abordar este problema durante el período de pruebas facilitadas por Chrome. |
| Facturación de costo por clic | Implementa la facturación de costo por clic en la API de PA. | Estamos considerando esta solicitud aquí y, actualmente, la consideramos una solicitud de sugerencias para implementarla con la plataforma de API actual. |
| browserSignals | Se agregó incomingBidInSellerCurrency a la especificación de browserSignals de informes para el vendedor. | Estamos considerando esta solicitud y agradecemos los comentarios adicionales que nos envíes aquí. |
| Compatibilidad con metadatos orientados a la compra y propiedad de la lógica para plataformas que no son DSP | El diseño actual de la API podría generar un cambio significativo en las campañas de resegmentación a nivel del producto, en las que es posible que las campañas deban migrar a plataformas que funcionen como DSP y proveedores de DCO. | Estamos analizando este problema y recibimos comentarios adicionales aquí. |
| Compatibilidad con metadatos orientados a la compra y propiedad de la lógica para plataformas que no son DSP | Comparte ejemplos en los que la DSP no es el propietario de IG. | Entendemos que los usuarios que no son ofertantes desean utilizar algunas funciones de los IG, pero no otras. Estamos evaluando activamente las opciones para abordar estos casos de uso y recibimos comentarios adicionales aquí. |
| Controles de tiempo de espera | Los publicadores deben poder dictar la cantidad de IGs que pueden participar y el tiempo de espera global o de nivel superior. | Entendemos que deseas mejorar los controles de tiempo de espera y la visibilidad entre los vendedores de componentes y de nivel superior, y estamos considerando esta solicitud. |
| Varios tamaños de anuncios | Compatibilidad de la API de PA para casos de uso de varios tamaños de anuncios | Estamos considerando esta solicitud y agradecemos los comentarios adicionales del ecosistema. |
| Documentación | ¿Existe una lista de atributos de IG que están sujetos a k-anon? | Respondimos esta pregunta aquí. |
| Depuración | Se mejoraron las capacidades de depuración de la API de PA. | Reconocemos la importancia de las herramientas de depuración sólidas para los desarrolladores que trabajan con la API de PA. Nos comprometemos a mejorar la experiencia de los desarrolladores explorando formas de integrar mejor las recuperaciones de archivos .well-known con las herramientas para desarrolladores. Nuestro objetivo es proporcionar una mayor visibilidad y capacidades de solución de problemas en el entorno de desarrollo. Estamos analizando este problema en más detalle aquí y recibimos con gusto más comentarios. |
| Etiquetas | ¿Todos los usuarios de las etiquetas de tratamiento de modo B tienen habilitadas las APIs de Privacy Sandbox? | Las asignaciones de grupos de experimentos de Chrome se determinan de forma aleatoria y son independientes de la configuración de Chrome que establece el usuario. Si bien estas APIs pueden estar disponibles para los usuarios dentro de grupos de tratamiento específicos (p.ej., treatment_1.*), su funcionalidad se puede modificar o inhabilitar a través de la configuración de Chrome. Grupo control_2 del modo B: La inclusión en este grupo inhabilita de forma inherente las APIs de medición y relevancia de Privacy Sandbox, y el usuario no puede anular este parámetro de configuración en la configuración de Chrome. |
| Uso de API | ¿La llamada a reportWin() y la renderización del anuncio se realizan en paralelo o una después de la otra? | Se llama a reportWin() directamente después de que se completa runAdAuction(). Al mismo tiempo, el proceso de renderización de anuncios puede comenzar cuando el resultado de la subasta se coloca dentro de un iframe o un marco delimitado. Después de que reportWin() termine de ejecutarse y el anuncio comience a renderizarse, se recuperarán las URLs proporcionadas a sendReportTo(). |
| (También se informó en trimestres anteriores) Asistencia para pruebas A/B |
Solicita asistencia para las pruebas A/B de la API de PA. | Estamos analizando esta solicitud aquí y agradecemos los comentarios adicionales. |
| Determinación por tráfico | La propuesta de Google para administrar la toma de decisiones requerida a través del servidor KV no es útil, ya que los vendedores no pueden interactuar con su backend, lo que dificulta la configuración del tráfico. | Como se explica en el problema de GitHub, exponer si una DSP individual tiene IGs presentes podría generar inquietudes sobre la creación de huellas digitales de los usuarios. Te sugerimos otras alternativas en el problema y estamos abiertos a más sugerencias. |
| Determinación por tráfico | Los mecanismos de almacenamiento en caché agregan una capa significativa de complejidad y evitan que las DSP conozcan la forma real del tráfico por el que ofertarían. | El mecanismo de almacenamiento en caché se ofreció solo como sugerencia. Las plataformas de tecnología publicitaria pueden optar por usar las sugerencias que se ajusten a su caso de uso. Te invitamos a que participes en el debate aquí. |
| Etiquetas | Chrome debe compartir la etiqueta como un parámetro en las solicitudes a los servidores de confianza del comprador y del vendedor. | Esta parece ser una solicitud razonable, ya que parece estar ampliamente alineada con el objetivo de utilizar los datos de IG de forma responsable. Sin embargo, estamos considerando la solicitud, sujeta a revisión interna, y proporcionaremos actualizaciones públicas sobre este asunto a medida que avancen las conversaciones. |
| Uso de API | Se aclare la definición explícita del grupo "control_1" en el documento "Orientación adicional de la CMA a terceros sobre pruebas". Específicamente, existe la preocupación de que un cambio en el texto se malinterprete como una exigencia de exclusión de todas las APIs de Privacy Sandbox de control_1. | Expresamos nuestras opiniones sobre este tema en esta conversación de GitHub. Dicho esto, no podemos hablar en nombre de la CMA y sugerimos que cualquier problema relacionado con la interpretación de su guía de pruebas se comunique directamente con la CMA. |
| Uso de API | ¿Chrome permitirá llamar a joinAdInterestGroup() en una página en blanco mientras redirecciona a otro recurso? | Si un usuario visita un sitio, el propietario del sitio puede delegar la capacidad de llamar a joinAdInterestGroup a un tercero. Esta delegación permite que un tercero compile IG sin necesidad de agregar ningún tipo de redireccionamiento a través de una página en blanco. Agradecemos los comentarios sobre los motivos específicos para compilar IG en medio de un redireccionamiento en lugar de usar el mecanismo de delegación previsto. |
| Uso de API | Los intercambios deben poder escribir IG en las páginas que pertenecen a los publicadores con los que trabajan y, luego, delegar el permiso para ofertar en ese IG a cualquier comprador o DSP determinado. | Recibimos los comentarios y estamos evaluando si se puede aceptar una solicitud de este tipo. Agradecemos los comentarios adicionales del ecosistema. |
| Uso de API | No se envía ninguna notificación de pérdida de depuración si nadie gana una subasta de la API de PA. | Las funciones reportWin y reportResult de Chrome están diseñadas para generar informes de ganancias a nivel del evento dentro del sistema de subasta de privacidad (PA). En circunstancias en las que se rechazan todas las ofertas durante una subasta de PA, no se espera que se invoquen estas funciones, ya que no se determina un ganador. Una actualización reciente de Chrome puede explicar las discrepancias en las que las URLs pasadas a forDebuggingOnly.reportAdAuctionLoss() no aparecen en el panel de red de DevTools. Recomendamos verificar esta funcionalidad con una compilación del canal Canary o Dev de Chrome. |
| Uso de API | ¿Puede ser negativo el adCost que se muestra en generateBid (ya se redondea estocásticamente a 2 bytes)? | AdCost es el costo de conversión o clic del anunciante que se pasa de generateBid() a reportWin(). Este valor puede ser nulo o un número doble. Los valores negativos se ignorarán y no se pasarán. El valor se redondeará de forma estocástica cuando se pase. |
| Mejora de la API | ¿Se pueden usar servidores de ejecución confiables y encriptados para controlar la segmentación, las cohortes, la atribución y las subastas en lugar del navegador Chrome? | Te recomendamos que explores los componentes y las opciones basados en TEE en la API de PA (p.ej., servidores KV y servicios de B&A), así como los componentes basados en TEE de Attribution Reporting y Private Aggregation (p.ej., Aggregation Service) que abordan esta pregunta. |
| Mejora de la API | ¿La respuesta de la subasta de Privacy Sandbox puede ser una respuesta de oferta (como las ofertas de encabezado) en lugar de una respuesta de anuncio (como las etiquetas de anuncios)? | Este tipo de cambio cambia de forma fundamental las propiedades de privacidad de la API de PA, por lo que no es algo que estemos considerando. |
| Controles del publicador | ¿Los publicadores pueden bloquear las creatividades de la API de PA en sus páginas? | Chrome tiene una propuesta para el análisis de creatividades en tiempo real que aún no está disponible para pruebas. Si bien esta función aún no está disponible, observamos que la mayoría de las SSP crearon soluciones para habilitarla. |
| Uso de API | ¿Cuál es el límite de tamaño de perBuyerSignals? | En su forma clásica, perBuyerSignals no tiene limitaciones de tamaño inherentes en Chrome. Las restricciones principales son que los datos siguen siendo serializables en JSON y no causan un consumo excesivo de memoria. Sin embargo, ten en cuenta que los perBuyerSignals muy grandes y complejos pueden afectar de forma negativa el rendimiento. Existe un método alternativo para pasar perBuyerSignals a través de directFromSellerSignalsHeaderAdSlot. Este enfoque transmite perBuyerSignals dentro de un encabezado, sujeto a un límite de tamaño máximo de 10 KB para toda la respuesta del encabezado. Además, los servidores individuales pueden imponer sus propias restricciones en el tamaño máximo del encabezado. |
| Documentación | Se debe cambiar la documentación sobre la llamada registerAdBeacon desde dentro de generateBid. | Actualizamos esta documentación el 17 de febrero. |
| Uso de API | ¿Cómo elige reportEvent la URL del píxel contador correcta entre varias opciones registradas? | Cada subasta genera una configuración independiente, que a su vez genera un mapa de informes independiente. Las subastas individuales (y sus marcos resultantes) son completamente independientes entre sí y no comparten datos. La explicación sobre los "informes de anuncios de marcos delimitados" proporciona más detalles sobre este tema. |
| IU de Chrome | Se agregó un filtro en la pestaña "Application -> "Interest groups" de DevTools de Chrome, lo que permite filtrar por propietario del IG (o tal vez también por nombre del IG). | Estamos evaluando esta solicitud y recibimos con gusto los comentarios adicionales del ecosistema. |
| Chrome sin interfaz gráfica | Compatibilidad con la API de PA en Chrome sin interfaz gráfica | Hay algunos componentes de la API de PA que están vinculados a Chrome, por ejemplo, las llamadas k-anon a los servidores de Google, que pueden no funcionar en el "antiguo" Chrome sin cabeza. Creemos que esto se puede abordar con la "nueva" versión de Chrome sin cabeza que se lanzó en Chrome 112. |
| Uso de API | En el caso de los informes de pérdidas con reportAdAuctionLoss, en muchos casos, vemos "topLevelWinningBid=0". ¿Cuál es la interpretación de esto? | El valor de topLevelWinningBid proviene de la función scoreAd() dentro del componente del vendedor de nivel superior. Este valor es importante para determinar el resultado de la subasta de nivel superior. Según la explicación, un valor de topLevelWinningBid de cero o cualquier número negativo significa que el anuncio correspondiente no es apto para ganar la subasta. Este mecanismo se puede emplear, por ejemplo, para filtrar los anuncios segmentados por grupo de intereses que no superan a un candidato segmentado de forma contextual. Si bien un topLevelWinningBid con valor cero puede indicar que prevaleció una subasta contextual, la especificación de la API de PA reconoce que otros factores podrían contribuir a este resultado. |
| Pruebas A/B de modo | Se aclare la selección de tráfico y los mensajes de inhabilitación del modo B y el modo A. | Los criterios de inclusión para el modo A y el modo B son los mismos. El objetivo es tener grupos que sean representativos del tráfico normal de Chrome, siempre y cuando admitan las APIs de Privacy Sandbox y el método de etiquetado, por lo que algunas configuraciones de cliente no son compatibles. Para los fines del experimento, es importante comparar solo el tráfico etiquetado con otro tráfico etiquetado. Los usuarios en el modo B tienen habilitada la función de Protección contra seguimiento y, por lo tanto, reciben una notificación sobre esa función. |
| Mejora de la API | ¿Se puede incluir "lifetimeMs" como una propiedad directa dentro de la llamada a joinAdInterestGroup o administrarla como un argumento independiente? | Estamos considerando cuidadosamente los comentarios de la comunidad de desarrollo web sobre la funcionalidad "joinAdInterestGroup" dentro de la propuesta de la API de PA. Un punto de debate clave se centra en el método óptimo para administrar las duraciones de IG. Estamos evaluando los beneficios de un argumento independiente para el parámetro "lifetimeMs", ya que promueve la flexibilidad y la adaptabilidad para posibles mejoras futuras en la especificación. Estamos analizando este problema aquí y recibimos con gusto más comentarios. |
| Uso de API | Posibilidad de aumentar las tasas de falsos negativos en el framework de la API de PA debido a colisiones con IDs de navegador de baja entropía. | El equipo de Chrome participa activamente en el perfeccionamiento continuo del framework de la API de PA. Agradecemos la conversación sobre las posibles tasas de falsos negativos que surgen de las colisiones de IDs de navegador. Estamos evaluando cuidadosamente estos comentarios y trabajaremos para garantizar que los análisis actualizados reflejen de forma integral todos los factores relevantes. Nuestro compromiso es ofrecer una solución que logre los resultados de privacidad deseados y, al mismo tiempo, mantenga la precisión y la confiabilidad. Estamos analizando este problema aquí y agradecemos tus comentarios adicionales. |
| Uso de API | ¿Es necesario un identificador de navegador de baja entropía para evitar que los clientes envíen solicitudes de “Unión” de forma reiterada para el mismo objeto en un sistema de k-anonimato? | Reconocemos y agradecemos el debate en curso sobre el uso de identificadores de navegadores en la implementación de sistemas de k-anonimato. Entendemos las inquietudes sobre las posibles implicaciones de privacidad de dichos identificadores. Si bien nuestra implementación inicial empleó un identificador de baja entropía como mecanismo contra el abuso, estamos explorando activamente técnicas alternativas, como los tokens de recuento anónimos, que priorizan la privacidad del usuario y, al mismo tiempo, mantienen la integridad del sistema. Nos comprometemos a encontrar soluciones que equilibren el uso responsable de los datos con protecciones de privacidad sólidas y damos la bienvenida al diálogo continuo con la comunidad de investigación. Estamos analizando este tema aquí y recibimos con gusto más comentarios. |
| Uso de API | ¿AMP (Accelerated Mobile Pages) admite la API de PA? | Actualmente, AMP no es compatible de forma nativa con la API de PA. Agradecemos los comentarios adicionales del ecosistema si la compatibilidad con AMP es una prioridad alta. |
| Mejora de la API | Considera quitar el tipo de las verificaciones de k-anonimato. | Estamos considerando cuidadosamente los comentarios sobre la posible optimización de las estructuras de solicitudes de k-anonimato. Entendemos la sugerencia de consolidar los parámetros y, posiblemente, unificar los tipos para optimizar el proceso. Nuestro objetivo es garantizar la eficiencia y la capacidad de mantenimiento, y estamos evaluando todas las opciones a medida que seguimos desarrollando nuestras soluciones de privacidad. Estamos analizando este problema aquí y recibimos con gusto más comentarios. |
| IU de Chrome | Solicita un mecanismo para que los usuarios menos técnicos puedan ver y administrar fácilmente los IG a los que pertenecen, incluidos los posibles controles a nivel del sitio web para inhabilitar la opción. | Reconocemos la importancia de proporcionar herramientas fáciles de usar para comprender y administrar los IG. Consideramos cuidadosamente varios métodos y descubrimos que identificar los IG por el sitio web al que se unieron ofrece el mejor equilibrio entre claridad y protección de la privacidad. Actualmente, la administración global de los IG se encuentra en la configuración de Chrome. Exploramos continuamente formas de mejorar aún más la experiencia del usuario en esta área. Estamos analizando este problema aquí y agradecemos tus comentarios adicionales. |
| Seguridad de la API | ¿La API de PA es vulnerable a filtraciones de privacidad a través de interacciones con anuncios de creatividades, incluso en el contexto de marcos delimitados? | Reconocemos el potencial de filtración de información a través de interacciones sofisticadas con los anuncios. Estamos investigando de forma activa la interacción entre los marcos de seguridad, la API de PA y los posibles vectores de ataque. Mitigar los riesgos de privacidad es una prioridad, y nos comprometemos a desarrollar soluciones sólidas que equilibren la innovación con la protección de los usuarios. Estamos analizando este problema aquí y agradecemos tus comentarios adicionales. |
| Latencia | ¿El tiempo de espera predeterminado de 50 ms para la lógica de ofertas del comprador es un valor realista? | Reconocemos las inquietudes planteadas sobre posibles inconsistencias entre la especificación y el tiempo de las solicitudes de red para la lógica de ofertas. Estamos revisando de forma activa las especificaciones para garantizar su precisión y analizando la configuración de tiempo de espera predeterminado óptima para equilibrar el rendimiento y la viabilidad. Estamos analizando este problema aquí y recibimos con gusto más comentarios. |
| Documentación | Posible filtración de tiempo en la especificación en la que un sitio web podría inferir si un anuncio no cumplió con el umbral de k-anonimato y las posibles implicaciones para el seguimiento entre sitios | Reconocemos el problema que se planteó en relación con una posible filtración de tiempo. Confirmamos que hay una discrepancia en la especificación y estamos tomando medidas para garantizar que el estado de k-anonimato de los anuncios se determine antes de la subasta para evitar esas filtraciones. Nos tomamos muy en serio estas inquietudes y actualizaremos la especificación para reflejar estos cambios. Estamos analizando este problema aquí y recibimos con gusto más comentarios. |
| Uso de API | Formas de implementar una lista de entidades bloqueadas de SSP en la API de PA | Reconocemos la necesidad de mecanismos para administrar las restricciones de anuncios de las SSP. Te recomendamos que explores soluciones que prioricen la evaluación integrada en el dispositivo y aprovechen los metadatos de anuncios existentes para proteger la privacidad del usuario y, al mismo tiempo, permitir la flexibilidad. Nos comprometemos a trabajar con los desarrolladores para identificar los enfoques óptimos dentro de la API de PA. Estamos analizando este problema aquí y agradecemos tus comentarios adicionales. |
| Uso de API | ¿Puede alguien decirle a su navegador que finja usar la API de PA de una manera que los sitios no puedan detectar? | Reconocemos que, en su forma actual, los sitios web podrían detectar la inhabilitación de la API de PA. Estamos trabajando activamente en funciones como las ofertas adicionales y la segmentación negativa, junto con la renderización de marcos delimitados, para mejorar la privacidad y ofrecer opciones de inhabilitación indetectables. Estamos analizando este problema aquí y agradecemos tus comentarios adicionales. |
| Pruebas A/B de modo | Tráfico de centros de datos que se presenta como tratamiento 1.1 | El equipo de Chrome confirmó con el equipo de GAM que este tráfico ahora se filtra fuera del experimento. Estamos analizando este problema aquí y agradecemos tus comentarios adicionales. |
| Uso de API | Eficiencia y equidad de la implementación de interestGroupBuyers en la API de PA. | Reconocemos el debate en curso sobre la eficiencia y equidad del campo "interestGroupBuyers" en las subastas de la API de PA. Reconocemos las compensaciones entre eficiencia, privacidad y equidad del mercado. Si bien los vendedores deben administrar las relaciones comerciales con los compradores, estamos explorando formas de optimizar el proceso de coincidencia. Estos pueden incluir ajustes dinámicos basados en datos en tiempo real y modelos híbridos. Mantenemos nuestro compromiso de encontrar soluciones que prioricen la privacidad del usuario y respalden un ecosistema publicitario competitivo. Estamos analizando este problema aquí y agradecemos tus comentarios adicionales. |
| IU de Chrome | Posible problemas de memoria y claridad de la IU relacionados con IG en Chrome. | Entendemos las inquietudes que se plantearon sobre la visualización de IG en DevTools. Si bien la vista actual refleja todos los eventos de IG para el seguimiento histórico, reconocemos el valor de proporcionar una visibilidad más clara del estado actual de los IG almacenados. Exploraremos las optimizaciones y las posibles mejoras de la IU para mejorar las estadísticas de los desarrolladores. En cuanto a la administración de la memoria, la implementación de IG está diseñada para evitar fugas de memoria, pero supervisamos y optimizamos el uso de recursos de forma continua. Estamos analizando este problema aquí y agradecemos tus comentarios adicionales. |
| Documentación | El usuario que publicó el mensaje original encuentra un error cuando intenta usar tamaños de anuncios nombrados directamente en el campo "sizeGroup" de la función "joinAdInterestGroup". Quieren saber si este es el comportamiento esperado. | Reconocemos el valor de optimizar la configuración de anuncios dentro de la función "joinAdInterestGroup". Estamos trabajando de forma activa para abordar esta limitación y planeamos habilitar esta función en actualizaciones futuras. Esta mejora se alinea con nuestro compromiso de proporcionar a los desarrolladores herramientas flexibles y eficientes para la administración de anuncios. Estamos analizando este problema aquí y agradecemos tus comentarios adicionales. |
| Etiqueta de pruebas facilitadas por Chrome | Solicita tener datos directos sobre el modo A en comparación con el modo B y etiquetas exactas en sendReportTo para que podamos hacer un seguimiento del experimento de forma coherente. | Estamos analizando esta solicitud aquí y agradecemos los comentarios adicionales. |
| Documentación | ¿El nombre de dominio del vendedor se incluye en las solicitudes que se realizan al servidor de confianza de un vendedor con fines de validación? | Reconocemos la omisión inicial del parámetro de nombre de host de la documentación de la API del servidor de KV de Protected Audience. Queremos asegurarles a los desarrolladores que el nombre de dominio del vendedor se incluye automáticamente en las solicitudes al servidor de confianza del vendedor. Esta funcionalidad es esencial para los procesos de validación de anuncios sólidos. Actualizamos la documentación para abordar esta omisión y seguiremos priorizando la claridad y la transparencia para la comunidad de desarrolladores. Estamos analizando este problema aquí y agradecemos tus comentarios adicionales. |
| Uso de API | Posibles métodos para incluir el nombre de la IG en las llamadas de seguimiento de impresiones de anuncios con fines de informes | Nos comprometemos a equilibrar la necesidad de mecanismos de denuncia sólidos con el principio fundamental de la privacidad del usuario. La inclusión de nombres de IG en el seguimiento de impresiones de anuncios está sujeta a protecciones de k-anonimato diseñadas para evitar la identificación de personas. Seguiremos explorando soluciones innovadoras de informes dentro de estas limitaciones de privacidad. Estamos analizando este problema aquí y agradecemos tus comentarios adicionales. |
| Función de la API | Solicita que el servidor de confianza del comprador reciba los encabezados HTTP de las sugerencias del cliente. | Estamos haciendo un seguimiento de esta solicitud de función aquí. |
| Uso de API | Si el archivo de delegación debe requerir que se cargue el encabezado "Access-Control-Allow-Origin", dado que dicta el comportamiento de membresía de IG para el navegador | Nos comprometemos a alinearnos con las prácticas recomendadas de seguridad web. El requisito del encabezado "Access-Control-Allow-Origin" para los archivos de delegación garantiza la coherencia con los principios de CORS y evita la exposición no intencional de información sensible. Estamos explorando formas de optimizar este proceso y, al mismo tiempo, mantener una postura de seguridad sólida. Estamos analizando este problema aquí y agradecemos tus comentarios adicionales. |
| Uso de API | Habilita los servidores de anuncios para que personalicen las creatividades dentro del framework de la API de PA. | Reconocemos el papel que pueden tener los servidores de anuncios en la personalización de creatividades. Estamos explorando activamente soluciones para potenciar los servidores de anuncios dentro de la API de PA, como el modelo de "IG conjunto", en el que se podrían combinar las ofertas y la lógica de selección de creatividades de anuncios. Nuestro objetivo es lograr un equilibrio entre habilitar capacidades sólidas de creatividades publicitarias y proteger la privacidad del usuario. Aquí, damos la bienvenida a más colaboración y comentarios sobre la evolución de la API para satisfacer las necesidades de todas las partes interesadas. |
| Preocupaciones sobre privacidad | Disponibilidad de identificadores alternativos (p.ej., RampID, ID5) en las solicitudes de ofertas contextuales podrían socavar los objetivos de privacidad de la API de PA, ya que facilitan la recopilación de datos entre sitios. | Reconocemos la posible tensión entre los identificadores entre sitios y los objetivos de privacidad de la API de PA. Si bien los publicadores pueden optar por compartir esos identificadores, el diseño de la API de PA se orienta, en esencia, a desvincular la selección de anuncios de la necesidad de realizar un seguimiento entre sitios. Nos comprometemos a fomentar un ecosistema de publicidad centrado en la privacidad y recomendamos a los desarrolladores que prioricen el enfoque de la API de PA. Estamos analizando este problema aquí y agradecemos tus comentarios adicionales. |
| Almacenamiento en caché | ¿Hay alguna manera de evitar la reutilización de secuencias de comandos de ofertas en varias subastas? | Reconocemos el comportamiento observado de almacenamiento en caché de las secuencias de comandos de ofertas dentro del framework de la API de PA. Si bien se admiten los mecanismos de almacenamiento en caché HTTP estándar, existe la posibilidad de volver a usar secuencias de comandos en todas las subastas debido al comportamiento de suspensión del dispositivo y al diseño de los ejecutores de ofertas. El equipo está investigando soluciones para proporcionar a los compradores un mayor control sobre la caché de secuencias de comandos para administrar sus estrategias de ofertas de manera eficaz. Estamos analizando este problema aquí y agradecemos tus comentarios adicionales. |
| Uso de API | Centraliza los informes de la actividad de ofertas en todos los IG de una DSP y, al mismo tiempo, respeta la privacidad del usuario. | Priorizamos la privacidad del usuario cuando diseñamos la API de PA. Si bien no es posible generar informes directos de eventos de ofertas individuales debido a los riesgos de seguimiento entre sitios, ofrecemos mecanismos como el almacenamiento compartido y la agregación privada. Estos permiten que las DSP obtengan estadísticas agregadas sobre la actividad de ofertas de una manera que preserva la privacidad del usuario. |
| Uso de API | La recuperación de sendReportTo() en reportResult() solo ocurre el 94% de las veces en relación con obtener una recuperación registrada con forDebuggingOnly.reportAdAuctionWin(). | Si bien es posible que no tengan el mismo tiempo de espera, es posible que ambas URLs se recuperen al mismo tiempo. En algunos casos, se eliminó la worklet del vendedor del componente y se debe volver a cargar para ejecutar la función reportResult(). Sin embargo, ni el tiempo que se tarda en recuperar la lógica de puntuación ni el tiempo que tarda la worklet en volver a cargar afectan el tiempo de espera de 50 ms de reportResult(). Ten en cuenta que Chrome usará encabezados de almacenamiento en caché para definir su comportamiento de recuperación en los casos en que se deba volver a cargar la worklet. Puedes obtener más información sobre las fases de una subasta de PA aquí. |
| K-anonimato | Solicitud de confirmación de que el nombre de interestGroup no afecta el k-anonimato de la publicación de anuncios. | Para que una creatividad se considere k-anónima, la tupla de la URL del propietario de IG, la URL de la secuencia de comandos de ofertas, la URL de la creatividad y el tamaño del anuncio deben cumplir con el umbral especificado (k) durante un período anterior (w). El estado de k-anonimato se actualiza periódicamente (p). |
| IU de Chrome | Propuesta para proporcionar el tipo de "visibilidad interna" que ofrecen muchos frameworks de MVC, ORM, etc. p.ej., comienza con el registro simple de eventos internos seleccionados en un panel nuevo en la sección Herramientas para desarrolladores --> Aplicación --> Aplicación | Estamos analizando la propuesta aquí y recibimos con gusto más comentarios. |
| IU de Chrome | La unión de Dev Tools IG no muestra elementos relacionados con la prioridad. | Tratamos este problema aquí. |
| Mejoras en la API | Lo más conveniente es permitir que el servidor de anuncios de la creatividad realice un seguimiento de sus propios eventos. ¿Se puede configurar una lista de dominios de seguimiento permitidos? | Compartimos una propuesta aquí y recibimos con gusto los comentarios adicionales del ecosistema. |
| Solicitud de funciones de la API | ¿Se puede extender la API de PA para admitir transacciones de medios que no sean de RTB y mantener casos de uso fundamentales, como la publicación de anuncios y la DCO? | Estamos analizando el problema aquí y agradecemos tus comentarios adicionales. |
| Tiempo de espera de la subasta del publicador | Los publicadores necesitan controlar la duración de las subastas para evitar la pérdida de impresiones, especialmente en las configuraciones de ofertas de encabezado, en las que los anuncios se seleccionan de forma secuencial. | Reconocemos la importancia de brindarles a los publicadores un control detallado sobre los tiempos de espera de las subastas de anuncios. Estamos explorando de forma activa cómo implementar un mecanismo de tiempo de espera de subasta global, posiblemente dentro del objeto "auctionConfig", y considerando cuidadosamente los casos extremos. El objetivo de esta función es optimizar los porcentajes de relleno de impresiones para los publicadores, y seguiremos colaborando con la comunidad para encontrar la mejor solución. Estamos analizando el problema aquí y agradecemos tus comentarios adicionales. |
| Mejora de la API | El diseño actual de los IG en la API de PA genera tamaños de metadatos grandes debido a las renderURLs largas. Los verificadores desean encontrar una forma de comprimir estas URLs para lograr una mayor eficiencia. | Reconocemos la importancia de optimizar el tamaño de los metadatos de IG, en particular para las subastas de anuncios sensibles a la eficiencia. Creemos que una solución basada en plantillas para comprimir renderURLs ofrece un potencial significativo. Evaluaremos cuidadosamente los diseños de plantillas propuestos y nos aseguraremos de que cualquier solución implementada incluya mecanismos sólidos de prevención de abusos para mantener la estabilidad del navegador. Colaborar con la comunidad de estándares web para desarrollar el enfoque óptimo, teniendo en cuenta estas consideraciones, sigue siendo una prioridad. Estamos analizando el problema aquí y agradecemos tus comentarios adicionales. |
| Uso de API | Los verificadores que controlan los formatos de anuncios nativos desean optimizar el proceso de subasta de Privacy Sandbox recuperando varios resultados de anuncios en una sola llamada para reducir la carga de la red y mejorar la velocidad de renderización de los anuncios. | Reconocemos las inquietudes sobre el rendimiento que se plantearon en relación con la renderización de anuncios nativos en Privacy Sandbox. Nos comprometemos a encontrar un equilibrio entre la eficiencia y las protecciones de privacidad sólidas para los usuarios. Si bien mostrar varios anuncios con puntuaciones completas compromete la privacidad, estamos explorando activamente formas de optimizar el proceso de subasta. Nos dedicamos a mejorar la compatibilidad de la API de PA con los formatos de anuncios nativos y a investigar mecanismos alternativos para mejorar la eficiencia dentro de las estrictas restricciones de privacidad de Privacy Sandbox. Estamos analizando el problema aquí y agradecemos tus comentarios adicionales. |
| Uso de API | Flexibilidad en la forma en que se califican y ordenan las ofertas de anuncios en Privacy Sandbox, especialmente para representar niveles de prioridad o reglas de mercado privado | Entendemos la necesidad de un control detallado sobre la puntuación y clasificación de los anuncios en Privacy Sandbox, en especial en situaciones de ofertas complejas. Reconocemos las soluciones propuestas que usan tuplas y funciones matemáticas para lograr una puntuación multidimensional sin sacrificar la privacidad del usuario. Si bien estos enfoques pueden agregar complejidad para los desarrolladores, ofrecen la expresividad necesaria. Nos comprometemos a explorar formas de optimizar estos procesos, posiblemente a través de funciones de ayuda o lineamientos, para garantizar un uso óptimo de las funciones de Privacy Sandbox para la lógica de subasta avanzada. Estamos analizando este problema aquí y agradecemos tus comentarios adicionales. |
| reportEvent() | Agrega un nuevo evento reservado (tal vez un píxel contador automático) que el navegador active una vez que se inicialice un marco con una creatividad del anuncio. | Estamos analizando esta solicitud aquí y agradecemos los comentarios adicionales. |
| adCost | Permite el desglose de adCost. | Cada valor de costo es una oportunidad para enviar una cantidad limitada de información fuera de la subasta. Permitir una lista completa de N de esos costos sería suficiente para enviar un identificador de usuario completo, lo que permitiría el seguimiento entre sitios. Estamos analizando este tema aquí y agradecemos los comentarios adicionales. |
| resolveToConfig | ¿Se debe heredar resolveToConfig del nivel superior y exponerse en browserSignals? | Estamos analizando esta solicitud aquí y agradecemos los comentarios adicionales. |
| Mejores herramientas | ¿Hay algo similar a chrome://topics-internals, pero para la API de PA? | No hay nada exactamente igual. Sin embargo, hay herramientas de desarrollador extensas para la API de PA. |
| Etiquetas | ¿Puede Chrome usar etiquetas para identificar el 20% de la población de K-anon? | Estamos considerando esta solicitud y agradecemos los comentarios adicionales del ecosistema. |
| Documentación | ¿Las worklets de subasta de Privacy Sandbox se convertirán en tipos de worklets estándar? | Debido a requisitos únicos de privacidad y seguridad, estos worklets difieren significativamente de los tipos de worklets estándar del navegador, por lo que no prevemos que se conviertan en tipos de worklets estándar dentro de la especificación HTML pronto. Nos comprometemos a mejorar nuestros recursos para desarrolladores con explicaciones claras sobre el entorno de implementación y ejecución de los worklets de subasta, lo que hará que esta información sea más accesible para los participantes de Privacy Sandbox. Aquí, analizamos este tema en más detalle. |
| Servidor de par clave-valor (KV) de trae tu propio servidor (BYOS) | Es posible que las partes puedan conocer varios IG (del mismo propietario) a los que se unió un usuario a través de consultas de servicios de KV en una configuración de servicio de KV de BYOS. | Esto ya no será posible cuando los servidores de KV se ejecuten en TEE y podamos asegurarnos de que cumplan con el modelo de confianza publicado. |
| userBiddingSignals | actualizar parte de "userBiddingSignals" y mantener otros. | Esto ya es posible sin necesidad de realizar cambios en la API. |
| Uso de API | Implementa el límite de frecuencia en varios IG dentro de Privacy Sandbox, posiblemente con el servidor KV o los datos modificados de "prevWinsMs". | Reconocemos el deseo de tener capacidades avanzadas de limitación de frecuencia en Privacy Sandbox. Reconocemos que las restricciones actuales sobre el uso compartido de datos entre los IG pueden presentar desafíos cuando se implementan estas estrategias. Si bien el servidor de KV proporciona un posible mecanismo con las protecciones de privacidad adecuadas, recomendamos a los desarrolladores que exploren soluciones dentro de un solo modelo de IG. Estamos analizando este problema aquí y agradecemos tus comentarios adicionales. |
| Uso de API | Los vendedores de componentes (aquellos que participan en subastas anidadas dentro de Privacy Sandbox) necesitan visibilidad de los tiempos de espera de subasta de nivel superior para optimizar sus propias configuraciones y evitar demoras innecesarias. | Reconocemos la necesidad de mejorar la coordinación del tiempo de espera entre los vendedores de nivel superior y los vendedores de componentes dentro de Privacy Sandbox. Estamos investigando activamente la incorporación de nuevos mecanismos de tiempo de espera, incluido un posible tiempo de espera de la subasta completa, y explorando formas de aplicar tiempos de espera de nivel superior a las subastas de componentes. Nuestro objetivo es mejorar la eficiencia y la previsibilidad para todos los participantes del proceso de subasta de Privacy Sandbox. Estamos analizando este problema aquí y agradecemos tus comentarios adicionales. |
Servicios de Protected Audience
| Tema de los comentarios | Resumen | Respuesta de Chrome |
|---|---|---|
| Entornos de ejecución confiables (TEE) | ¿Es más costoso ejecutar TEE en nubes públicas en comparación con los centros de datos de tecnología publicitaria local? | Nuestra respuesta es similar a la de trimestres anteriores: Nuestro modelo de seguridad de TEE actual se beneficia de las prácticas de las implementaciones de la nube pública. En particular, los TEE actuales basados en hardware no protegen contra todos los ataques físicos. Nuestros proveedores de servicios de nube pública admitidos existentes, AWS y Google Cloud, diseñaron e implementaron mitigaciones para los riesgos de acceso físico, incluidos los de los empleados. Consulta los siguientes detalles sobre la asistencia en las instalaciones. Las tecnologías publicitarias nos mencionaron que ejecutar servicios en la nube es más costoso que los centros de datos de tecnología publicitaria en las instalaciones. Si bien no estamos en condiciones de evaluar esas afirmaciones, recibimos con gusto comentarios adicionales sobre los costos y seguimos evaluando opciones para expandir nuestra compatibilidad con TEE. |
| TEEs | Compatibilidad con TEE en entornos de nube no públicos | Nuestra respuesta es similar a la de trimestres anteriores: Si bien seguimos explorando la compatibilidad con opciones más allá de las soluciones basadas en la nube pública, no tenemos planes actuales para admitir TEEs en las instalaciones. En esta etapa, dados los requisitos de seguridad de Privacy Sandbox y los desafíos significativos que presentan las implementaciones locales, creemos que lo más beneficioso para el ecosistema es seguir expandiendo y mejorando las implementaciones basadas en la nube (por ejemplo, admitir Google Cloud además de AWS). Sin embargo, recibimos con gusto comentarios adicionales sobre por qué este requisito es necesario y factible, dadas las limitaciones de privacidad y seguridad. |
| Otros proveedores de servicios en la nube | Compatibilidad con otros proveedores de servicios en la nube | Siempre estamos abiertos a sugerencias para otros proveedores de servicios en la nube, pero planeamos admitir, al menos, Google Cloud y AWS cuando se aplique la 3PCD. Consulta esta explicación para obtener más información. |
| API de B&A Services | ¿Cuál es la dirección de Google para la API de B&A Services? ¿Se priorizará por encima o por debajo de Protected Audience del navegador Chrome en las subastas de dispositivos? | Nuestra respuesta es similar a la de trimestres anteriores: Seguimos comprometidos con el diseño actual de ofertas en el dispositivo de Protected Audience. Se propusieron los servicios de B&A para explorar posibles soluciones que admitan un subconjunto de casos de uso en los que la potencia de procesamiento o la velocidad de red del dispositivo pueden ser limitadas. |
| Estandarización | Los servicios de B&A no pasaron por un proceso de estandarización. | La propuesta de servicios de B&A se encuentra en medio de una fase del proceso de estandarización y agradecemos la participación adicional para respaldar ese objetivo. Comenzó con una propuesta (basada en propuestas anteriores), se está incubando públicamente a través de un amplio debate abierto en el W3C, y los desarrolladores interesados pueden comenzar a experimentar con ella y enviar comentarios. Este es el patrón habitual para el desarrollo de funciones web, como se describe, por ejemplo, en nuestra entrada de blog aquí. |
| Servidor de KV | Expone la URL completa al servidor de KV del comprador para la segmentación de contenido, contextual o de sitios. | Estamos analizando esta solicitud aquí y agradecemos los comentarios adicionales del ecosistema. |
| Documentación | La documentación sobre "Componentes de confianza o forzosos en comparación con los opcionales" en GitHub genera confusión con algunas tecnologías publicitarias que tienen su propio conjunto de imágenes de implementación y de infraestructura. | Queremos mejorar la documentación sobre "Componentes de confianza o obligatorios en comparación con los opcionales" y nos interesa saber si el ecosistema considera que este trabajo debe priorizarse. |
| Mejora de la API | El código de estado HTTP de una llamada al servidor de KV también debe estar disponible para la función scoreAd() como parámetro. | Estamos evaluando esta solicitud y recibimos con gusto los comentarios adicionales del ecosistema. |
| Documentación | Proporciona más información sobre cómo se manejarían exactamente las cargas de trabajo de JS y WASM con la ejecución de UDF. | Estamos analizando la posibilidad de proporcionar esta información y agradecemos los comentarios adicionales aquí. |
| Documentación | Solicitud para actualizar el nombre del repositorio | Cambiamos el nombre del repositorio a "protected-auction-key-value-service". Esto está en línea con el término de la colección de servicios a la que pertenece, que también tiene otros repositorios, como la discusión de los servicios de Protected Audience y los repositorios de la documentación de los servicios de Protected Auction. |
| Documentación | Se quitó la referencia a la API de Cloud Debugger en bidding_auction_services_gcp_guide.md. | Actualizamos la documentación y quitamos la referencia. |
| Uso de API | La latencia que genera la búsqueda de KV tarda más de 50 ms. Tarda casi 100 ms. ¿Tienes alguna guía sobre lo que les ha funcionado bien a otros vendedores? ¿Tienes alguna sugerencia para medir los tiempos de espera y los tiempos? |
La llamada al servidor de KV se realiza dentro del contexto de los ejecutores de secuencias de comandos, es decir, el entorno protegido especial dentro del navegador Chrome. Su objetivo es mantener la información de estos ejecutores de secuencias de comandos protegida de cualquier acceso que no sea de la API. Proporcionamos una explicación detallada aquí. |
| Uso de API | ¿Hay un tiempo de espera para que el servidor de KV responda en un momento determinado? | Los vendedores pueden especificar el campo "perBuyerCumulativeTimeouts" en la configuración de la subasta. Este tiempo de espera incluye el tiempo necesario para recuperar indicadores de ofertas confiables. |
| Latencia | ¿Cómo trabaja el equipo de Privacy Sandbox para abordar la latencia? | Si quieres obtener información sobre las estrategias que estamos explorando para mantener la latencia dentro de los límites aceptables, consulta este artículo. |
Medición de anuncios digitales
Attribution Reporting (y otras APIs)
| Tema de los comentarios | Resumen | Respuesta de Chrome |
|---|---|---|
| Optimización manual de campañas | La ARA no admite la optimización manual de campañas. | Analizamos esta situación con la tecnología publicitaria y mostramos las formas en que se puede usar la ARA para respaldar la optimización manual de campañas. La ARA se creó de una manera que permite la personalización y la flexibilidad de la tecnología publicitaria para resolver una variedad de casos de uso de la tecnología publicitaria. Entre las sugerencias que se proporcionaron, se incluyen el uso de diferentes configuraciones flexibles a nivel del evento y el uso de informes a nivel del evento con informes de resumen para reducir el impacto del ruido y satisfacer sus necesidades de optimización manual y automática. Estamos abiertos a recibir más comentarios del ecosistema sobre la personalización y flexibilidad de las configuraciones de la ARA. |
| Tipo de conversión | Google solo permite ocho tipos de conversiones, lo que es limitante. | Implementamos la mayoría de los informes flexibles a nivel del evento, lo que les brinda a las tecnologías publicitarias flexibilidad adicional en términos de la cantidad de períodos de informes, la cantidad de informes de atribución y los bits de datos de activador que pueden usar. Las tecnologías publicitarias pueden elegir una configuración que permita medir hasta 32 tipos de conversión diferentes. |
| Límite de eventos de informes agregables | El mínimo numérico de 20 eventos de conversión por informe agregable no es viable para los anunciantes más pequeños con un presupuesto limitado. | No hay una cantidad mínima de eventos de conversión necesaria por informe agregable. Además, existen varias decisiones de diseño que se pueden tomar para optimizar los informes agregables para anunciantes más pequeños, como cambiar la estructura clave o las dimensiones de seguimiento, probar diferentes niveles de epsilon, probar frecuencias de lotes más largas y probar diferentes asignaciones de presupuesto de contribución entre los objetivos de medición. Las tecnologías publicitarias más pequeñas también pueden experimentar con la combinación de informes a nivel del evento y de informes de resumen como una forma de reducir el impacto del ruido. |
| Datos en tiempo real | Privar a las DSP de los datos en tiempo real (p.ej., sobre los clics, las sesiones y las conversiones) que utilizan para adaptar su estrategia de ofertas y lograr una mayor eficacia de las campañas va en contra del compromiso de mantener las funcionalidades existentes. | Incluso con la ARA, los clics y las sesiones siguen siendo en tiempo real, y las conversiones siempre se registran después del hecho, incluso con 3PC. |
| Campos incompletos | Faltan requisitos en el lanzamiento de eventos flexibles completos: i) campo de moneda y ii) campo orderID o TransactionID. | Actualmente, no planeamos admitir un campo de moneda ni un campo de ID de pedido o ID de transacción como parte de la flexibilidad total a nivel del evento, ya que ya existen formas de hacerlo con los informes actuales a nivel del evento. Estamos abiertos a recibir comentarios adicionales sobre estos campos y reconsideraremos si hay casos de uso adicionales que los requieran. Las formas de usar el diseño actual de ARA para medir la información del tipo de ID de moneda y pedido: 1. Según los comentarios, la moneda se determina según la ubicación geográfica del usuario, que se puede agregar como parte del source_event_id para determinar qué moneda se usó. 2. Según los comentarios, el campo del ID de pedido es necesario para garantizar que las conversiones y los valores no se dupliquen por error, lo que se puede hacer con claves de anulación de duplicación. |
| Privacy Budget | El presupuesto de privacidad de ARA limita la capacidad de realizar mediciones en varias dimensiones. | La ARA se diseñó de manera tal que las tecnologías publicitarias puedan personalizar sus propias configuraciones de ARA para abarcar una variedad de situaciones de atribución. Con el diseño actual de la ARA, las tecnologías publicitarias deberán pensar en la compensación entre las dimensiones más importantes que deben medir y el impacto del ruido en sus datos. Agregar ruido a los datos según el nivel de detalle de las dimensiones que se miden es esencial para la privacidad. Estamos abiertos a recibir más comentarios del ecosistema sobre la capacidad de realizar mediciones en diferentes dimensiones, pero debemos comprender los casos de uso específicos que lo requieren. |
| Actualización de la especificación | Aunque Google afirmó que pasó de ventanas de informes de eventos fijos a flexibles, esto no se reflejó en las especificaciones técnicas de Google, que actualmente tienen un período mínimo de una hora. | Actualmente, los informes flexibles a nivel del evento permiten que las tecnologías publicitarias cambien la cantidad de informes de atribución por evento de origen, los bits de datos del activador y la cantidad o la duración de las ventanas de informes. La ARA aún tiene una ventana mínima de informes de 1 hora para los informes a nivel del evento, lo que es esencial para mantener la privacidad y mitigar ciertos tipos de ataques de reconstrucción de historial. Dado que los informes de resumen proporcionan información agregada, las tecnologías publicitarias pueden habilitar la recepción de informes agregables de inmediato y sin demoras, si es necesario para sus casos de uso. |
| Diseño de API | Preocupación por el hecho de que reducir la información en los informes de conversiones y agregar ruido podría afectar al ecosistema más que a Google. | Google se comprometió con la CMA a diseñar e implementar las propuestas de Privacy Sandbox de una manera que no distorsione la competencia dando preferencia a su propio negocio, y a tener en cuenta el impacto en la competencia en la publicidad digital y en los publicadores y anunciantes de todos los tamaños. |
| Corrección de atribución | La ARA no permite que el proveedor de tecnología controle ni verifique la atribución correcta. | Existen muchas soluciones disponibles en la ARA que proporcionan capacidades de verificación: 1. Las tecnologías publicitarias pueden verificar que el comportamiento de ARA coincida con sus expectativas: – El código del cliente de ARA es de código abierto. – El código del servidor de ARA también es de código abierto, y los coordinadores se aseguran de que solo las versiones permitidas del servicio de agregación puedan desencriptar y procesar informes agregables. 2. Chrome proporcionó a las tecnologías publicitarias una biblioteca de simulación para verificar el comportamiento de la atribución, en la que la tecnología publicitaria puede probar cómo la ARA realiza la atribución en un entorno simulado. 3. ARA admite una serie de indicadores de depuración que ayudan a verificar si se produjo o no el procesamiento esperado y por qué. |
| (También se informa en trimestres anteriores) Ruido |
Comentarios sobre el nivel de ruido demasiado alto que afecta la utilidad de los informes. | Hablamos con las tecnologías publicitarias sobre estos mismos comentarios y pudimos identificar formas en las que se puede personalizar la ARA para que se adapte mejor a sus casos de uso, incluso con ruido. Tenemos documentación para desarrolladores que contiene la mayoría de las decisiones de diseño y las personalizaciones que analizamos con las tecnologías publicitarias. La ARA se diseñó de manera tal que las tecnologías publicitarias puedan personalizar sus propias configuraciones de la ARA para abarcar una variedad de situaciones de atribución. Sin embargo, las tecnologías publicitarias deberán pensar en la compensación entre las dimensiones que son más cruciales para medir y el impacto del ruido en sus datos. Estamos abiertos a recibir más comentarios del ecosistema sobre el impacto del ruido y podemos brindar orientación adicional sobre los impulsores de la ARA que se pueden usar para cambiar el impacto del ruido. |
| Atribución multidominio | ¿Cómo hacer un seguimiento de las atribuciones que son multidominio? | Las tecnologías publicitarias pueden redireccionar a diferentes URLs de informes para resolver este caso de uso. Estamos abiertos a recibir más comentarios del ecosistema sobre este aspecto del diseño de ARA. |
| Mejora de la API | Cambia periódicamente el factor de escalamiento que se usa cuando se registra la atribución para los informes de resumen de la ARA. | Según el debate en GitHub, parece que controlar varios factores de escalamiento en el servicio de agregación probablemente generará una mayor cantidad de ruido en los informes de resumen en comparación con la funcionalidad actual. Estamos abiertos a comentarios adicionales sobre la necesidad de factores de escalamiento como parte de los informes agregables, pero queremos señalar la posible compensación con un mayor ruido. También estamos evaluando si otras funciones futuras de ARA también pueden ayudar a resolver este caso de uso. |
| Uso de API | Oportunidad de unificar la forma en que se comparten los eventos de atribución con todos los participantes, lo que es beneficioso para la SSP, la DSP, etcétera. | Planeamos sincronizarnos con la tecnología publicitaria para comprender mejor sus comentarios y las limitaciones que encuentran. |
| Volumen de tráfico de prueba | ¿El tráfico de prueba del modo B para todos los Chrome es estable? | La inclusión en un grupo experimental no se ve afectada por la configuración de Chrome (es independiente de ella). |
| Documentación | Compatibilidad con ARA para píxeles | Publicamos información sobre cómo admitir este caso de uso y recibimos con gusto los comentarios adicionales del ecosistema. |
| Uso de API | Es posible que la ARA no se atribuya a la fuente correcta para los vendedores externos en las plataformas de comercio electrónico si la conversión no se realiza con el último contacto. | Las empresas pueden usar filtros para evitar que se produzca una atribución incorrecta (ya que no se generará ningún informe de conversiones). También estamos trabajando en una propuesta de filtrado previo a la atribución para ayudar con este caso de uso. |
| Navegadores compatibles | ¿La ARA será compatible con diferentes navegadores? | Invitamos a otros navegadores a adoptar las APIs de Privacy Sandbox y a seguir dedicando tiempo a analizar nuestro enfoque de forma abierta en el W3C. Declaramos explícitamente que la interoperabilidad es un objetivo para enviar ARA, y el diseño de ARA está diseñado para ser independiente del navegador, con valores flexibles especificados por los proveedores para proveedores con diferentes posturas de privacidad. Otros navegadores toman sus propias decisiones sobre si proporcionar alternativas viables a los identificadores entre sitios que puedan admitir el ecosistema digital de contenido y servicios. Nos complace que Microsoft Edge haya indicado que admitirá la AR. |
| Uso de API | ¿Cuál es el tipo de fuente esperado para los registros de fuentes de ARA para registerAdBeacon/reportEvent (y los píxeles contadores automáticos de navigation_start/commit)? | Depende de si estos píxeles contadores son automáticos o manuales:
: Reservado.* (es decir, automáticos) deben ser del tipo de fuente de navegación. : Los eventos activados de forma manual deben ser del tipo fuente de eventos. |
| Uso de API | ¿El límite máximo de 20 informes agregables por fuente se refiere a cada evento de fuente? ¿El límite es global o diario? ¿Hay un plan para aumentar el límite? | El límite de 20 informes agregables por fuente es un límite global en el que se pueden crear 20 informes agregables para cada fuente. El navegador establece el límite y no se puede configurar. El objetivo de este límite es evitar el abuso de la protección de los informes de atribución reales con informes nulos. Aquí, analizamos este tema en más detalle. |
| Uso de API | Compatibilidad con el marketing por correo electrónico mediante ARA | En este momento, no hay asistencia directa para este caso de uso en ARA (si no controlas el sitio de hosting de correo electrónico). Estamos analizando este tema aquí y agradecemos los comentarios adicionales. |
| Epsilon | ¿Cuándo se determinará el valor de epsilon para la API de Aggregate? | Las tecnologías publicitarias pueden configurar el valor de epsilon actual hasta un umbral predeterminado definido por Privacy Sandbox (que actualmente es 64). Te recomendamos que pruebes diferentes valores de epsilon, que identifiques los puntos de inflexión para tus propios casos de uso y que proporciones comentarios. Nos aseguraremos de comunicarnos con las tecnologías publicitarias con anticipación antes de realizar cualquier cambio en el rango de valores de epsilon. |
| Mejoras en la API | Se admite un caso de uso en el que el anunciante puede insertar un identificador en el campo trigger_data para que coincida con los datos externos del CRM y permitir que los anunciantes verifiquen la calidad de las conversiones. | Estamos analizando la solicitud y aceptamos comentarios adicionales aquí. |
| Uso de API | Cómo controlar las URLs de redireccionamiento como URLs de destino | Las tecnologías publicitarias pueden hacer lo siguiente: 1. Coloca la URL de destino final en el campo de destino; 2. El campo de destino permite hasta 3 URLs, lo que te permite ingresar varias URLs en el campo. Para ambas opciones, deberás conocer la URL de destino final. Aquí , analizamos este tema en más detalle. |
Servicio de agregación
| Tema de los comentarios | Resumen | Respuesta de Chrome |
|---|---|---|
| Mecanismo de descubrimiento de claves | Solicitud de un mecanismo de descubrimiento de claves | Tenemos una propuesta de descubrimiento de claves y recibimos con gusto los comentarios del ecosistema sobre ella. |
| Uso de API | Hoja de ruta de la observabilidad en el servicio de agregación | Estamos revisando las opciones para admitir más visibilidad y recibimos con gusto los comentarios del ecosistema aquí. |
| Mejora de la API | Solicitar permiso para volver a consultar informes | El servicio de agregación está trabajando en una propuesta de solicitud en la que las tecnologías publicitarias pueden dividir su epsilon para cada informe. Esto puede generar más ruido por búsqueda, pero permitirá que las tecnologías publicitarias vuelvan a realizar la búsqueda y mantengan la privacidad. |
| Mejora de la API | Me gustaría poder asociar varios orígenes al mismo ID de AWS. | El servicio de agregación ahora permitirá incorporar varios sitios en la misma cuenta de nube (Google Cloud o AWS). Esto permitirá que las tecnologías publicitarias usen el mismo enclave de servicio de agregación para procesar informes de varios sitios y varios orígenes de los mismos sitios. |
| Uso de API | Cuando fallan los lotes agregables, no se sabe si se consume el presupuesto o no, y si se puede volver a procesar el lote. Cuando un servicio de agregación encuentra un error de presupuesto para los informes duplicados, se pierden el resto de los informes. ¿Cómo minimizar esta pérdida? | En una situación típica, si falla toda la tarea, no se consumirá el presupuesto. En casos de fallas poco frecuentes en las que se consume el presupuesto, las tecnologías publicitarias pueden solicitar la recuperación del presupuesto. Si la tecnología publicitaria encuentra fallas frecuentes en las tareas con el error de presupuesto agotado, debe confirmar su estrategia de lotes. Aquí encontrarás instrucciones para realizar correctamente el procesamiento por lotes y evitar informes y errores duplicados. Envíanos tus comentarios sobre la recuperación del presupuesto aquí. |
| Uso de API | Si usas la API de agregación privada con el activador que se describe aquí, se generará un informe agregable para cada subasta. ¿Cuáles son las capacidades de escalamiento del servicio de agregación? | El servicio de agregación no establece un límite superior para la cantidad de claves o informes en un lote, pero actualmente no se admite una escala de 10^14 informes y 10^12 claves debido a la memoria que se requeriría. En nuestra guía de tamaño, se indican los rangos que probamos y recomendamos para obtener un rendimiento óptimo según la carga esperada y los tipos de instancias de VM de Cloud compatibles. |
| Procesamiento de datos | Si los datos encriptados contienen información personal, ¿cuál es el acuerdo legal para proporcionar datos encriptados al servicio de agregación? ¿Puedes indicarme si se garantiza que el coordinador no accederá a los datos encriptados? |
El servicio de agregación no comparte datos encriptados ni del usuario con el coordinador. El servicio de agregación usa el coordinador para la administración y contabilización de claves. Puedes encontrar algunos detalles sobre el coordinador aquí. En el caso de la contabilización, el servicio de agregación solo comparte el ID compartido y el origen de los informes con el PBS para el consumo del presupuesto. Una vez que lancemos un multisitio, reemplazaremos el origen por el sitio. Ten en cuenta que el servicio de agregación se ejecuta en un TEE, que es el único lugar donde se pueden desencriptar los informes de los clientes. El código que se ejecuta en el TEE es de código abierto y es auditado por terceros, como se describe aquí. |
API de Private Aggregation
| Tema de los comentarios | Resumen | Respuesta de Chrome |
|---|---|---|
| Uso de API | Posibilidad de que los vendedores de componentes envíen informes a varios servidores de agregación dentro de un TEE | El estado actual de la API de Private Aggregation no admite esta función. Aquí, analizamos este problema en más detalle. |
| Documentación | ¿Cuál es el valor de epsilon que se usa en las pruebas de Google? | En el caso de la API de Private Aggregation, el valor de ε especificado en una consulta del servicio de agregación corresponde al presupuesto de contribución de L1 de 2^16 que se aplica de forma continua cada 10 minutos. También hay un presupuesto de contribución de L1 de 2^20 como "garantía" que se aplica de forma continua durante 24 horas. En esencia, el parámetro de privacidad es ε en un período continuo de 10 minutos y es de 16ε en un período continuo de 24 horas (en lugar de 144ε). Actualmente, el servicio de agregación admite un rango de ε para pruebas (hasta 64) para permitir la experimentación con diferentes estrategias de agregación y proporcionar comentarios sobre la utilidad del sistema con diferentes parámetros de privacidad para la agregación privada y otras APIs. Planeamos revisar el valor máximo de epsilon permitido con el tiempo a medida que recibamos comentarios de los verificadores y agreguemos funciones que permitan un uso más eficiente del presupuesto de privacidad. |
Limita el seguimiento encubierto
Reducción del usuario-agente o sugerencias de cliente de usuario-agente
No se recibieron comentarios este trimestre.
IP Protection (antes Gnatcatcher)
| Tema de los comentarios | Resumen | Respuesta de Chrome |
|---|---|---|
| ID de resolución | Privacy Sandbox debe ser más vocal para presionar que los IDs de resolución que a menudo se compilan en IP no son sostenibles para los anunciantes. | Privacy Sandbox dejó en claro que nuestro objetivo es reducir el seguimiento entre sitios. Nuestras iniciativas públicas, que van más allá de las cookies, se publican en privacysandbox.com y GitHub. Nos esforzamos por reducir el seguimiento entre sitios, incluido el que se basa en direcciones IP. Sin embargo, en última instancia, depende de los sitios web individuales decidir si habilitar de forma proactiva el seguimiento entre sitios. En una era de mayor escrutinio sobre el cumplimiento normativo, es prudente que las empresas individuales comprendan las prácticas que emplean sus proveedores de servicios. |
| Chromecast | ¿La Protección de IP afectará a Chromecast o a otros dispositivos Chrome? | Actualmente, no hay planes para que la Protección de IP se aplique a los dispositivos Chromecast. |
| Lista de protección de IP | ¿Se publicará la lista de terceros identificados como potencialmente usuarios de direcciones IP para el seguimiento entre sitios en toda la Web? | La lista se publicará una vez que esté finalizada, como se explica aquí. |
Mitigación del seguimiento por rebote
| Tema de los comentarios | Resumen | Respuesta de Chrome |
|---|---|---|
| Exención de inicio de sesión único (SSO) | ¿Cómo verificará la mitigación de seguimiento de rebotes (BTM) los casos de uso de SSO para la exención? | Las heurísticas de Chrome inhabilitarán la BTM. Consulta la explicación para obtener más información. |
| Prueba de baja | ¿La BTM está habilitada para los sitios en la prueba de baja de los 3PC? | No, la BTM respeta las excepciones de cookies creadas por la prueba de baja, como se explica aquí. |
Privacy Budget
Como se indica en la explicación de GitHub y en el sitio para desarrolladores, Privacy Budget ya no se considera de forma activa como parte de las propuestas de Privacy Sandbox.
Fortalecimiento de los límites de la privacidad entre sitios
Conjuntos de sitios web relacionados (anteriormente, Conjuntos propios)
| Tema de los comentarios | Resumen | Respuesta de Chrome |
|---|---|---|
| Solicitud de función | Se permite el acceso automático a los CHIP o al particionamiento de almacenamiento en RWS, sin necesidad de la API de Storage Access ni de la interacción del usuario. | Estamos considerando los beneficios y la viabilidad de una función que pueda realizar esta tarea. Una consideración es una posible brecha en la interoperabilidad entre navegadores, que RWS aborda aprovechando la API de Storage Access. Actualmente, no hay un equivalente a esta funcionalidad solicitada que sea compatible con otros navegadores. Recomendamos a los desarrolladores que envíen sus casos de uso sobre este problema para facilitar el debate aquí. |
| Eliminación de conjuntos que no cumplen con los requisitos | ¿Cuál es el proceso para quitar del repositorio los conjuntos que dejan de cumplir con los requisitos? | Estamos trabajando para definir un proceso para esto y compartiremos actualizaciones en cuanto estén disponibles. |
| Proceso de Aplicación de las Políticas | No hay claridad sobre el rol subjetivo de Google en el proceso de aplicación de las RWS. | Como RWS es un proyecto en curso y seguimos recibiendo envíos nuevos, aún se están consolidando algunos aspectos del proceso y nuestros criterios. Creemos que es importante que nuestros lineamientos de envío describan en detalle todos los requisitos para el envío. En el futuro, agregaremos más detalles a nuestros lineamientos de envío para evitar más ambigüedades y confusiones. Nuestro objetivo es que el proceso de envío sea lo más técnico posible para que podamos eliminar gradualmente la participación humana y depender por completo de las verificaciones automatizadas. Las PR como esta requieren más interacción humana porque incluyen comportamientos que no anticipamos, pero nos permiten identificar más áreas para la automatización y formas en las que podemos corregir nuestros lineamientos para evitar estos problemas en el futuro. |
| Uso compartido de datos | Solicita una función que permita a los propietarios de dominios indicar que desean que un tercero también comparta datos de RWS, con el consentimiento del usuario. | La funcionalidad solicitada ya está disponible a través de APIs como FedCM y las APIs de acceso al almacenamiento que permiten el acceso a la identidad autenticada después de que el usuario acepta un mensaje de permiso. Agradecemos los comentarios del ecosistema sobre cualquier caso de uso específico que consideren imposible. |
| Otros métodos de almacenamiento | ¿La información guardada en el almacenamiento local o de sesión también se interpretará como 3PC? | El almacenamiento local, el almacenamiento de sesión y otras formas de almacenamiento que no son de cookies cuando se usan en contextos de terceros se particionaron en Chrome desde la versión 115. Consulta esta entrada de blog para obtener más detalles. |
| Límite de conjuntos asociados | ¿Qué sucede con las organizaciones que envían más de 5 dominios, aunque el límite es de 5 sitios asociados? | Estos conjuntos se aceptarán a través del proceso de GitHub, pero el navegador (Chrome) solo aplicará nuestras reglas de otorgamiento automático de la API de Storage Access a los primeros 5 dominios y, además, ignorará los dominios restantes, como se explica aquí. |
| find_robots_txt | La verificación de find_robots_txt no funciona con redireccionamientos. | Se envió una solución para resolver este problema aquí. |
| Gesto del usuario | Se quitó el requisito de gesto del usuario para accessStorage(). | Este requisito se basó en un diseño similar que se implementa en todos los navegadores principales para la API de requestStorageAccess. Te invitamos a que envíes comentarios y casos de uso adicionales en este problema de GitHub para ayudarnos a priorizar esta solicitud y habilitar debates entre navegadores. |
| Gesto del usuario | ¿Se requiere un gesto del usuario para otorgar permiso de acceso al almacenamiento de terceros después de reiniciar Chrome o el SO? | Sí, pero recibimos con gusto comentarios adicionales del ecosistema sobre si se debe cambiar este comportamiento aquí. |
API de Fenced Frames
| Tema de los comentarios | Resumen | Respuesta de Chrome |
|---|---|---|
| adComponent | Falta de documentación y flexibilidad cuando se usan AdComponents con marcos delimitados. | Queremos compartir más documentación sobre este caso de uso. Además, los componentes de anuncios son compatibles con los marcos delimitados mediante getNestedConfigs(), que se documenta en la especificación aquí. |
| (También se informa en trimestres anteriores) Renderiza adComponent |
Solicitud de códigos de muestra para renderizar adComponents en el marco de límite | Estamos trabajando para compartir algunos códigos de muestra aquí. |
| Verificación de anuncios de terceros | El rol de la verificación de anuncios de terceros en el contexto de los marcos delimitados necesita más detalles, en especial en lo que respecta a la seguridad contextual o de la marca. | Actualmente, los informes de anuncios de marcos delimitados permiten que las DSP envíen datos a nivel del evento de impresión y subasta a verificadores de anuncios externos para la facturación y las verificaciones de seguridad de la marca posteriores a la renderización. |
| Anuncios Expandibles | Solicita la compatibilidad con anuncios expandibles. | Si el anuncio debe cambiar entre dos tamaños con la misma relación de aspecto y no hay diferencias funcionales entre los dos (solo el tamaño), el incorporador podría cambiar el tamaño del marco con el segundo tamaño del anuncio y el navegador escalaría el elemento del marco según corresponda. |
| (También se informó en trimestres anteriores) Compatibilidad con el inventario nativo y de video |
¿Los marcos delimitados admiten inventario nativo y de video? | Nuestra respuesta es similar a la de trimestres anteriores: La API de PA admite la renderización de videos con un mecanismo que se basa en iframes. Sin embargo, aún no diseñamos una solución para la renderización de anuncios nativos y de video que sea compatible con los marcos delimitados, y este es uno de los motivos por los que decidimos retrasar la aplicación de esta medida hasta 2026. Esto significa que, si un socio decide aplicar los marcos delimitados ahora, no podrá publicar anuncios nativos ni de video. |
| Junta Asesora | Solicita la creación de un consejo asesor de proveedores de anuncios nativos para garantizar que las implementaciones de marcos delimitados cumplan con los estándares de la industria. | Los marcos delimitados no son obligatorios para usar en la API de PA antes de 2026. El tiempo adicional nos permite seguir trabajando con la industria para diseñar e implementar la compatibilidad con una gama más amplia de casos de uso críticos. Anteriormente, informamos que evolucionaremos los marcos delimitados antes de que sea necesario para mantener la compatibilidad con los anuncios nativos y de video con la API de PA. Según nuestros compromisos, nos comunicaremos con la CMA y le informaremos sobre cualquier cambio de este tipo, y seguiremos recibiendo comentarios del ecosistema antes de exigir marcos delimitados. Nuestro modelo de participación en el ecosistema del W3C y las organizaciones de estándares de anuncios como IAB Tech Lab permite que expertos de la industria de todo tipo guíen los diseños antes de que sean necesarios. |
| (También se informa en trimestres anteriores) Diferencia de tamaño entre plataformas |
Se informa que el tamaño del contenido que se muestra en el marco con límite se ve diferente en computadoras de escritorio y smartphones. | Este es un problema conocido de Chromium que estamos investigando. Aquí puedes enviarnos tus comentarios adicionales. |
| Mejora de la API | ¿Se retrasó el requisito de marcos delimitados hasta 2025 para que los anuncios nativos ahora sean compatibles con Privacy Sandbox? | Como indicamos en nuestro anuncio público sobre la aplicación de los marcos delimitados a partir de 2026, detectamos un "esfuerzo significativo para adaptarse" a los marcos delimitados. Por supuesto, uno de ellos fue el nativo, pero no fue el único factor. El objetivo era brindar más tiempo para garantizar que el ecosistema esté listo para admitir casos de uso clave, incluidos, sin limitaciones, los nativos. |
API de Shared Storage
| Tema de los comentarios | Resumen | Respuesta de Chrome |
|---|---|---|
| Rendimiento | Los tiempos de devolución de Shared Storage fuera de la worklet parecen depender de la actividad en la worklet. | Hablamos sobre este resultado de la prueba aquí. |
| Adopción más amplia | El almacenamiento compartido debe ser un estándar de la industria disponible en todos los navegadores. | Agradecemos y tomamos nota de estos comentarios. Chrome continúa participando activamente en los foros del W3C, incluido el WICG, para promover la propuesta, solicitar comentarios y fomentar la adopción. |
| Worklets de ofertas | ¿Es posible leer desde el almacenamiento compartido dentro de generateBid (que ya se ejecuta en una worklet) para aplicar la lógica de decisión o empresarial del anuncio (como la limitación de frecuencia) en función de la información entre sitios y seleccionar un subconjunto de anuncios? | No, es imposible leer desde el almacenamiento compartido dentro de las worklets de ofertas. |
CHIPS
| Tema de los comentarios | Resumen | Respuesta de Chrome |
|---|---|---|
| Capacidad de la partición | Se aclaró el comportamiento cuando se supera la capacidad de la partición. | Cuando se alcanza la capacidad, las cookies más antiguas se expulsan de las cookies a las que se accedió menos recientemente para liberar memoria hasta que se deje de superar el límite. Los desarrolladores ven el encabezado de cookie actualizado en las solicitudes posteriores. |
| Acceso de iframe de terceros | El contenido de iframe de terceros incorporado que abre una pestaña o ventana nueva en el mismo sitio de terceros debe tener acceso a las mismas cookies particionadas que el abridor. | Estamos analizando este caso de uso y recibimos con gusto los comentarios adicionales del ecosistema aquí. |
| Cookies duplicadas | Si hay una cookie particionada y una no particionada con el mismo nombre, ¿qué valor de clave decide enviar el navegador? | Cuando tienes dos cookies con el mismo nombre (una particionada y otra no), obtendrás ambas. Lamentablemente, no hay forma de diferenciarlas. La especificación de RFC sobre este tema está disponible aquí, donde se explica que no se debe confiar en el orden en que se envían las cookies. |
| Solicitud de función | Aceptar las cookies particionadas por origen | Estamos considerando esta solicitud y recibimos con gusto los comentarios adicionales del ecosistema aquí. |
FedCM
No se recibieron comentarios este trimestre.
Cómo combatir el spam y el fraude
API de Private State Tokens (y otras APIs)
| Tema de los comentarios | Resumen | Respuesta de Chrome |
|---|---|---|
| Vista web | ¿Los tokens de estado privado (PST) persisten en varias vistas web en el mismo dispositivo móvil (perfil)? | Cada app que use WebView tendrá un almacenamiento local diferente, lo que significa que los emisores de PST no pueden emitir tokens en el WebView de una app y, luego, permitir canjes de tokens en una app diferente. Esto también es cierto para otras formas de datos almacenados de forma local en vistas web, como las cookies. Los PST aún no están disponibles por completo en WebView. Esperamos poder brindarte una actualización sobre este tema a fines del 2ᵉʳ trimestre. |
| Nuevo tipo de token | Propuesta de un nuevo tipo de token. | Agradecemos esta propuesta y la exploración continua de las aplicaciones y adaptaciones de los PST. Esperamos obtener más información sobre esta propuesta en las próximas reuniones del grupo comunitario de lucha contra el fraude en el segundo trimestre de 2024. |
| Identificación del usuario | ¿Cómo evitar que se identifiquen los usuarios en función de los PST específicos que tienen? | Actualmente, se mitiga limitando los intentos de canje en un sitio a dos emisores, independientemente de si hay tokens disponibles de ese emisor. Debes contar un emisor en función del límite, incluso si no hay tokens disponibles, ya que, de lo contrario, el sitio podría iterar por todos los emisores hasta encontrar una coincidencia positiva. |
| Registro | ¿Cuánto tiempo será obligatorio el registro para los PST? | El registro seguirá siendo obligatorio en el futuro previsible, como se explica con más detalle aquí. |
| Compatibilidad con otros navegadores de Chromium | ¿El registro de emisores de PST para otros navegadores basados en Chromium será compatible con el repositorio de registro de emisores de Chrome? | Chrome recupera los compromisos clave y los distribuye a los clientes de Chrome a través de un mecanismo llamado Actualizador de componentes. A medida que otros navegadores agreguen una compatibilidad más completa con la API, deberán establecer un proceso para obtener los compromisos clave para el cliente, ya sea a través de un método de actualización de componentes o algún otro método. Esto se aborda con más detalle aquí. |