Informe de comentarios (1er trim. de 2024)

Informe trimestral del primer trimestre de 2024 en el que se resumen 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 comentarios que recibe Chrome de diversas fuentes, como se detalla en la descripción general de 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 agradece los comentarios recibidos del ecosistema y explora activamente formas de integrar el aprendizaje en las decisiones de diseño.

Los temas de comentarios se clasifican por prevalencia en función de la API. Para ello, se agrega la cantidad de comentarios que el equipo de Chrome recibió sobre un tema determinado y se organiza en orden descendente de cantidad. Los temas de comentarios comunes se identificaron a partir de la revisión de 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 y los formularios públicos de Google.

Más concretamente, se revisaron las actas de las reuniones de los organismos web estándar y, para obtener comentarios directos, se consideraron los registros de Google de las reuniones 1:1 con las partes interesadas, los correos electrónicos recibidos por los ingenieros individuales, la lista de distribución de la API y el formulario público de comentarios. Luego, Google coordinó entre los equipos involucrados en estas diversas actividades de comunicación para determinar la prevalencia relativa de los temas emergentes en relación con cada API.

Las explicaciones de las respuestas de Chrome a los comentarios se desarrollaron a partir de preguntas frecuentes publicadas, respuestas reales a los problemas planteados por las partes interesadas y la determinación de una posición específicamente a 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 del informe actual aún no tengan una respuesta de Chrome considerada.

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

MPS

Conjuntos propios

IAB

Oficina de Publicidad Interactiva

IdP

Proveedor de identidad

IETF

Grupo de Trabajo de Ingeniería de Internet

interna

Dirección de Protocolo de Internet

openRTB

Ofertas en tiempo real

TE

Prueba de origen

API de PAT

API de Protected Audience (anteriormente FLEDGE)

PatCG

Grupo comunitario de tecnología publicitaria privada

RP

Persona 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

User-Agent Client Hints

W3C

Consorcio World Wide Web

WIPB

ceguera de IP voluntaria

Comentarios generales, sin API o 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 dispuestos a recibir comentarios razonables de las partes interesadas sobre cualquier desarrollo significativo relacionado con Privacy Sandbox, incluida la administración futura de Privacy Sandbox.
Prueba	Fases de prueba adicionales para 3PCD, además del 1% actual de las pruebas facilitadas por Chrome.	No tenemos previsto ofrecer pruebas facilitadas por Chrome más allá del 1% actual de tráfico de Chrome habilitado desde principios de enero.
Redireccionamiento de la Web a la app	La 3PCD en dispositivos móviles no debería ocurrir antes de que se logre la interoperabilidad completa entre la Web y las aplicaciones.	Estamos de acuerdo en que es conveniente admitir la interoperabilidad web y de apps, y lanzamos la medición de atribución web y entre apps. Además, estamos explorando soluciones de segmentación de Web a app. Sin embargo, no planeamos retrasar a 3PCD en la Web móvil. No tenemos un objetivo de cobertura del 100% al final de las 3PCD. En su lugar, esperamos que la compatibilidad en Android para la medición web y entre apps sea razonablemente alta con 3PCD y que aumente con el tiempo a medida que los usuarios actualicen sus teléfonos.
Rol del navegador	Chrome parece estar asumiendo el rol de servidor de anuncios o SSP.	Chrome no asume el rol de un servidor de anuncios o SSP. Con la API de PA, Chrome proporciona un contenedor para los servidores de anuncios, las SSP, las DSP y otras tecnologías publicitarias para que incorporen su propia lógica de ofertas y puntuación.
Orientación para 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 incluir a los desarrolladores en los procesos de debate y comentarios de todas las propuestas. Esto significaba que el contenido se estructuró generalmente en torno a la comprensión de la motivación y los conceptos detrás del proyecto, seguido de detalles de los primeros desarrollos y pruebas de cada propuesta. Esto fue eficaz a la hora de crear una colaboración real en el ecosistema para desarrollar las propuestas, pero a medida que las APIs avanzaron hacia la disponibilidad general, hay un nuevo público de desarrolladores que están aquí principalmente para compilar en las APIs en lugar de contribuir a su desarrollo subyacente. Recientemente actualizamos la navegación de developer.google.com/privacy-sandbox de I Seguiremos en el futuro con este enfoque de documentación basado en casos de uso.
Entorno de desarrollo local	¿Cómo continuamos desarrollando y probando nuestro frontend de manera local en http://localhost cuando la cookie es SameSite=Secure y cuando el backend está dirigido por una CDN?	Estamos analizando este problema aquí y recibimos con gusto comentarios adicionales del ecosistema.
Mitigación de 3PCD	¿Existe una forma programática de saber si las 3PC están bloqueadas o cuándo la heurística está activa?	En Chrome, tanto la detección de funciones como la llamada a document.hasStorageAccess de un iframe permiten que el desarrollador sepa si el origen del iframe tiene acceso a 3PC.
Prueba de video	Actualmente, no se pueden probar los anuncios de video en Privacy Sandbox.	Chrome publicó un debate y una demostración de varias formas posibles de lograr un video con la API de PA hoy (consulta las secciones 242 y 254 en nuestro repositorio de demostraciones en GitHub). Ten en cuenta que estos no están pensados como código de muestra que las tecnologías publicitarias adoptarían por completo, sino como prueba de concepto y demostración de las técnicas que podrían admitir la renderización de videos de VAST con la API de PA. En este análisis, también quedó claro que, si bien la renderización de videos ya es posible actualmente, hay cambios que Chrome podría hacer que simplificarían la implementación con la API de PA. Por ejemplo, las actualizaciones de la sustitución de macros (que se analizan aquí) que ya planeamos abordar en función de los comentarios sobre casos de uso de seguridad de la marca de verificadores de anuncios externos 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. Hasta la fecha, la mayor parte del debate se centró en particular en la renderización de anuncios de video de VAST. La renderización de anuncios nativos podría utilizar los mismos enfoques y, en muchos sentidos, es más fácil. Los anuncios nativos parecen estar recibiendo menos atención que los videos en este momento, pero esto es solo una cuestión de priorización de la industria de tecnología publicitaria, no de ninguna barrera técnica para la implementación.
Medición que no son anuncios	Las 3PCD pueden afectar las soluciones de medición de público no relacionadas con los anuncios.	Las APIs de medición no requieren que el caso de uso esté relacionado con anuncios. Mientras que la ARA es más específica para un recorrido publicitario típico,la Agregación privada es de uso general. Estos dos componentes básicos pueden usarse para abordar una amplia gama 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 centra en mantener la privacidad de la actividad de las personas a través de una Internet abierta y libre. Sabemos que los publicadores dependen de los anuncios para producir contenido y hacer que esté disponible de la forma más amplia posible. Los anunciantes ayudan a las personas a descubrir ofertas o productos nuevos que tal vez deseen. Las funciones de Privacy Sandbox permiten que los sitios web de todo tipo, incluidos aquellos que trabajan con creadores de contenido, muestren anuncios útiles a las personas en función de su actividad con diferentes partes, sin revelar la identidad del usuario a esas partes.
Cronogramas más claros	Programaciones de lanzamientos más claros y detallados para las tecnologías de Privacy Sandbox	La documentación de la API de Privacy Sandbox incluye el estado de la API y las páginas de disponibilidad. En estas páginas, se enumeran las próximas funciones y sus cronogramas (p.ej., PA API, ARA). Aquí encontrarás una vista central de estos estados.
Aprendizaje automático	Las tecnologías publicitarias no pueden entrenar correctamente los modelos de aprendizaje automático hasta que 3PCD se extienda más del 1%.	Expandir 3PCD a más navegadores para realizar pruebas no garantiza que las APIs tengan más uso, que es probablemente lo que buscan las tecnologías publicitarias para seguir entrenando los modelos de aprendizaje automático. Si las tecnologías publicitarias no buscan un uso más amplio del ecosistema para seguir entrenando modelos de aprendizaje automático, no hay motivo para expandir la 3PCD, ya que las tecnologías publicitarias que desean entrenar modelos con más tráfico pueden hacerlo hoy sin aumentar las 3PCD. Esto puede hacerse sin que Chrome parezca avanzar con 3PCD antes de que finalice el período de inactividad.
Caso de uso no admitido	Actualmente, no se están considerando casos de uso de la DSP de autoservicio.	Existen varias DSP de autoservicio que proporcionan comentarios públicos sobre las API con regularidad. Varias de las DSP que proporcionan comentarios públicos con regularidad también se registraron como verificadores. Además, Chrome participa activamente en temas típicos de DSP de autoservicio, como los servidores de anuncios de terceros y los videos. Las llamadas semanales recientes a la API de PA abordaron estos temas.
Prueba de origen	Solicitud de OT para sitios que desean un aumento más agresivo y cobertura de prueba para 3PCD.	Actualmente, Chrome está desarrollando una OT de origen, que permitirá a los orígenes habilitar el comportamiento de la eliminación gradual de 3PC. Los orígenes de nivel superior que se registran para esta prueba y los tokens de implementación tendrán bloqueadas las 3PC como si el dispositivo del usuario tuviera habilitada la protección contra el seguimiento. Esta OT ofrecerá una valiosa oportunidad a los sitios para realizar pruebas más amplias de alternativas a largo plazo a las 3PC antes de la eventual eliminación gradual de las 3PC programada para realizarse después de la consulta con la CMA. Todavía estamos trabajando para finalizar el cronograma de lanzamiento de la OT.
Informe de IAB Tech Lab	Se recibieron comentarios sobre Privacy Sandbox del informe de IAB Tech Lab.	Respondimos en detalle el informe de IAB Tech Lab aquí. También reconocimos 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, y trabajaremos con el ecosistema y actualizaremos nuestras Preguntas frecuentes públicas según corresponda”. Ya tratamos la documentación fragmentada anteriormente. Abordamos los requisitos comerciales en la sección "Garantías de datos" aquí. Además, algunos productos publicitarios de Google compartieron sus enfoques. Abordamos las auditorías de terceros en la sección “Garantía de integridad del algoritmo” aquí. Con respecto a la acreditación, esperamos que esas entidades continúen acreditando los productos, incluido el uso que hacen de las tecnologías, en lugar de hacerlo por sí mismos. Con respecto a la escalabilidad, seguimos abiertos a los datos de desarrolladores que demuestren problemas. Con respecto a la transparencia y la administración, seguimos desarrollando de manera abierta en GitHub y en foros como W3C, al mismo tiempo que interactuamos con la CMA en virtud de los Compromisos.
Acceso con Google	El Acceso con Google daría la posibilidad a Google de usar datos de acceso de identificación cruzada, de forma contraria a los Compromisos.	El Acceso con Google no le permite a Google usar datos en contra de los Compromisos.
Compatibilidad	¿Cuáles son los planes para la compatibilidad de las APIs de Privacy Sandbox y la retrocompatibilidad?	Una vez que Chrome lanza una función para el público en general, nuestro objetivo es mantener su compatibilidad. Por supuesto, no siempre es posible mantener la retrocompatibilidad y, en esos casos, tenemos un proceso claro para dar de baja y quitar las funciones existentes, que se describe aquí. Esperamos seguir agregando más funciones a las APIs de Privacy Sandbox con el paso del tiempo, en respuesta a los comentarios del ecosistema sobre casos de uso en los que se beneficiarían de una mejor asistencia. 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 la función es compatible. Esto es mejor que pedirles a los desarrolladores que verifiquen un número de versión de Chrome determinado, 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 funciones para la API de PA se puede encontrar aquí.
Implementación del servidor	En lugar de vincularse con su propia implementación, Chrome debe especificar los comportamientos que debe cumplir una implementación satisfactoria de un servidor de indicadores confiables, un servidor de agregación y cualquier otro componente necesario que no sea del navegador. Esto permitiría la innovación dentro de límites de privacidad aceptables.	Apreciamos y agradecemos el deseo de innovación de las partes externas. Nuestro objetivo para todas las APIs y servicios es ofrecer flexibilidad de tecnología publicitaria a fin de implementar su funcionalidad. Por ejemplo, permitimos que las tecnologías publicitarias usen información confidencial de la empresa en el diseño de la lógica de ofertas para subastas. Además, interactuamos continuamente con los comentarios de las tecnologías publicitarias y, cuando se justifica, los incorporamos a nuestros diseños. Para permitir que otros 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 entender qué beneficios busca obtener el interesado y que no tenemos actualmente.
Heurística	¿Cuáles son los planes de heurística a largo plazo?	Alineados con lo que indicaron otros navegadores, con el tiempo pretendemos retirar estas heurísticas a medida que se utilicen muchas soluciones alternativas, sujetas a un análisis de viabilidad más exhaustivo. Compartimos esta información aquí.
Volumen de pruebas	Diferentes volúmenes de tráfico cuando se comparan distintas dimensiones.	El experimento del 1% tiene criterios de exclusión que generan diferencias en la elegibilidad para el experimento entre distintas poblaciones de clientes de Chrome. Por ejemplo, el experimento excluye a los usuarios de Chrome Enterprise, por lo que se espera que la fracción de tráfico con etiquetas del experimento sea más alta los fines de semana. Es normal observar diferentes porcentajes de tráfico en diferentes porciones de datos (como ubicación geográfica, fecha y plataforma), y esto se alinea con lo que vemos en los datos de Chrome.
Cómo volver a habilitar manualmente las cookies de terceros	¿Los sitios podrán saber cuántos usuarios (%) volvieron a habilitar manualmente las cookies después de la aplicación forzosa de 3PCD?	Los usuarios podrán volver a habilitar el acceso de terceros a nivel del sitio mediante la derivación del usuario si se encuentran con fallas. Las 3PC también pueden volver a habilitarse con otras medidas, como la API de Storage Access. Existen medidas técnicas, como hasStorageAccess(), que permiten que los sitios detecten si las 3PC están habilitadas o inhabilitadas. Sin embargo, Chrome no facilitará que los sitios web conozcan los motivos de la reactivación.
Protección contra seguimiento	¿Durante cuánto tiempo estará disponible la función de IU de Protección contra seguimiento de Chrome?	Se prevé que la IU de la Protección contra seguimiento en la barra de direcciones permanecerá más allá de cuando las 3PC dejen de estar disponibles.
(También se informó en trimestres anteriores) Asistencia en varios navegadores	Otros proveedores de navegadores que adoptarán las APIs de Privacy Sandbox.	Otros proveedores de navegadores, como Apple, Mozilla y Microsoft, participan de forma activa en foros públicos donde se discuten los principios de privacidad y los enfoques basados en el navegador. Nos animan los debates colaborativos en foros como la reciente reunión anual TPAC de la W3C y los foros en curso sobre PATCG de W3C 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 de 3PCD	Proporcionar hooks de API para detectar si un iframe o una incorporación de terceros cumplen con 3PCD o no.	Estamos analizando la solicitud aquí y agradecemos que nos envíes comentarios adicionales del ecosistema.
Prueba	Solicitud de marcas adicionales en instancias administradas de Chrome que desactiven temporalmente los comportamientos personalizados.	Estamos considerando esta solicitud para instancias administradas de Chrome y agradecemos las contribuciones adicionales del ecosistema si esa función experimental sería útil.

Inscripción y certificación

Tema de los comentarios	Resumen	Respuesta de Chrome
Verificación de la certificación	¿Cómo garantizará Google la autenticidad de las certificaciones?	Todos los registrantes deben mantener el archivo de certificación en su lugar mientras usan las APIs. Google valida que el archivo esté implementado y que la sintaxis sea correcta, pero no valida el comportamiento de la tecnología publicitaria con respecto al lenguaje de la certificación.
Proceso de inscripción a la API de Private Aggregation	¿Hay alguna manera de verificar el estado de la inscripción en la API de Private Aggregation?	El equipo de asistencia al cliente para inscripciones les enviará una notificación por correo electrónico a todos los usuarios inscritos aprobados una vez que se haya validado la inscripción. 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á y responderá preguntas, y proporcionará cualquier orientación adicional que sea necesaria.

Mostrar anuncios y contenido relevantes

Temas

Tema de los comentarios	Resumen	Respuesta de Chrome
(También se informa en trimestres anteriores) Cronograma y documentación del clasificador	Debe existir algún tipo de mecanismo para que se revise la clasificación o, al menos, transparencia adicional sobre cómo el modo de clasificación determina las categorías.	Nuestra respuesta no cambió en comparación con trimestres anteriores: "La clasificación incorrecta de sitios puede hacer que el indicador de Topics sea un poco menos útil como indicador en general, pero los sitios específicos que se clasificaron de forma incorrecta no resultarán más ni menos afectados por esto que cualquier otro sitio. Esto se debe a que la información contextual de un sitio siempre estará disponible para las subastas que se realicen en su sitio, lo que proporcionaría información comparable con el tema correcto, incluso en el caso de una clasificación errónea. Aquí nos encantaría recibir comentarios sobre este tema”.
Administrador de anuncios de Google	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 competencia que está presente en menos sitios.	El requisito de observación existe para garantizar que la API de Topics no permita 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 cientos de sitios y permiten a los participantes del mercado llamar a la API de Topics a través de su tecnología. Además, cabe mencionar que el límite de hasta 5 temas principales por semana puede tener un efecto igualador, ya que los participantes del mercado están presentes en muchos sitios que pueden aprender más de 5 temas equivalentes con 3PCs se limitará a 5.
(También se informó en trimestres anteriores) Utilidad para diferentes tipos de partes interesadas	Inquietud sobre el valor creado y la distribución de ese valor para los sitios según el nivel de tráfico o la especialización de su contenido	Sabemos que los sitios especializados tienen más probabilidades de contribuir con 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 de las terceros en Chrome. Además, en el entorno actual, algunos sitios proporcionan más valor que otros en los sistemas de relevancia del anuncio basados en las 3PC. Además, los temas presentes en sitios especializados pueden ser beneficiosos mutuamente, ya que diversos anunciantes pueden publicar campañas en varios conjuntos de temas, y la lógica de ofertas puede observar el valor que tiene en una amplia variedad de temas.
Nombres de host en comparación con URLs completas	¿La clasificación basada en nombres de host de sitios web es lo suficientemente eficaz? ¿Reduce el riesgo de privacidad en comparación con las URLs completas?	Consideramos utilizar las URLs o los títulos de páginas de la información, además de los nombres de host, y determinamos que los posibles beneficios se superarían con los riesgos para la privacidad y la seguridad de los usuarios. Un ejemplo de riesgos para la privacidad del usuario incluye la clasificación de información sensible incluida en la URL o el título de la página en los temas de un usuario.
Topics como indicador	Solicita orientación para combinar Topics con otros indicadores y qué otros indicadores podrían ser útiles.	Las soluciones de tecnología publicitaria pueden generar los mejores resultados combinando todas las herramientas disponibles, como el aprendizaje automático y los indicadores que resguardan la privacidad de las APIs que preservan la privacidad, junto con datos contextuales, datos de creatividades y datos de origen. Obtén más información sobre el tema aquí.

API de Protected Audience (anteriormente FLEDGE)

Tema de los comentarios	Resumen	Respuesta de Chrome
Probar el volumen del tráfico	Los verificadores informan un volumen bajo de respuestas a la oferta 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, la cual prevemos que seguirá aumentando durante 2024 y en adelante. En última instancia, los anunciantes, sus agencias y los proveedores de tecnología son los que determinan 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 de las 3PCD. En ese momento, prevemos que podrán aumentar 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) que los publicadores y sus proveedores de tecnología publicitaria pueden decidir no iniciar subastas de API de PA si consideran que la demanda es baja. Los publicadores son los que determinan la prioridad de actualizar sus páginas y de participar. Prevemos que los publicadores demorarán un tiempo en hacer pruebas y aumentar el tráfico de forma gradual por estos motivos. Este informe también incluye una respuesta de Google Ad Manager sobre sus controles de publicador para la participación de la API de PA.
(También se denunció en trimestres anteriores) Fraude / abuso	¿Cómo puede el ecosistema reducir los riesgos y evitar que personas o compradores que actúan de mala fe se posicionen como un público deseable?	Los mecanismos de denuncia de los anuncios de la API de PA conservan la información que se usa actualmente para distinguir el tráfico de personas del tráfico de bots. Además, en la API de PA se pueden usar técnicas actuales basadas en dominios para incluir o excluir dominios. Esto se describe con más detalle en nuestra respuesta al informe de IAB Tech Lab sobre Privacy Sandbox.
Misma restricción de origen para el propietario de IG y la URL de lógica de ofertas	Con el requisito del mismo 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 del mismo origen para la carga de secuencias de comandos es una protección de seguridad importante. Aquí encontrará algunos detalles sobre una solución propuesta que equilibra los comentarios sobre el ecosistema y otras consideraciones aquí.
Subasta privada de varias ranuras	Hay mucho espacio para permitir subastas privadas de múltiples ranuras dentro de los límites de privacidad a través del uso del ruido y una mayor integración con las prácticas actuales de los anuncios.	Estamos teniendo en cuenta estos comentarios y evaluando la solicitud de subastas de varias etiquetas con respecto al aumento de la complejidad y los riesgos de privacidad asociados con esta función. Analizamos este problema con más detalle durante una llamada del PA API Web Incubator Community Group (WICG) aquí.
Vendedores principales	La estructura actual de la API de PA proporciona a cualquier vendedor de nivel superior considerablemente más datos y comprensión del valor relativo de las impresiones que los publicadores o vendedores de componentes.	En una subasta de varios vendedores, cada vendedor tendrá la mejor oferta. Además, a partir del ecosistema, descubrimos que los publicadores podrían considerar la demanda de venta directa junto a las mejores ofertas de cada vendedor con el que trabajan. Es necesario analizar todas estas posibles oportunidades de monetización para determinar qué anuncio publicar. Esta situación, en la que es necesario que algún actor vea el conjunto completo de opciones para elegir un anuncio para 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 a las campañas publicitarias de venta directa, en las que esta última es aplicable. Esto significa que se debe tener un mecanismo para elegir entre esas oportunidades de monetización, como existe actualmente. No creemos que el navegador deba tener la función de seleccionar qué anuncio publicar. Por lo tanto, el concepto de vendedor de primer nivel 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 del vendedor puede optar por proporcionar información sobre las campañas de venta directa del publicador en los casos en que 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, las opciones de anuncios de venta directa del 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 bajo el tema “Acceso a la información”.
Separación de anuncios de la competencia	Solicitar la separación de anuncios de la competencia, por ejemplo, para evitar que los anuncios de marcas que compiten aparezcan uno al lado del otro	No sabemos cómo garantizar la separación competitiva en el ecosistema actual de publicidad digital programática, por oferta y de múltiples vendedores. Sin embargo, la API de PA permite a los vendedores recuperar indicadores en tiempo real adicionales en función de una combinación de renderURL y nombre de host (que representa el dominio del publicador) que se pueden usar durante scoreAd() cuando se califican las creatividades. Los vendedores pueden usarla para evitar que los anuncios de marcas que compiten aparezcan uno al lado del otro, siempre que el publicador quiera 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 del componente, el nombre del anunciante, la URL de página de destino, el tamaño de las creatividades, el tiempo de respuesta y la tasa de ofertas, así como las ofertas perdedoras.	Presentamos algunas soluciones posibles aquí y recibimos más comentarios del ecosistema.
Informes a nivel del evento	Los publicadores no pueden obtener suficiente información sobre el anuncio publicado después de que la API de PA de informes a nivel del evento deje de estar disponible.	Conocemos los diferentes casos de uso de informes que debemos seguir admitiendo cuando se retiren los informes a nivel del evento. Por eso, establecimos que la fecha de eliminación de los informes a nivel del evento no sea anterior a 2026. Durante ese período, invitamos a participar de forma activa mientras abordamos el ecosistema por rutas duraderas que podrían incluir nuevas ideas para obtener información de una manera que preserve la privacidad.
Varias SSP	El valor agregado obtenido de varias SSP será demasiado bajo para los publicadores.	Consideramos que esto no es correcto y recibiríamos comentarios adicionales del ecosistema para comprender los fundamentos de esta afirmación.
Actividades de selección	No se pueden realizar actividades de selección con la API de PA.	Recibimos comentarios sobre la posibilidad de que los vendedores usen la API de PA para compartir información sobre el público con compradores en toda la Web (también conocida como extensión de público). Creemos que hoy en día esto es posible gracias a la función de delegación de PA y los acuerdos comerciales. Al mismo tiempo, estamos considerando activamente si podemos adaptar mejor estos tipos de casos de uso y cómo hacerlo.
Inhabilitación del comprador	Es probable que la inhabilitación predeterminada del comprador tenga resultados más bajos en las subastas de componentes.	Ya sea que se defina una subasta de PA de un solo vendedor o varios vendedores, el vendedor debe indicar explícitamente 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. Recibiremos más discusiones en GitHub.
Aplicar Ads	No se puede aplicar el filtrado previo según el tamaño de anuncio y el tamaño del espacio publicitario.	Estamos trabajando para agregar esta función. Obtén más detalles aquí.
Compatibilidad con la segmentación negativa por IG	Una API para admitir la segmentación negativa de IG: muestra anuncios solo si un usuario no pertenece a una IG.	Este problema de GitHub 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 deberían estar vigentes para una solicitud de anuncio específica. Aunque este enfoque parece atractivo, todas las versiones de esta idea que hemos investigado permiten que el servidor identifique de manera única al usuario.
Ley de Servicios Digitales	¿Cómo puede un publicador usar marcos vallados y, además, evitar que se rendericen las respuestas que contienen información sujeta a la Ley de Servicios Digitales?	Al igual que con cualquier tecnología nueva, cada empresa es responsable de garantizar que el uso que haga de Privacy Sandbox satisfaga la ley. Google no puede proporcionar asesoramiento legal a otras personas. Para cada API, publicamos documentación técnica extensa, que debería proporcionar las bases para realizar las evaluaciones legales necesarias. Los marcos vallados no son necesarios para su uso en la API de PA desde 2026, lo que otorga tiempo adicional a las partes interesadas para garantizar que su uso de esta tecnología cumpla con toda la legislación relevante.
Documentación	¿Es updateAdInterestGroups() 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 también una dirección IP como proxy y agregar un retraso antes de que se realice la actualización.
Compatibilidad con la propiedad lógica y los metadatos orientados a la compra para plataformas que no son DSP	Solicitud de una forma de actuar como sustituto de las DSP.	Conocemos estos comentarios de segmentos que no pertenecen a la DSP y estamos considerando esta solicitud. Agradecemos los comentarios adicionales del ecosistema.
Informes	Solicitud para agregar una 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 cola para descubrir más detalles. Recibiremos más comentarios sobre el ecosistema aquí.
Documentación	¿Existe un vínculo en el que se puedan ver todos los encabezados de respuesta que deben establecer el anunciante y el dominio del propietario (delegado)?	Estamos planificando actualizaciones de la documentación para esclarecer esto y recibir comentarios adicionales del ecosistema.
Ofertas de varias torres	Solicitud de una explicación del flujo de trabajo (entrenamiento e inferencia) mediante una arquitectura o un diagrama de bloques sobre cómo se ve un enfoque de múltiples torres en el contexto de la API de PA.	Gracias por enviar tus comentarios. Tenemos algunas presentaciones sobre el tema de las que esperamos crear documentación adicional.
Segmentación negativa	Capacidad de Privacy Sandbox para proteger a públicos sensibles y menores de anuncios inapropiados, como juegos de apuestas.	La API de PA no tiene en cuenta el contenido de los anuncios que se muestran. Esto está a cargo de los desarrolladores de tecnología publicitaria que usan PA. En general, el publicador y sus proveedores de tecnología publicitaria pueden bloquear creatividades de anuncios en las subastas de Protected Audience usando información contextual de la página y los conjuntos de reglas del publicador. Esto refleja nuestra comprensión del enfoque que hoy en día aborda el ecosistema ante estos desafíos. Para los compradores, la funcionalidad de segmentación negativa de IG también puede ser útil para algunos casos de uso de cumplimiento.
Diseño de API	Google está rechazando la oferta 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 IG, lo que está permitido.	En el transcurso de nuestros análisis sobre la latencia de la subasta, destacamos que reutilizar la misma secuencia de comandos en todos los IG 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 subasta de la API de PA.
Marketing basado en cuentas	La API de PA no es una API simple para casos de uso de marketing basados en cuentas.	Agradecemos los comentarios del ecosistema sobre cualquier caso de uso específico que consideren posible y animamos a los participantes del ecosistema a continuar con este debate a través de nuestro repositorio público de GitHub o 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 de ejecutar una prueba A/B viable.	Respuesta de Google Ad Manager: Los controles de la API de PA en Google Ad Manager (GAM) afectan la capacidad de GAM de usar la API, siempre que esta esté disponible. Por lo tanto, los publicadores pueden ejecutar pruebas A/B mediante la funcionalidad de la política de permisos de Chrome para inhabilitar el uso de la API en un subconjunto de tráfico con el fin de usarla como grupo de control para una prueba A/B.
Aprendizaje automático	Los editores necesitan más control sobre el uso del aprendizaje automático que propone GAM.	Respuesta de Google Ad Manager: En enero de 2024, lanzamos un control que ofrece a los publicadores la capacidad de inhabilitar nuestro regulador de aprendizaje automático y habilitar subastas de APIs de PA con vendedores que no sean de Google en todo su tráfico. Puede encontrar más detalles sobre este control en nuestro Centro de ayuda.
(También se informó en trimestres anteriores) Subastas de nivel superior	Capacidad de usar el servidor de anuncios del publicador de Google sin dar también el control de GAM de la subasta de la API de PA de nivel superior.	Respuesta de Google Ad Manager: Por los motivos que se explican en el informe del tercer trimestre de 2023 de Google, los planes de GAM para su integración con la API de PA no incluyen compatibilidad con publicadores que usan GAM como su servidor de anuncios del publicador sin control de la subasta de nivel superior.
Acceso a la Información	GAM tiene acceso a información valiosa de los competidores, incluidos los precios contextuales de la subasta, los indicadores proporcionados por los compradores a las SSP para la subasta de la API de PA y los parámetros de configuración de las SSP.	Respuesta de Google Ad Manager: Durante años, mantuvimos un enfoque firme en la equidad de las subastas, incluida nuestra promesa de que ningún precio de ninguna de las fuentes publicitarias no garantizadas del publicador, incluidos los precios de las líneas de pedido no garantizadas, se compartirá con otro comprador antes de que oferte en la subasta, lo que luego reafirmamos 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 con nuestra promesa y no compartir la oferta de ningún participante con respecto a otros antes de que se complete en las subastas de varios vendedores. Para ser claros, 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 las configuraciones de subasta de componentes, incluidos los indicadores que proporcionan los compradores a las SSP, como parte de nuestra propia subasta. De hecho, aceptaríamos cambios en la API de PA que permitan a los vendedores de componentes especificar sus configuraciones de subasta de componentes de una manera que se ofusque con el vendedor de nivel superior.
Subastas de componentes	Como subasta de nivel superior, GAM controlará qué SSP ejecutan subastas de componentes para cada oportunidad de anuncio.	Respuesta de Google Ad Manager: Como servidor de anuncios del publicador, GAM ofrece una API liviana para SSP con la que un publicador podría trabajar para especificar sus configuraciones de subasta de componentes a través de la API de Google Publisher Tag (GPT). Puedes obtener más detalles aquí. Si una SSP proporciona una configuración de subasta de componentes a través de esta API, se incluirá en la lista de subastas de componentes para esa oportunidad de anuncio. GAM no impone ninguna restricción en las subastas de componentes incluidas. Podrá hacerlo cualquier SSP que desee ejecutar una subasta de componentes, siempre que 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 divulgado a cada oferta ganadora de la subasta de cada componente.	Respuesta de Google Ad Manager: GAM mantiene un enfoque sólido en la equidad de las subastas durante años. Como parte de mantener una subasta justa y transparente, no admitimos precios mínimos que solo se aplican a segmentos específicos de demanda. Ese es un principio coherente en nuestro producto y seguirá siendo así para las subastas de la API de PA.
Servidores de publicidad 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 SSP de Google en el contexto de la API de PA.	Respuesta de Google Ad Manager: Actualmente, GAM admite que se pruebe la API de PA con varios vendedores en GAM mediante la API que se describe aquí. Por el momento, 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	Informa que los verificadores indican que las subastas de la API de PA tienen una latencia alta.	Hemos escuchado inquietudes sobre la latencia y esta es, en parte, la razón por la que desarrollamos varias funciones como parte de la API de PA, lo que permitirá que las SSP establezcan límites en la latencia de la DSP y realicen mejoras que puedan disminuir la latencia. Recientemente, actualizamos nuestra guía de prácticas recomendadas sobre latencia, que incluye más información para aprovechar estas funciones. Además, seguimos desarrollando nuevas mejoras en la latencia, algunas de las cuales se pueden ver aquí.
(También se informó en trimestres anteriores) Renderización de videos	Compatibilidad con el procesamiento de videos con la API de PA y marcos cercados.	En enero, publicamos una demostración de cómo podrían funcionar los videos in-stream en una subasta de PA, con detalles adicionales sobre enfoques alternativos. También observamos que los participantes del ecosistema comienzan a proponer cómo funciona el procesamiento de videos para los socios que se integran con ellos, como las propuestas de GAM sobre la construcción de la URL de renderización compatible con video o el proceso completo de E2E. Además, estamos escuchando los comentarios del ecosistema sobre los cambios que podemos hacer para aumentar la adopción, y ese cambio se detalla en GitHub. Seguimos comprometidos activamente con el ecosistema para identificar cualquier otro obstáculo para la adopción que podamos encontrarnos 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 para la API de IG / PA?	En el diseño de la API de PA, todos los datos almacenados en los IG, o sobre qué personas están en los 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 manera que no sea para generar ofertas en la subasta. Algunas mejoras de privacidad que Chrome está explorando implican la interacción con un servidor de k-anonimato ejecutado por Google. Esa interacción se está diseñando cuidadosamente para evitar compartir información sobre los usuarios y para ejecutarla en un TEE a fin de garantizar la paridad de información en todo el ecosistema de anuncios. Google se comprometió a que la CMA diseñe e implemente las propuestas de Privacy Sandbox de manera que no distorsione la competencia prefiriendo el negocio de Google y tenga en cuenta el impacto en la competencia de la publicidad digital y en los publicadores y anunciantes. Seguimos trabajando estrechamente con la CMA para garantizar que nuestro trabajo cumpla con estas obligaciones.
(También se registran en trimestres anteriores) Desde el principio de IG	Solicita extender la vida útil de IG de 30 a 90 días.	Este cambio requiere una evaluación cuidadosa, que debe sopesar los beneficios para la industria con el impacto en los usuarios de Chrome y otras partes interesadas. Estamos considerando esta solicitud y agradecemos que nos envíes comentarios adicionales aquí.
(También se informó en trimestres anteriores) modelingSignals	Solicita un campo nuevo además de modelSignals, que solo puede codificar información de anuncios y clics.	Respondimos estos comentarios con una contrapropuesta aquí. Colaboramos activamente con la industria para comprender sus puntos de vista sobre nuestra propuesta y, actualmente, estamos comparando los beneficios para la industria con el impacto en los usuarios de Chrome y otras partes interesadas.
Bits adicionales en reportWin()	Proporciona bits adicionales en reportWin() a partir del límite actual de 12 antes de 3PCD.	Actualmente, estamos explorando enfoques para admitir este caso de uso. Nos está llevando tiempo, ya que también estamos buscando enfoques que puedan ayudarnos a garantizar un plan de privacidad a largo plazo.
Diseño de subastas	Solicitudes para una sola subasta que muestra URLs de renderización con su puntuación correspondiente.	Compartir varias URLs de renderización con su respectiva puntuación a partir de una sola subasta de PA es algo que consideramos, pero que no implementamos debido a inquietudes sobre la privacidad. Entendemos el deseo de evitar mostrar el mismo anuncio varias veces a un usuario en una sola página y agradecemos que se analicen en GitHub.
reportWin	registrar campos arbitrarios en la función reportWin().	Esto ya sucede actualmente durante el período de prueba. Una vez que Chrome deje de ser compatible con 3PC, se migrará la versión forDebuggingOnly de la API para habilitar la depuración con reducción de muestreo, como se especifica aquí.
Vendedores de componentes	Tienen un mecanismo independiente para contar sus propias impresiones y otros eventos, sin depender solo de los informes de las tecnologías publicitarias.	Esta solicitud de función está en nuestra cola para continuar con el descubrimiento. No tenemos previsto abordar este problema durante el período de prueba facilitado 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 vemos como una solicitud de sugerencias sobre cómo implementarla con la plataforma de API actual.
browserSignals	Se agregó IngressBidInSellerCurrency a los informes de la especificación de browserSignals para el vendedor.	Estamos considerando esta solicitud y agradecemos que nos envíes comentarios adicionales aquí.
Compatibilidad con la propiedad lógica y los metadatos orientados a la compra para plataformas que no son DSP	El diseño actual de la API podría implicar un cambio significativo en las campañas de resegmentación a nivel de producto, donde es posible que las campañas deban migrar a plataformas que funcionan como DSP y proveedores de campañas de Display.	Estamos analizando el problema y nos gustaría recibir más comentarios aquí.
Compatibilidad con la propiedad lógica y los metadatos orientados a la compra para plataformas que no son DSP	Comparte ejemplos en los que la DSP no sea el propietario de la IG.	Entendemos que quienes no son ofertantes quieren usar algunas funcionalidades de los IG, pero no otras. Evaluamos de forma activa las opciones para abordar estos casos de uso y recibimos comentarios adicionales aquí.
Controles de tiempo de espera	Los publicadores deben poder determinar la cantidad de IG que pueden participar y el tiempo de espera global o de nivel superior.	Entendemos que deseamos mejorar los controles de tiempo de espera y la visibilidad entre los vendedores de nivel superior y los de componentes, y estamos considerando esta solicitud.
Tamaño de varios anuncios	Compatibilidad con la API de PA para casos de uso de tamaños de anuncios múltiples.	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?	Respondemos esta pregunta aquí.
Depuración	Se mejoraron las capacidades de depuración para la API de PA.	Reconocemos la importancia de contar con herramientas de depuración robustas para los desarrolladores que trabajan con API de PA. Nuestro compromiso es mejorar la experiencia de los desarrolladores a través de la exploración de maneras de integrar mejor las recuperaciones de archivos .well-known en las herramientas para desarrolladores. Nuestro objetivo es brindar mayor visibilidad y capacidades de solución de problemas dentro del entorno de desarrollo. Estamos analizando este problema con más detalle aquí y agradecemos que nos envíes tus comentarios.
Etiquetas	¿Todos los usuarios de las etiquetas de tratamiento del modo B tienen habilitadas las APIs de Privacy Sandbox?	Las asignaciones de los grupos experimentales de Chrome se determinan de forma aleatoria y son independientes de la configuración de Chrome establecida por el usuario. Si bien estas APIs pueden estar disponibles para los usuarios de grupos de tratamiento específicos (p.ej., trate_1.*), su funcionalidad se puede modificar o inhabilitar en la configuración de Chrome. Grupo de control_2 del modo B: La inclusión en este grupo inhabilita intrínsecamente las APIs de relevancia y medición de Privacy Sandbox, y el usuario no puede anular esta configuración desde la configuración de Chrome.
Uso de API	¿La llamada a reportWin() y la renderización de anuncios se realizan en paralelo o uno después de otro?	Se llama a reportWin() directamente después de que se complete runAdSubasta(). 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 vallado. Una vez que se complete la ejecución de reportWin() y el anuncio comience a renderizarse, se recuperarán las URL proporcionadas a sendReportTo().
(También se informó en trimestres anteriores) Asistencia para A/B Testing	Solicita asistencia para las pruebas A/B de la API de PA.	Estamos analizando esta solicitud aquí y agradecemos que nos envíes tus comentarios.
Determinación del tráfico	La propuesta de Google para administrar la toma de decisiones necesaria a través del servidor de KV no es útil, ya que los vendedores no pueden interactuar con su backend, lo que dificulta la determinación del tráfico.	Como se analizó en el problema de GitHub, exponer si una DSP individual tiene presentes IG podría generar problemas con la creación de huellas digitales del usuario. Sugerimos otras alternativas con respecto al problema y estamos dispuestos a recibir más sugerencias.
Determinación del tráfico	Los mecanismos de almacenamiento en caché agregan una capa significativa de complejidad y evitan que las DSP conozcan la verdadera forma de tráfico en el que ofertarían.	El mecanismo de almacenamiento en caché se ofreció simplemente como una sugerencia. Las AdTech pueden elegir usar las sugerencias que se adapten a su caso de uso, y aceptamos debates adicionales aquí.
Etiquetas	Chrome debe compartir la etiqueta como parámetro en las solicitudes que se envíen a los servidores de confianza del comprador y el vendedor.	Esta parece ser una solicitud razonable, ya que está, en líneas generales, alineada con el objetivo del uso responsable de datos de IG. Sin embargo, estamos considerando la solicitud, la cual está sujeta a una revisión interna, y brindaremos actualizaciones públicas al respecto a medida que avancen los debates.
Uso de API	Se aclara la definición explícita del grupo "control_1" en el documento "Orientación adicional de la CMA para terceros sobre pruebas". En particular, existe la preocupación de que un cambio en la redacción pueda malinterpretarse como un requisito de la exclusión de todas las APIs de Privacy Sandbox de control_1.	Expresamos nuestras opiniones al respecto en esta conversación de GitHub. Dicho esto, no podemos hablar en nombre de la CMA, por lo que te sugerimos que le comuniques directamente a la CMA cualquier problema relacionado con la interpretación de sus lineamientos para las pruebas.
Uso de API	¿Chrome permitirá llamar a joinAdInterestGroup() en una página en blanco mientras se redirecciona a otro recurso?	Si un usuario visita un sitio, el propietario del sitio puede delegarle a un tercero la capacidad de llamar a joinAdInterestGroup. Esta delegación permite que un tercero cree IGs sin necesidad de agregar ningún tipo de redireccionamiento mediante una página en blanco. Agradecemos los comentarios sobre motivos específicos para crear IG en medio de un redireccionamiento en lugar de usar el mecanismo de delegación previsto.
Uso de API	Los intercambios deben poder escribir los IG en las páginas que son propiedad de los editores con los que trabajan y que luego pueden delegar el permiso para ofertar en esa IG a cualquier comprador o DSP determinados.	Recibimos los comentarios y estamos evaluando si se podría respaldar ese tipo de solicitud. Agradecemos los comentarios adicionales del ecosistema.
Uso de API	No hay una notificación de pérdida de depuración si nadie gana una subasta de API de PA.	Las funciones reportWin y reportResult de Chrome están diseñadas para los informes de ganancias a nivel del evento dentro del sistema de subasta de privacidad (PA). Cuando se rechazan todas las ofertas durante una subasta de PA, no se espera que se invoquen estas funciones porque no se determina un ganador. Una actualización reciente de Chrome podría explicar las discrepancias en las que las URLs que se pasaron a forDebuggingOnly.reportAdSubastaLoss() no aparecen en el panel de la red de Herramientas para desarrolladores. Te recomendamos que verifiques esta funcionalidad con una compilación de Chrome para canales Canary o para desarrolladores.
Uso de API	¿El valor de adCost que genera generateBid puede ser negativo (ya se redondea de manera estocástica a 2 bytes)?	El costo del anuncio es el costo por clic o conversión del anunciante que se pasa de generateBid() a reportWin(). Este valor puede ser Nulo o doble. Los valores negativos se ignorarán y no se pasarán. El valor se redondeará estocásticamente cuando se lo pase.
Mejora de la API	¿Se pueden usar servidores de Ejecución de confianza y Encriptado para manejar la segmentación, las cohortes, la atribución y las subastas en lugar del navegador Chrome?	Recomendamos explorar 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., Servicio de agregación), que abordan esta cuestión.
Mejora de la API	¿La respuesta de la subasta de Privacy Sandbox puede ser una respuesta a una oferta (como la oferta de encabezado) en lugar de una respuesta de un anuncio (como las etiquetas de anuncios)?	Este tipo de cambio cambia fundamentalmente las propiedades de privacidad de la API de PA, por lo que no lo estamos 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 esto aún no está disponible, observamos que la mayoría de las SSP crearon soluciones para habilitar esta función.
Uso de API	¿Cuál es el límite de tamaño en perBuyerSignals?	En su forma clásica, perBuyerSignals no tiene limitaciones de tamaño inherentes a Chrome. Las restricciones principales son que los datos siguen siendo serializables por JSON y no causan un consumo de memoria excesivo. Sin embargo, se debe tener en cuenta que perBuyerSignals muy grandes y complejos pueden afectar negativamente 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 al tamaño máximo del encabezado.
Documentación	Se debe cambiar la documentación sobre la llamada registerAdBeacon desde generateBid.	Actualizamos esta documentación el 17 de febrero.
Uso de API	¿Cómo reportEvent elige la URL del píxel contador correcta entre varias opciones registradas?	Cada subasta genera una configuración independiente, lo 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 de "Informes de anuncios de marcos vallados" proporciona más detalles sobre este tema.
IU de Chrome	Agregue el filtro en "Aplicación -> Grupos de interés" de Herramientas para desarrolladores de Chrome, lo que permite filtrar por propietario de IG (o quizás también por nombre de IG).	Estamos evaluando esta solicitud y agradecemos los comentarios adicionales del ecosistema.
Chrome sin interfaz gráfica	Compatibilidad con la API de PA en Headless Chrome	Hay algunos componentes de la API de PA que están vinculados a Chrome, por ejemplo, las llamadas de k-anon a los servidores de Google, que podrían no funcionar en la versión "antigua" de Headless Chrome. Creemos que esto se podría solucionar con la nueva versión" de Headless Chrome que se lanzó en Chrome 112.
Uso de API	En el caso de los informes de pérdidas con reportAdSubastaLoss, vemos la "topLevelWbindingBid=0" en muchos casos. ¿Cómo interpreta esto?	El valor topLevelWancingBid se origina en la función scoreAd() dentro del componente del vendedor de nivel superior. Este valor desempeña un papel importante en la determinación del resultado de la subasta de nivel superior. Según la explicación, un valor topLevelWTINGBid igual a cero o cualquier número negativo significa que el anuncio correspondiente no es apto para ganar la subasta. Este mecanismo puede utilizarse, por ejemplo, para filtrar los anuncios orientados por grupo de interés que no superan a un candidato de orientación contextual. Si bien una topLevelWTINGBid 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.
Prueba de modo A/B	Aclaración sobre la selección de tráfico de los modos B y A, y las instrucciones de inhabilitación	Los criterios de inclusión para los modos A y B son los mismos. El objetivo es tener grupos que representen el tráfico normal de Chrome, siempre y cuando admitan las APIs de Privacy Sandbox y el método de etiquetado, ya que algunas configuraciones de clientes 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 Protección contra seguimiento y, por lo tanto, reciben una notificación al respecto.
Mejora de la API	¿Se puede incluir "lifetimeMs" como una propiedad directa dentro de la llamada joinAdInterestGroup o administrarla como un argumento independiente?	Estamos considerando cuidadosamente los comentarios de la comunidad de desarrollo web sobre la funcionalidad "joinAdInterestGroup" en la propuesta de API de PA. Un punto de discusión clave se centra en el método óptimo para administrar el ciclo de vida 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 a la especificación. Estamos analizando este problema aquí y agradecemos que nos envíes comentarios adicionales.
Uso de API	Posible aumento de las tasas de falsos negativos en el framework de la API de PA debido a las colisiones con los IDs de navegador con baja entropía.	El equipo de Chrome participa activamente en el perfeccionamiento continuo del marco de trabajo de la API de PA. Agradecemos el debate sobre las posibles tasas de falsos negativos que surgen de las colisiones de ID de navegadores. Estamos evaluando cuidadosamente estos comentarios y trabajaremos para garantizar que los análisis actualizados reflejen de manera exhaustiva todos los factores relevantes. Nuestro compromiso es ofrecer una solución que logre los resultados de privacidad deseados y que, al mismo tiempo, mantenga la precisión y la confiabilidad. Estamos analizando este problema aquí y agradecemos que nos envíes comentarios adicionales.
Uso de API	¿Es necesario un identificador de navegador de baja entropía para evitar que los clientes envíen solicitudes “Join” de manera reiterada para el mismo objeto en un sistema de k-anonimato?	Reconocemos y agradecemos el debate continuo sobre el uso de identificadores de navegadores en la implementación de sistemas de k-anonimato. Comprendemos las inquietudes planteadas sobre las posibles implicaciones de estos identificadores para la privacidad. Si bien en nuestra implementación inicial se utilizó un identificador de baja entropía como mecanismo antiabuso, estamos explorando de forma activa técnicas alternativas, como los tokens de recuento anónimos, que priorizan la privacidad del usuario y mantienen la integridad del sistema. Nos comprometemos a encontrar soluciones que equilibran el uso responsable de datos con protecciones sólidas de la privacidad, y agradecemos el diálogo continuo con la comunidad de investigadores. Estamos analizando este tema aquí y agradecemos que nos envíes comentarios adicionales.
Uso de API	¿Las páginas de AMP (Accelerated Mobile Pages) son compatibles con la API de PA.	Actualmente, AMP no es compatible de forma nativa con la API de PA. Agradecemos los comentarios adicionales del ecosistema si el soporte de 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 agilizar el proceso. Nuestro objetivo es garantizar la eficiencia y el mantenimiento, y evaluamos todas las opciones a medida que seguimos desarrollando nuestras soluciones de privacidad. Estamos analizando este problema aquí y agradecemos que nos envíes comentarios adicionales.
IU de Chrome	Solicitud de un mecanismo para que los usuarios menos técnicos vean y administren fácilmente los IG a los que pertenecen, incluidos los posibles controles a nivel del sitio web para inhabilitarlos.	Reconocemos la importancia de proporcionar herramientas fáciles de usar para comprender y administrar los IG. Analizamos cuidadosamente varios métodos y descubrimos que identificar los IG mediante 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 las IG se encuentra en la configuración de Chrome. Investigamos continuamente maneras de mejorar aún más la experiencia del usuario en esta área. Estamos analizando este problema aquí y agradecemos que nos envíes comentarios adicionales.
Seguridad de las APIs	¿La API de PA es vulnerable a filtraciones de privacidad a través de interacciones creativas con los anuncios, incluso en el contexto de marcos protegidos?	Reconocemos la posibilidad de filtración de información mediante interacciones sofisticadas con los anuncios. Estamos investigando activamente la interacción entre Fenced Frames, la API de PA y posibles vectores de ataque. Mitigar los riesgos de privacidad es una de nuestras principales prioridades, y estamos comprometidos a desarrollar soluciones sólidas que equilibran la innovación con la protección de los usuarios. Estamos analizando este problema aquí y agradecemos que nos envíes 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 presentadas respecto de las posibles inconsistencias entre la especificación y el momento de las solicitudes de red en relación con la lógica de ofertas. Estamos revisando activamente las especificaciones para garantizar su precisión y también investigando la configuración óptima de tiempo de espera predeterminada para equilibrar el rendimiento y la viabilidad. Estamos analizando este problema aquí y agradecemos que nos envíes comentarios adicionales.
Documentación	Posible fuga de tiempo en la especificación en la que un sitio web podría inferir si un anuncio no cumplía con el umbral de k-anonimato y las posibles implicaciones para el seguimiento entre sitios.	Reconocemos el problema que surgió en relación con una posible filtración de información sobre los plazos. Confirmamos una discrepancia en la especificación y estamos tomando medidas para garantizar que se determine el estado de k-anonimato de los anuncios antes de la subasta para evitar estas filtraciones. Nos tomamos muy en serio estas inquietudes y actualizaremos la especificación para reflejar estos cambios. Estamos analizando este problema aquí y agradecemos que nos envíes comentarios adicionales.
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 por parte de las SSP. Recomendamos explorar soluciones que prioricen la evaluación integrada en el dispositivo y aprovechen los metadatos de anuncios existentes para proteger la privacidad del usuario y, a la vez, 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 que nos envíes comentarios adicionales.
Uso de API	¿Puede alguien decirle a su navegador que simule usar una API de PA de una manera que los sitios no puedan detectar?	Reconocemos que, en su forma actual, los sitios web podrían detectar si se inhabilita la API de PA. Estamos trabajando activamente en funciones como las ofertas adicionales y la segmentación negativa, además de la renderización de marcos vallados, para mejorar la privacidad y trabajar para proporcionar opciones de inhabilitación que no se puedan detectar. Estamos analizando este problema aquí y agradecemos que nos envíes comentarios adicionales.
Prueba de modo A/B	Tráfico del centro de datos que pretende ser el 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 que nos envíes comentarios adicionales.
Uso de API	Eficiencia y equidad de la implementación de interestGroupBuyers en la API de PA	Reconocemos el debate continuo sobre la eficiencia y la equidad del campo "interestGroupBuyers" en las subastas de la API de PA. Reconocemos el equilibrio entre eficiencia, privacidad y equidad en el mercado. Si bien los vendedores deben administrar las relaciones comerciales con los compradores, estamos explorando formas de optimizar el proceso de vinculación. Estas 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 que nos envíes comentarios adicionales.
IU de Chrome	Potenciales problemas de memoria y claridad de la IU relacionados con IG en Chrome	Comprendemos las inquietudes que se plantean sobre mostrar IG en Herramientas para desarrolladores. 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 optimizaciones y posibles mejoras en la IU para mejorar las estadísticas de los desarrolladores. En cuanto a la administración de memoria, la implementación de IG está diseñada para prevenir fugas de memoria, pero supervisamos y optimizamos continuamente el uso de recursos. Estamos analizando este problema aquí y agradecemos que nos envíes comentarios adicionales.
Documentación	El publicador original encuentra un error al intentar usar tamaños de anuncio con nombre directamente dentro del campo "sizeGroup" de la función "joinAdInterestGroup". Quieren saber si este es el comportamiento previsto.	Reconocemos el valor de optimizar la configuración de anuncios en la función "joinAdInterestGroup". Estamos trabajando activamente para abordar esta limitación y tenemos previsto habilitar esta función en futuras actualizaciones. 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 que nos envíes comentarios adicionales.
Etiqueta de prueba facilitada por Chrome	Solicita datos directos sobre el modo A en comparación con el modo B y las etiquetas exactas en sendReportTo para que podamos hacer un seguimiento del experimento de forma coherente.	Estamos analizando esta solicitud aquí y agradecemos que nos envíes tus comentarios adicionales.
Documentación	¿Se incluye el nombre de dominio del vendedor en las solicitudes realizadas a su servidor de confianza con fines de validación?	Aceptamos la omisión inicial del parámetro de nombre de host en 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 a su servidor de confianza. Esta función es esencial para lograr procesos de validación de anuncios sólidos. Actualizamos la documentación para abordar este descuido y seguiremos priorizando la claridad y la transparencia para la comunidad de desarrolladores. Estamos analizando este problema aquí y agradecemos que nos envíes 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 generación de informes	Nos comprometemos a equilibrar la necesidad de contar con 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 las protecciones de k-anonimato diseñadas para evitar la identificación de personas. Seguiremos explorando soluciones de informes innovadoras que estén dentro de estas restricciones de privacidad. Estamos analizando este problema aquí y agradecemos que nos envíes comentarios adicionales.
Función de la API	Solicitud para que el servidor de confianza del comprador reciba encabezados HTTP de Client Hints.	Estamos realizando un seguimiento de la solicitud de función aquí.
Uso de API	Si el archivo de delegación debe requerir la carga del encabezado "Access-Control-Allow-Origin", dado que indica el comportamiento de la membresía de IG para el navegador	Asumimos el compromiso de alinearnos con las prácticas recomendadas de seguridad web. El requisito del encabezado “Access-Control-Allow-Origin” para la delegación de archivos garantiza la coherencia con los principios de CORS y evita la exposición involuntaria 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 que nos envíes comentarios adicionales.
Uso de API	Permite que los servidores de anuncios personalicen creatividades dentro del marco de trabajo de la API de PA.	Reconocemos la función que pueden desempeñar 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ía combinar la lógica de oferta y de selección de creatividades de anuncios. Nuestro objetivo es lograr un equilibrio entre habilitar capacidades sólidas de creatividad de anuncios y proteger la privacidad del usuario. Aceptamos más colaboración y comentarios sobre cómo mejorar la API para satisfacer las necesidades de todas las partes interesadas aquí.
Preocupaciones sobre privacidad	Disponibilidad de identificadores alternativos (p.ej., RampID, ID5) en las solicitudes de ofertas contextuales podría socavar los objetivos de privacidad de la API de PA, ya que facilitaría 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 busca separar la selección de anuncios de la necesidad de hacer un seguimiento entre sitios. Nos comprometemos a fomentar un ecosistema publicitario centrado en la privacidad y alentamos a los desarrolladores a priorizar el enfoque de la API de PA. Estamos analizando este problema aquí y agradecemos que nos envíes comentarios adicionales.
Almacenar en caché	¿Existe alguna manera de evitar la reutilización de las 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 mecanismos estándar de almacenamiento en caché de HTTP, existe la posibilidad de reutilizar secuencias de comandos en 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 brindar a los compradores un mayor control sobre el almacenamiento en caché de secuencias de comandos para administrar sus estrategias de ofertas de manera eficaz. Estamos analizando este problema aquí y agradecemos que nos envíes comentarios adicionales.
Uso de API	Centralice la generación de informes de la actividad de ofertas en todos los IG para una DSP, a la vez que se 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 del seguimiento entre sitios, ofrecemos mecanismos como el almacenamiento compartido y la agregación privada. Esto permite que las DSP obtengan estadísticas agregadas sobre la actividad de ofertas de una manera que preserve 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.reportAdSubastaWin().	Si bien es posible que no tengan la misma sincronización, es posible que ambas URLs se recuperen al mismo tiempo. En algunos casos, se eliminó el worklet del vendedor del componente y se debe volver a cargar para luego ejecutar la función reportResult(). Sin embargo, ni el tiempo que lleva recuperar la lógica de puntuación ni el tiempo de que se vuelva a cargar el worklet afecta el tiempo de espera de 50 ms de reportResult(). Ten en cuenta que Chrome usará los encabezados de almacenamiento en caché para definir su comportamiento de recuperación en los casos en que se deba volver a cargar el 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 del 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) en un período anterior (w). El estado de k-anonimato se actualiza periódicamente (p).
IU de Chrome	Propuesta para brindar el tipo de "visibilidad interna" que ofrecen muchos marcos de trabajo MVC, ORM, etc. P.ej., comienza con el registro simple de eventos internos seleccionados en un nuevo panel en Herramientas para desarrolladores --> Aplicación --> sección de Aplicación	Estamos analizando la propuesta aquí y agradecemos que nos envíes comentarios adicionales.
IU de Chrome	La unión a IG de Herramientas para desarrolladores no muestra elementos relacionados con la prioridad.	Hemos resuelto este problema aquí.
Mejora de la API	Sería preferible permitir que el servidor de anuncios creativos 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 comentarios adicionales del ecosistema.
Solicitud de función de la API	¿Se puede extender la API de PA para admitir transacciones de medios que no sean RTB y mantener casos de uso fundamentales, como la publicación de anuncios y el Optimizador de campañas de la Red de Display?	Estamos analizando el problema aquí y agradecemos que nos envíes comentarios adicionales.
Tiempo de espera de la subasta del publicador	Los publicadores necesitan controlar la duración de la subasta para evitar la pérdida de impresiones, especialmente en las configuraciones de ofertas por encabezado, en las que los anuncios se seleccionan de forma secuencial.	Sabemos que es importante brindarles a los publicadores un control detallado sobre los tiempos de espera de las subastas de anuncios. Estamos explorando activamente cómo implementar un mecanismo de tiempo de espera de la subasta global, posiblemente dentro del objeto "auctionConfig", mientras consideramos cuidadosamente los casos extremos. El objetivo de esta función es optimizar las tasas de relleno de impresiones de los publicadores, y seguiremos colaborando con la comunidad para encontrar la mejor solución. Estamos analizando el problema aquí y agradecemos que nos envíes comentarios adicionales.
Mejora de la API	El diseño actual de los IG en la API de PA genera grandes tamaños de metadatos debido a las URLs de renderización extensas. Los verificadores desean una forma de comprimir estas URLs para ser más eficientes.	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 las URL de renderización ofrece un gran potencial. 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. La colaboración con la comunidad de estándares de la Web para desarrollar el enfoque óptimo, teniendo en cuenta estas consideraciones, sigue siendo una prioridad. Estamos analizando el problema aquí y agradecemos que nos envíes comentarios adicionales.
Uso de API	Los verificadores que manejan formatos de anuncios nativos quieren optimizar el proceso de subasta de Privacy Sandbox recuperando varios resultados de anuncios en una sola llamada para reducir la carga de red y mejorar la velocidad de renderización de anuncios.	Reconocemos los problemas de rendimiento planteados con respecto a la renderización de anuncios nativos en Privacy Sandbox. Nos comprometemos a encontrar un equilibrio entre la eficiencia y las sólidas protecciones de la privacidad de los usuarios. Si bien mostrar varios anuncios con puntuaciones completas pone en riesgo la privacidad, exploramos activamente formas de optimizar el proceso de subasta. Nos dedicamos a mejorar la compatibilidad de la API de PA para 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 que nos envíes comentarios adicionales.
Uso de API	La flexibilidad en cuanto a cómo se califican y ordenan las ofertas de anuncios dentro de Privacy Sandbox, especialmente para representar los niveles de prioridad o las reglas del mercado privado.	Comprendemos la necesidad de un control detallado sobre la puntuación y el ordenamiento de los anuncios en Privacy Sandbox, especialmente en situaciones de ofertas complejas. Reconocemos las soluciones propuestas con tuplas y funciones matemáticas para lograr una puntuación multidimensional sin sacrificar la privacidad del usuario. Si bien estos enfoques pueden agregar complejidad a los desarrolladores, ofrecen la expresividad necesaria. Nos comprometemos a explorar formas de optimizar estos procesos, posiblemente a través de funciones o lineamientos auxiliares, para garantizar el uso óptimo de las funciones de Privacy Sandbox para la lógica de subasta avanzada. Estamos analizando este problema aquí y agradecemos que nos envíes comentarios adicionales.
reportEvent()	Agrega un evento reservado nuevo (por ejemplo, el píxel contador automático) que activa el navegador una vez que se inicializa un marco con una creatividad de anuncio.	Estamos analizando esta solicitud aquí y agradecemos que nos envíes tus comentarios.
adCost	Permite el desglose de adCost.	Cada valor del 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 que nos envíes tus comentarios.
resolveToConfig	¿resolveToConfig debería heredarse del nivel superior y exponerse en browserSignals?	Estamos analizando esta solicitud aquí y agradecemos que nos envíes tus comentarios.
Mejores herramientas	¿Hay algo similar a chrome://topics-internals pero para la API de PA?	No hay nada exactamente igual. Sin embargo, existen herramientas extensas para desarrolladores en la API de PA.
Etiquetas	¿Chrome puede 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	¿Los trabajos de subasta de Privacy Sandbox se convertirán en tipos de worklet estándar?	Debido a los requisitos únicos de seguridad y privacidad, estos trabajos difieren significativamente de los tipos de worklet estándar del navegador, por lo que no prevemos que pronto se convertirán en tipos de worklet estándar dentro de la especificación HTML. Nos comprometemos a mejorar nuestros recursos para desarrolladores con explicaciones claras sobre la implementación y el entorno de ejecución de los trabajos de subasta, lo que hace que esta información sea más accesible para los participantes de Privacy Sandbox. Debatimos este tema con más detalle aquí.
Servidor clave-valor (KV) Bring-Your-Own-Server (BYOS)	Las partes pueden aprender varios IG (del mismo propietario) unidos por un usuario a través de consultas de servicios de KV en una configuración del servicio de KV de BYOS.	Esto ya no será posible cuando los servidores KV se ejecuten en TEE, y podemos asegurarnos de que puedan cumplir con el modelo de confianza publicado.
userBiddingSignals	actualizar parte de "userBiddingSignals" y, al mismo tiempo, mantener otros.	Esto ya es posible sin que se requiera ningún cambio en la API.
Uso de API	Implementar la limitación de frecuencia en varios IG dentro de Privacy Sandbox, posiblemente con el servidor KV o datos modificados de "prevWinsMs".	Reconocemos la necesidad de contar con capacidades avanzadas de limitación de frecuencia dentro de Privacy Sandbox. Reconocemos que las restricciones actuales sobre el uso compartido de datos entre los IG pueden presentar desafíos a la hora de implementar estas estrategias. Si bien el servidor KV proporciona un posible mecanismo con las protecciones de privacidad adecuadas, recomendamos a los desarrolladores que exploren soluciones en un único modelo de IG. Estamos analizando este problema aquí y agradecemos que nos envíes 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 la 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 adición de nuevos mecanismos de tiempo de espera, incluido un tiempo de espera potencial completo para la subasta y explorando formas de aplicar tiempos de espera de nivel superior a las subastas de componentes. Nuestro objetivo es mejorar la eficiencia y previsibilidad para todos los participantes del proceso de subasta de Privacy Sandbox. Estamos analizando este problema aquí y agradecemos que nos envíes 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 que en los centros de datos de tecnología publicitaria locales?	Nuestra respuesta es similar a la de trimestres anteriores: Nuestro modelo de seguridad de TEE actual se beneficia de las prácticas de implementaciones de nubes públicas. En particular, los TEE actuales basados en hardware no defienden todos los ataques físicos. Nuestros proveedores de servicios en la nube pública admitidos, AWS y GCP, diseñaron e implementaron mitigaciones para los riesgos de acceso físico, incluidos los de los empleados. A continuación, se indican más detalles sobre la asistencia local. 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 locales. Si bien no podemos evaluar estas afirmaciones, agradecemos que nos envíes comentarios adicionales sobre los costos y seguimos evaluando opciones para ampliar nuestra asistencia a los equipos de TEE.
TEE	Compatibilidad con TEE en entornos de nube no pública	Nuestra respuesta es similar a la de trimestres anteriores: Si bien seguimos explorando la compatibilidad con otras opciones más allá de las soluciones basadas en la nube pública, actualmente no tenemos planes de admitir los TEE locales. En esta etapa, teniendo en cuenta los requisitos de seguridad de Privacy Sandbox y los desafíos significativos que presentan las implementaciones locales, creemos que continuar expandiendo y mejorando las implementaciones basadas en la nube (por ejemplo, admitir Google Cloud además de AWS) es lo más beneficioso para el ecosistema. Sin embargo, recibiremos comentarios adicionales sobre por qué un requisito de este tipo es necesario y factible dadas las restricciones de privacidad y seguridad.
Otros proveedores de servicios en la nube	Asistencia para otros proveedores de servicios en la nube	Siempre estamos dispuestos a recibir sugerencias para otros proveedores de servicios en la nube, pero, por el momento, al menos estamos planificando admitir GCP y AWS cuando se aplique 3PCD. Consulte esta explicación para obtener más información.
API de B&A Services	¿Cuáles son las instrucciones 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 los trimestres anteriores: Seguimos comprometidos con el diseño actual de las ofertas integradas en el dispositivo de Protected Audience. Se propusieron los servicios de B&A para explorar posibles soluciones a fin de admitir un subconjunto de casos de uso en los que la potencia de procesamiento o la velocidad de la red del dispositivo pueden ser limitadas.
Estandarización	Los servicios de B&A no han pasado por un proceso de estandarización.	La propuesta de servicios de B&A está en el medio de una fase del proceso de estandarización, y agradecemos que se involucren más para lograr ese objetivo. Comenzó con una propuesta (basada en propuestas anteriores), que se está incubando públicamente a través de un debate abierto extenso en W3C y los desarrolladores interesados pueden comenzar a experimentar con ella y proporcionar comentarios. Este es el patrón habitual para el desarrollo de funciones web, como se describe por ejemplo en la entrada de nuestro blog aquí.
Servidor KV	Exponer la URL completa al servidor KV del comprador para la segmentación por contenido, contextual o sitio	Estamos analizando esta solicitud aquí y agradecemos que nos envíes comentarios adicionales del ecosistema.
Documentación	La documentación de “Componentes confiables o aplicados en comparación con opcionales” en GitHub genera confusión con algunas tecnologías publicitarias que tienen su propio conjunto de imágenes e infraestructura de implementación.	Estamos trabajando para mejorar la documentación sobre "Componentes confiables o aplicados en comparación con los opcionales" y nos interesa saber del ecosistema si es necesario priorizar ese trabajo.
Mejora de la API	El código de estado HTTP de una llamada al servidor KV también debería estar disponible para la función scoreAd() como parámetro.	Estamos evaluando esta solicitud y agradecemos 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 la UDF.	Estamos trabajando para proporcionar esta información y agradecemos que nos envíes comentarios adicionales aquí.
Documentación	Solicita actualizar el nombre del repositorio.	Cambiamos el nombre del repositorio por "protection-auction-key-value-service". El término está en consonancia con el término para la colección de servicios a la que pertenece, que también incluye otros repositorios, como la discusión sobre los servicios de Protected Audience y los repositorios de documentación de los Servicios de subasta protegidos.
Documentación	Se quitó la referencia a la API del depurador de Cloud en bidding_auction_services_gcp_guide.md.	Actualizamos la documentación y quitamos la referencia.
Uso de API	La latencia ingresada por la búsqueda de KV tarda más de 50 ms. Tarda casi 100 ms. ¿Tienes información sobre lo que les ha dado buenos resultados a otros vendedores? ¿Tienes alguna sugerencia sobre cómo medir los tiempos de espera y los tiempos?	La llamada al servidor KV ocurre 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 en estos ejecutores de secuencias de comandos protegida contra cualquier acceso que no sea de API. Puedes encontrar una explicación detallada aquí.
Uso de API	¿Hay un tiempo de espera para que el servidor 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 los indicadores de ofertas confiables.
Latencia	¿Cómo trabaja el equipo de Privacy Sandbox para abordar la latencia?	Si quieres conocer las estrategias que estamos explorando para mantener la latencia dentro de límites aceptables, consulta este vínculo.

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 las campañas. La ARA se desarrolló de un modo que permite la personalización y flexibilidad de la tecnología publicitaria para resolver una variedad de casos de uso de tecnología publicitaria. Algunas sugerencias que se proporcionaron incluyeron el uso de diferentes configuraciones flexibles a nivel de evento y el uso de informes a nivel de evento con informes de resumen para reducir el impacto del ruido y satisfacer sus necesidades de optimización manuales y automáticas. Estamos dispuestos a recibir más comentarios sobre el ecosistema con respecto a la personalización y flexibilidad de los parámetros de configuración de la ARA.
Tipo de conversión	Google solo permite ocho tipos de conversión, lo que supone un límite.	Implementamos la mayoría de los informes flexibles a nivel del evento, lo que brinda a las plataformas de tecnología publicitaria mayor flexibilidad en términos de la cantidad de ventanas de informes, la cantidad de informes de atribución y los bits de datos de activadores que pueden utilizar. 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 puede usarse para los anunciantes más pequeños con un presupuesto limitado.	No se necesita una cantidad mínima de eventos de conversión por informe agregable. Además, hay una serie de decisiones de diseño que se pueden tomar para optimizar los informes agregables para anunciantes más pequeños, como cambiar la estructura o las dimensiones clave a las que se hace seguimiento, probar diferentes niveles de épsilon, probar frecuencias de lotes más extensos y probar diferentes asignaciones de presupuesto de contribución entre 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 resumen.
Datos en tiempo real	Privar a las DSP de datos en tiempo real (p.ej., de clics, sesiones y conversiones) que utilizan para adaptar su estrategia de ofertas y lograr una mejor eficacia de las campañas, va en contra del compromiso de mantener las funciones existentes.	Incluso con la ARA, los clics y las sesiones se mantienen en tiempo real, y las conversiones siempre se producen después, incluso con las 3PC.
Campos incompletos	Faltan requisitos en el lanzamiento de eventos completamente flexibles: i) campo Currency y ii) campo orderID / TransactionID.	Por el momento, no planeamos admitir los campos Moneda ni ID de pedido o ID de transacción como parte de la flexibilidad completa a nivel del evento porque ya existen formas de hacerlo con los informes actuales a nivel del evento. Estamos dispuestos a enviar 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 la ARA para medir la información del tipo de ID de pedido y moneda: 1. En función de los comentarios, la moneda se determina según la ubicación geográfica del usuario, que se puede agregar como parte de source_event_id para determinar qué moneda se usó. 2. Según los comentarios recibidos, el campo ID de pedido es necesario para garantizar que las conversiones y los valores no se cuenten dos veces por error, lo que se puede hacer con claves de anulación de duplicación.
Presupuesto de privacidad	El presupuesto de privacidad de la ARA limita la capacidad de realizar mediciones en múltiples dimensiones	La ARA se diseñó de modo que las tecnologías publicitarias puedan personalizar sus propios parámetros de configuración de la ARA para abarcar una variedad de situaciones de atribución. Con el diseño actual de la ARA, las tecnologías publicitarias deberán considerar el equilibrio entre las dimensiones que son más cruciales para su medición y el impacto del ruido en sus datos. Agregar ruido a los datos en función del nivel de detalle de las dimensiones que se miden es fundamental para la privacidad. Estamos dispuestos a recibir más comentarios del ecosistema sobre la capacidad de realizar mediciones en diferentes dimensiones, pero necesitamos comprender los casos de uso específicos que lo requieren.
Actualizar especificación	Si bien Google afirma que pasó de una ventana de informes de eventos fija a una flexible, esto no se ve reflejado 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 fuente, los bits de datos del activador y la cantidad o duración de las ventanas de informes. La ARA aún tiene un período mínimo de 1 hora para los informes a nivel del evento, lo que es fundamental para mantener la privacidad y mitigar contra ciertos tipos de ataques de reconstrucción del historial. Dado que los informes de resumen proporcionan información de forma agregada, las plataformas de tecnología publicitaria pueden habilitar la recepción de informes agregables de inmediato sin demora, si es necesario para sus casos de uso.
Diseño de API	Le preocupa que reducir la información en los informes de conversión y agregar ruido podría tener más impacto en el ecosistema que en Google.	Google se comprometió con la CMA a diseñar e implementar las propuestas de Privacy Sandbox de manera que no distorsione la competencia prefiriendo el propio negocio de Google y que tenga en cuenta el impacto en la competencia de la publicidad digital y en los publicadores y anunciantes de todos los tamaños.
Corrección de la atribución	La ARA no permite que el proveedor de tecnología controle y verifique la atribución correcta.	Hay muchas soluciones disponibles dentro de la ARA que proporcionan capacidades de verificación: 1. Las tecnologías publicitarias pueden verificar que el comportamiento de la ARA coincida con sus expectativas: – El código del cliente de la ARA es de código abierto. – El código del servidor de la 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 les proporcionó a las tecnologías publicitarias una biblioteca de simulación para verificar el comportamiento de las atribuciones, en la que pueden probar cómo la ARA realiza la atribución en un entorno simulado. 3. La ARA admite varios indicadores de depuración que ayudan a verificar si es posible que no se haya producido el procesamiento esperado y por qué.
(También se informó en trimestres anteriores) Ruido	Comentarios que indican que el nivel de ruido es demasiado alto y está afectando la utilidad de los informes	Hablamos con las tecnologías publicitarias con estos mismos comentarios y pudimos identificar las formas en que se puede personalizar la ARA para que se adapte mejor a sus casos de uso, incluso con ruido. Contamos con 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. Las ARA se diseñaron para permitir que las tecnologías publicitarias personalicen sus propios parámetros de configuración 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 qué dimensiones son más cruciales para medir y el impacto del ruido en sus datos. Estamos dispuestos a recibir comentarios adicionales del ecosistema sobre el impacto del ruido y podemos proporcionar orientación adicional sobre los impulsores de la ARA que pueden usarse 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 dispuestos a recibir comentarios adicionales sobre el ecosistema de la ARA sobre este aspecto del diseño.
Mejora de la API	Cambia periódicamente el factor de escala utilizado al registrar la atribución para los informes de resumen de la ARA.	Según la discusión en GitHub, parece que manejar varios factores de escalamiento en el servicio de agregación probablemente dará como resultado una mayor cantidad de ruido agregado a los informes de resumen en comparación con la funcionalidad actual. Estamos dispuestos a recibir comentarios adicionales sobre la necesidad de factores de escalamiento como parte de los informes agregables, pero queremos destacar el posible equilibrio con un aumento en el ruido. También estamos evaluando si otras funciones futuras de la ARA podrían ayudar a resolver este caso de uso.
Uso de API	Oportunidad de unificar cómo se comparten los eventos de atribución con todos los participantes, lo que es beneficioso para SSP, DSP, etcétera.	Planeamos realizar una sincronización con la tecnología publicitaria para comprender mejor sus comentarios y las limitaciones con las que se encuentran.
Probar el volumen del tráfico	¿El tráfico de prueba para el modo B es estable en todo Chrome?	La inclusión en un grupo experimental no se ve afectada por la configuración de Chrome (independientemente de ella).
Documentación	Se agregó compatibilidad con la ARA para píxeles.	Publicamos información sobre cómo admitir este caso de uso y recibimos con gusto comentarios adicionales del ecosistema.
Uso de API	Es posible que la ARA no se atribuya a la fuente correcta para vendedores externos en plataformas de comercio electrónico si la conversión no se realiza en el último contacto.	Las empresas pueden usar filtros para evitar que se produzcan atribuciones incorrectas (ya que no se generará ningún informe de conversiones). También estamos trabajando en una propuesta de filtrado previo de atribuciones para ayudar con este caso de uso.
Navegadores compatibles	¿Se admitirá la ARA en diferentes navegadores?	Aceptamos que otros navegadores adopten las APIs de Privacy Sandbox y seguimos dedicando tiempo a debatir nuestro enfoque en el W3C. Definimos explícitamente la interoperabilidad como un objetivo para el envío de la ARA, y el diseño de la ARA es independiente del navegador y tiene valores flexibles especificados por el proveedor para proveedores con diferentes posturas de privacidad. Otros navegadores están tomando sus propias decisiones sobre si brindar alternativas viables al contenido del ecosistema entre sitios y que puedan admitir el ecosistema digital. Te alentamos a que Microsoft Edge indica que sea compatible con la ARA.
Uso de API	¿Cuál es el tipo de fuente esperado para los registros de fuentes de la ARA para registerAdBeacon/reportEvent (y balizas automáticas de navigation_start/commit)?	Depende de si los píxeles contadores son automáticos o manuales: - reservados.* (es decir, automáticos) sean del tipo de fuente de navegación. : Son eventos activados de forma manual para que sean del tipo de fuente de eventos.
Uso de API	¿El límite máximo de 20 informes agregables por fuente significa para cada evento de fuente? ¿El límite es global o diario? ¿Hay algún plan para aumentar este 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 límite lo establece el navegador y este 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. Debatimos este tema con más detalle aquí.
Uso de API	Compatibilidad con el marketing por correo electrónico mediante la ARA.	En este momento, no hay asistencia directa para este caso de uso dentro de la ARA (si no controlas el sitio de hosting de correo electrónico). Estamos analizando este tema aquí y agradecemos que nos envíes tus comentarios.
Epsilon	¿Cuándo se determinará el valor de épsilon para la API de Aggregate?	Las tecnologías publicitarias pueden configurar el valor de épsilon actual hasta un umbral predeterminado definido por Privacy Sandbox (que actualmente es 64). Recomendamos probar diferentes valores de épsilon, identificar puntos de inflexión para tus propios casos de uso y proporcionar comentarios. Nos aseguraremos de comunicarnos con las tecnologías publicitarias con anticipación antes de cualquier cambio en el rango de valores de épsilon.
Mejora de la API	Admitir un caso de uso en el que el anunciante pueda insertar un identificador en el campo trigger_data para buscar coincidencias con datos externos de CRM que les permitan a los anunciantes verificar la calidad de las conversiones	Estamos analizando la solicitud y agradecemos que nos envíes comentarios aquí.
Uso de API	Cómo manejar las URLs de redireccionamiento como URLs de destino	Las tecnologías publicitarias pueden realizar cualquiera de las siguientes acciones: 1. Ingresa la URL de destino final en el campo de destino. 2. El campo de destino admite hasta 3 URLs, lo que le permite incluir varias URL en el campo. Ambas opciones requerirán que se especifique la URL de destino final. Consultamos este tema con más detalle aquí.

Servicio de agregación

Tema de los comentarios	Resumen	Respuesta de Chrome
Mecanismo clave de descubrimiento	Solicitud de un mecanismo de descubrimiento de claves	Tenemos una propuesta de descubrimiento clave y recibimos comentarios del ecosistema sobre la propuesta.
Uso de API	Hoja de ruta para la observabilidad del servicio de agregación	Estamos revisando las opciones para aumentar la observabilidad y agradecemos los comentarios del ecosistema aquí.
Mejora de la API	Solicitando poder volver a consultar informes.	El servicio de agregación está trabajando en una propuesta de consulta en la que las tecnologías publicitarias pueden dividir su épsilon para cada informe. Esto puede generar más ruido por búsqueda, pero permitirá que las plataformas de tecnología publicitaria vuelvan a realizar consultas y mantengan la privacidad.
Mejora de la API	Te gustaría poder asociar varios orígenes al mismo ID de AWS.	El servicio de agregación ahora permitirá la integración de varios sitios en la misma cuenta de la nube (GCP o AWS). Esto permitirá que las tecnologías publicitarias usen el mismo enclave del servicio de agregación para procesar informes de varios sitios y orígenes múltiples de los mismos sitios.
Uso de API	Cuando fallan los lotes agregables, no estás seguro de si el presupuesto se consume o no y si pueden volver a procesar su lote. Cuando un servicio de agregación encuentra un error de presupuesto por informes duplicados, se pierde el resto de los informes restantes. ¿Cómo se puede minimizar esta pérdida?	En una situación típica, si falla todo el trabajo, no se consumirá el presupuesto. En casos excepcionales en los que se consume el presupuesto, las plataformas de tecnología publicitaria pueden solicitar la recuperación del presupuesto. Si la tecnología publicitaria encuentra fallas de trabajo frecuentes con el error de presupuesto agotado, deben confirmar su estrategia de lotes. Aquí encontrará instrucciones para agrupar datos correctamente y evitar la duplicación de informes y errores. Agradecemos los comentarios sobre la recuperación del presupuesto aquí.
Uso de API	Si se usa la API de Private Aggregation con el activador que se describe aquí, se produciría un informe agregable para cada subasta. ¿Cuáles son las capacidades de escalamiento del servicio de agregación?	El servicio de agregación en sí no establece un límite superior en la cantidad de claves o informes por lote, pero una escala de 10^14 informes y 10^12 claves no es compatible actualmente debido a la memoria que se requeriría. En nuestra guía sobre el tamaño, se indican los rangos que probamos y que recomendamos para obtener un rendimiento óptimo dada la carga esperada y los tipos de instancias de Cloud VM compatibles.
Tratamiento de Datos	Si un dato encriptado tiene información personal, ¿cuál es la disposición legal para proporcionar datos encriptados al Servicio de Agregación? ¿Puedes indicar si se garantiza que el coordinador no acceda 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 de claves y la contabilidad. Puedes encontrar algunos detalles sobre el coordinador aquí. En el caso de la contabilidad, el servicio de agregación solo comparte el ID compartido y el origen de los informes con PBS para el consumo del presupuesto. Cuando lancemos varios sitios, 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 está auditado por terceros, como se describe aquí.

API de Private Aggregation

Tema de los comentarios	Resumen	Respuesta de Chrome
Uso de API	La capacidad de los vendedores de componentes para enviar 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. Hemos analizado este problema con más detalle aquí.
Documentación	¿Cuál es el valor de épsilon que se usó en los juicios de Google?	Para la API de Private Aggregation, el valor ε especificado en una consulta del servicio de agregación corresponde al presupuesto de contribución de L1 de 2^16 que se aplica cada 10 minutos consecutivos. También hay un presupuesto de contribución de L1 de "respaldo" de 2^20 que se aplica cada 24 horas. En esencia, el parámetro de privacidad es ε cada 10 minutos y es de 16ε cada 24 horas (en lugar de 144ε). Por el momento, el servicio de agregación admite un rango de ε para las 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 volver a revisar el valor de épsilon máximo permitido con el tiempo a medida que recibimos comentarios de los verificadores y agregar funciones que permiten un uso más eficiente del presupuesto de privacidad.

Limita el seguimiento encubierto

Reducción de usuario-agente/Sugerencias de clientes de usuario-agente

No se recibieron comentarios este trimestre.

Protección de IP (anteriormente Gnatcatcher)

Tema de los comentarios	Resumen	Respuesta de Chrome
ID de resolución	Privacy Sandbox debe expresar mejor que los IDs de resolución que suelen crearse en base a IP no son sustentables para los anunciantes.	Privacy Sandbox dejó claro que nuestro objetivo es reducir el seguimiento entre sitios. Nuestras iniciativas públicas, que van más allá de las cookies, se publican tanto en privacysandbox.com como en GitHub. Nos esforzamos por reducir el seguimiento entre sitios, incluido el que se basa en direcciones IP. Sin embargo, en última instancia, depende de cada sitio web decidir si habilitar de manera proactiva el seguimiento entre sitios. En una época de mayor escrutinio sobre el cumplimiento de las normativas, es prudente que las empresas individuales comprendan las prácticas que emplean sus proveedores de servicios.
Chromecast	¿La protección de IP afectará al Chromecast o a otros dispositivos Chrome?	Actualmente, no hay planes de aplicar la protección de IP a los dispositivos Chromecast.
Lista de protección de IP	¿Se publicará la lista de terceros identificados como que pueden utilizar direcciones IP para el seguimiento entre sitios en toda la Web?	La lista se publicará una vez que se complete, 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 del seguimiento por rebote (BTM) los casos de uso de SSO para la exención?	La heurística de Chrome inhabilitará BTM. Consulta los detalles aquí.
Prueba de baja	¿Está habilitada la BTM para los sitios que participan en la prueba de baja de las 3PC?	No, BTM respeta las excepciones de cookies creadas por la prueba de baja, como se explica aquí.

Presupuesto de privacidad

Como se mencionó en la explicación de GitHub y en el sitio para desarrolladores, el presupuesto de privacidad ya no se considera de forma activa como parte de las propuestas de Privacy Sandbox.

Fortalece los límites de privacidad entre sitios

Conjuntos de sitios web relacionados (anteriormente, conjuntos propios)

Tema de los comentarios	Resumen	Respuesta de Chrome
Solicitud de función	Se puede acceder automáticamente a los CHIP o a la partición de almacenamiento a través del RWS, sin necesidad de la API de Storage Access ni la interacción del usuario.	Estamos considerando los beneficios y la viabilidad de una función que puede realizar esta función. Una consideración es una posible brecha en la interoperabilidad entre navegadores, que RWS aborda aprovechando la API de Storage Access. Por el momento, no existe un equivalente para esta funcionalidad solicitada y que otros navegadores admiten. 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 las políticas	¿Cuál es el proceso para quitar del repositorio conjuntos que no cumplen con las políticas?	Estamos trabajando para definir un proceso. Compartiremos las actualizaciones en cuanto estén disponibles.
Proceso de Aplicación de las Políticas	Existe una falta de claridad en cuanto al rol subjetivo de Google en el proceso de aplicación de RWS.	Dado que RWS es un proyecto en curso y seguimos recibiendo nuevas presentaciones, algunos aspectos del proceso y nuestros criterios se siguen consolidando. Sin embargo, estamos de acuerdo en que es importante que nuestros lineamientos de envío describan completamente nuestros requisitos para el envío de contenido. De ahora en adelante, agregaremos más detalles a ellos para evitar más ambigüedades y confusión. Nuestra intención es que el proceso de envío sea lo más técnico posible, de manera que podamos eliminar la participación humana y basarnos completamente en verificaciones automatizadas. Las relaciones públicas como esta necesitan más interacción humana porque incluyen comportamientos que no previmos, pero nos permiten identificar más áreas de automatización y formas de corregir nuestros lineamientos para evitar estos problemas en el futuro.
Uso compartido de datos	Solicitud de una función que permita a los propietarios de dominios indicar que les gustaría 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 APIs de Storage Access que permiten el acceso a la identidad autenticada después de que el usuario acepta una solicitud de permiso. Agradecemos los comentarios del ecosistema sobre cualquier caso de uso específico que no se considere posible.
Otros métodos de almacenamiento	¿La información guardada en el almacenamiento local o en el almacenamiento de sesiones también se interpretará como 3PC?	El almacenamiento local, el almacenamiento de sesiones y otras formas de almacenamiento sin cookies, cuando se usan en contextos de terceros, se particionan en Chrome desde la versión 115. Consulta esta entrada de blog para obtener más detalles.
Límite de conjuntos asociados	¿Qué les sucederá a las organizaciones que envían más de 5 dominios a pesar del límite 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. Además, ignorará los dominios restantes, como se explica aquí.
find_robots_txt	La comprobación find_robots_txt no funciona con los redireccionamientos.	Se envió una solución para resolver este problema aquí.
Gesto del usuario	Se quitó el requisito de gestos del usuario para accessStorage().	Este requisito se realizó con base en un diseño similar que se aplica en todos los navegadores principales para la API de requestStorageAccess. Invitamos a los usuarios a enviar comentarios y casos de uso adicionales en este problema de GitHub para ayudarnos a priorizar esta solicitud y habilitar los debates entre navegadores.
Gesto del usuario	¿Se requiere un gesto del usuario para otorgar permiso para el acceso al almacenamiento de terceros después de reiniciar Chrome o el SO?	Sí, pero recibimos con gusto comentarios adicionales del ecosistema sobre si hay que cambiar este comportamiento aquí.

API de Fenced Frames

Tema de los comentarios	Resumen	Respuesta de Chrome
adComponent	Falta de documentación y flexibilidad en el uso de AdComponents con marcos vallados	Queremos compartir más documentación sobre este caso de uso. Además, para agregar, los componentes de los anuncios son compatibles con marcos cercados con getNestedConfigs(), que se documenta en la especificación aquí.
(También se informó en trimestres anteriores) Renderización adComponent	Solicitud de códigos de muestra para renderizar adComponents en marco vallado.	Estamos trabajando para compartir algunos códigos de muestra aquí.
Verificación de anuncios de terceros	La función de la verificación de anuncios de terceros en el contexto de los marcos vallados requiere más detalles, en especial con respecto a la seguridad contextual o de la marca.	Actualmente, los informes de anuncios con marcos vallados permiten que las DSP envíen datos a nivel de los eventos de las impresiones y las subastas a los verificadores de anuncios de terceros para llevar a cabo la facturación y las verificaciones de seguridad de la marca posteriores al renderizado.
Anuncios Expandibles	Solicitud para admitir anuncios expandibles.	Si el anuncio necesita cambiar entre dos tamaños con la misma relación de aspecto y no hay una diferencia funcional entre ambos (solo el tamaño), la herramienta de incorporación podría cambiar el tamaño del marco vallado con el segundo tamaño del anuncio y el navegador ajustará la escala del elemento según corresponda.
(También se registraron en trimestres anteriores) Compatibilidad con inventario nativo y de video	¿Los marcos cercados son compatibles con el inventario nativo y de video?	Nuestra respuesta es similar a la de los trimestres anteriores: La API de PA admite el procesamiento de videos a través de 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 vallados, y esta es una de las razones por las que decidimos rechazar la aplicación de esta clase de marcos para 2026. Esto significa que, si un socio decide aplicar de manera forzosa los Fotogramas cercados ahora, no podrá utilizar los anuncios nativos ni de video.
Consejo asesor	Solicita la creación de un consejo asesor de proveedores de anuncios nativos para garantizar que las implementaciones de marcos vallados sigan los estándares de la industria.	El uso de marcos cercados no es necesario en la API de PA antes de 2026. Este tiempo adicional nos permite seguir trabajando con la industria para diseñar e implementar la asistencia para una gama más amplia de casos de uso fundamentales. Anteriormente, ya dijimos que mejoraremos la función Fenced Frames antes de su requisito de mantener la compatibilidad con los anuncios nativos y de video con la API de PA. De acuerdo con nuestros compromisos, nos comunicaremos con la CMA y también la informaremos de esos cambios, y seguiremos recibiendo comentarios del ecosistema antes de requerir Marcos vallados. Nuestro Modelo de interacción del ecosistema en el 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 informó en trimestres anteriores) Diferencia de tamaño entre plataformas	Informa que el tamaño del contenido que se muestra en el Marco cercado tiene un aspecto diferente en computadoras de escritorio y smartphones.	Este es un problema conocido de Chromium que estamos investigando. Enviaremos comentarios adicionales aquí.
Mejora de la API	¿Se pospuso el requisito de Marcos cercados en 2025 para que Privacy Sandbox ahora admita anuncios nativos?	Como señalamos en nuestro anuncio público sobre la aplicación de marcos vallados no antes de 2026, nos enteramos de un "esfuerzo significativo" para ajustar marcos cercados. Uno de ellos era, sin duda, los nativos, pero no era el único factor. El objetivo era proporcionar más tiempo para garantizar la preparación del ecosistema de modo de respaldar los casos de uso clave, incluidos, sin limitaciones, los anuncios nativos.

API de Shared Storage

Tema de los comentarios	Resumen	Respuesta de Chrome
Rendimiento	Los tiempos de devolución del almacenamiento compartido fuera del worklet parecen depender de la actividad en él.	Estamos analizando este resultado de la prueba aquí.
Adopción más amplia	El almacenamiento compartido debe ser un estándar de toda la industria disponible en todos los navegadores.	Apreciamos y agradecemos sus comentarios. Chrome sigue participando de forma activa en los foros del W3C, incluido WICG, para defender la propuesta, solicitar comentarios e impulsar la adopción.
Worklets de ofertas	¿Es posible leer desde el almacenamiento compartido dentro de generateBid (que ya se está ejecutando en un worklet) para aplicar la lógica empresarial o de decisión de anuncios (como la limitación de frecuencia) en función de la información de varios sitios y seleccionar un subconjunto de anuncios?	No, es imposible leer desde el almacenamiento compartido dentro de los trabajos de licitación.

CHIPS

Tema de los comentarios	Resumen	Respuesta de Chrome
Capacidad de la partición	Aclara el comportamiento cuando se excede la capacidad de 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 ya no se supere el límite. Los desarrolladores verán el encabezado Cookie actualizado en solicitudes posteriores.
Acceso a iframe de terceros	El contenido iFrame de terceros incorporado que abre una pestaña o ventana nueva al mismo sitio de terceros debe tener acceso a las mismas cookies particionadas que el iniciador.	Estamos analizando este caso de uso y recibimos comentarios adicionales del ecosistema aquí.
Cookies duplicadas	Si hay una cookie particionada y una no particionada con el mismo nombre, ¿qué par clave-valor decide enviar el navegador?	Cuando tengas dos cookies con el mismo nombre (una particionada y otra no), aparecerán ambas cookies; lamentablemente, no hay forma de diferenciar cuál es cuál. La especificación de RFC esto está disponible aquí, lo que explica que no debe confiarse en el orden en el que se envían las cookies.
Solicitud de función	Habilitar cookies particionadas de origen.	Estamos considerando esta solicitud y agradecemos que nos envíes comentarios adicionales del ecosistema aquí.

FedCM

No se recibieron comentarios este trimestre.

Combate el spam y el fraude

API de Private State Token (y otras APIs)

Tema de los comentarios	Resumen	Respuesta de Chrome
Vista web	¿Los tokens de estado privado (PST) persisten en varias WebViews del mismo dispositivo móvil (perfil)?	Cada aplicación que usa WebView tendrá un almacenamiento local diferente, lo que significa que las entidades emisoras de PST no pueden emitir tokens en WebView de una app y, luego, en otra independiente, permitir canjes de tokens. Esto también se aplica a otros tipos de datos almacenados localmente en WebViews, como las cookies. Las PST aún no están completamente disponibles en WebView. Esperamos brindar información actualizada al respecto a fines del segundo trimestre.
Nuevo tipo de token	Propuesta para un tipo de token nuevo.	Estamos muy agradecidos por esta propuesta y por la exploración continua de las solicitudes y adaptaciones de las PST, y esperamos obtener más información sobre esta propuesta en las próximas reuniones del Grupo comunitario contra el fraude en el 2o trim. de 2024.
Identificación de usuarios	¿Cómo evitar que se identifique a los usuarios en función de las PST específicas que tiene?	Esto se mitiga actualmente limitando los intentos de canje en un sitio a dos entidades emisoras, independientemente de si hay tokens disponibles de esa entidad emisora. Debes considerar una entidad emisora para el límite incluso si no hay tokens disponibles, ya que, de lo contrario, el sitio podría iterar a través de todas las entidades emisoras hasta que alcance una coincidencia positiva.
Registro	¿Durante cuánto tiempo se necesitará el registro de PST?	En el futuro cercano, se seguirá solicitando un registro, como se explica con más detalle aquí.
Compatibilidad con otros navegadores Chromium	¿Se admitirá el registro de entidad emisora de PST para otros navegadores basados en Chromium mediante el repositorio del registro de entidades emisoras 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 agregan una compatibilidad más completa con la API, necesitarán establecer un proceso para obtener los compromisos clave para el cliente, ya sea a través de un método similar al de actualizador de componentes o de algún otro método. Esto se aborda con más detalle aquí.