Chrome Privateness Sandbox de Google tiene como objetivo ofrecer una alternativa para un futuro sin cookies, basada en principios de privacidad definidos por el equipo de Chrome, con capacidades de navegador para admitir publicidad digital.
Sin embargo, es imposible reemplazar con un solo salto gigante todo lo que se ha desarrollado durante los últimos 20 años para respaldar la publicidad en línea. Y seamos realistas, algunos casos de uso de publicidad deberían quedar en el pasado.
Pero, por audaz y ambicioso que sea Privateness Sandbox, se está implementando con mucha confusión y ambigüedad. Y hay muchas preguntas sin respuesta sobre cómo funcionará. 
Privacy Sandbox no es un reemplazo 1:1 para 3Laptop
Como dijo Anthony Chávez, vicepresidente de gestión de productos de Privacy Sandbox, dijo recientemente“No intentamos proporcionar reemplazos uno por uno para las cookies y los identificadores entre sitios. Punto final”.
En cambio, Privacy Sandbox es un paradigma completamente nuevo. Su objetivo es reconstruir un servidor de anuncios y un intercambio de anuncios en el navegador, junto con varias otras restricciones.
Google introdujo dos conjuntos de API para respaldar la publicidad digital. Un conjunto de API es para mostrar anuncios relevantes: Topics es para el comportamiento del usuario observado por el navegador, y Shielded Audience API (PAAPI) proporciona capacidades para que los compradores configuren y se dirijan a segmentos de audiencia. El otro conjunto de API es un entorno de ejecución confiable (TEE) para la medición y atribución de anuncios y funciones de soporte para la privacidad.
El producto resultante es una multifecta de restricciones basadas en la privacidad. sobre editores, vendedores y compradores. Esto requiere que la industria presione el botón de reinicio para necesidades comerciales críticas como facturación, informes, optimización de la inversión publicitaria y ciclos de retroalimentación en la toma de decisiones.
La semana pasada, Google lanzó una respuesta hacia Las preocupaciones de IAB Tech Lab sobre si ciertos casos de uso de publicidad son compatibles con Privacy Sandbox. El grupo de trabajo de IAB Tech Lab Privacy Sandbox está considerando la respuesta de Google junto con todas las demás respuestas que llegan durante nuestro período de comentarios.
Pero hay muchas cosas sobre el nuevo paradigma que actualmente no entendemos.
1. ¿Qué es una característica provisional y cuál es el estado final? Privateness Sandbox incluye características provisionales con las que se espera que la industria trabaje ahora, pero hay innumerables estados finales poco claros y detalles sin resolver sobre cómo funcionarán las subastas. ¿Son transparentes? ¿Las capacidades disponibles hoy estarán garantizadas en iteraciones futuras? La incertidumbre dificulta comprometerse con nuevas inversiones.
Suscribir
AdExchanger diario
Reciba el resumen de nuestros editores en su bandeja de entrada todos los días de la semana.
2. Sin garantía comercial ni contrato por parte de Google. Privacy Sandbox tiene como objetivo asumir funciones comerciales críticas, como realizar subastas en tiempo serious, publicación de anuncios e informes. Pero ¿cuál es el contrato de Google con compradores y vendedores? Si algo deja de funcionar o no funciona como se esperaba, ¿quién es responsable?
Esto es computer software. Y como todo software package, no se trata de si se introduce un error, sino de cuándo. A diferencia de un error de software del lado del servidor, un mistake de PAAPI es mucho más difícil de revertir de inmediato.
3. Necesitaremos un conjunto de tecnología para Privacy Sandbox y otro para OpenRTB, lo que fragmentará aún más Net. Por ejemplo, los marcos vallados son parte integral de Privateness Sandbox y se requieren para su uso con PAAPI, pero coexistirán con los iframes.
En el caso de ganar una subasta PAAPI, el anuncio debe mostrarse utilizando un marco cercado. Pero una subasta ganadora de ofertas en tiempo real requiere que el anuncio se muestre mediante un iframe. Eso significa que los anunciantes tendrán que crear sus anuncios con dos instrumentos distintos de medición y atribución. Esto no escala.
4. Facturación confiable. Privateness Sandbox cambia la medición de datos a nivel de evento a informes agregados y retrasados a través de un TEE, pero no proporciona una vía para la acreditación del MRC ni de ningún otro auditor.
Se agregará ruido (una cantidad aleatoria de datos) a los informes resumidos para proteger la privacidad del usuario. Pero ¿cuánto ruido es aceptable en los datos agregados para la industria o para la acreditación del MRC?
¿Y qué pasa si una actualización del navegador restablece los datos, un mistake detiene el envío de datos o un usuario no actualiza su navegador? ¿Cuál es la garantía de que todos los datos reportados sean precisos y siempre sean reportados, especialmente cuando un usuario puede eliminar todos los datos de medición?
5. ¿Cuál será la latencia en la renderización de anuncios? Dado que Google recomienda una subasta tradicional del lado del servidor seguida de una subasta de Privateness Sandbox, ¿cuál es la latencia esperada? ¿Cuáles son los puntos de referencia, especialmente a gran escala? ¿Cómo afectarán los diferentes dispositivos y recursos informáticos disponibles para el navegador Chrome a la ejecución de subastas y a la presentación de anuncios críticos para la experiencia del usuario?
6. No todo el trabajo se puede realizar en el dispositivo. Google propone TEE para subastas e informes. Si el TEE se considera un componente necesario, ¿por qué no desarrollarlo completamente como parte de un producto mínimo viable antes de obligar a la industria a adoptar una solución que no escala? ¿Cómo se optimizarían los costos de infraestructura si operan con un proveedor de servicios en la nube distinto al proporcionado por el equipo de Chrome, o en su centro de datos regional?
Un camino a seguir
Con tanto en juego, ¿qué debería hacer Google?
- Trabaje con la industria para desarrollar métodos estandarizados e interoperables para respaldar funciones como el presupuesto y el ritmo de las campañas, la gestión de frecuencia, los cálculos de alcance y la seguridad de la marca. Recuerde: incluso las regulaciones gubernamentales establecen una excepción para funciones comerciales esenciales como la medición.
- Identifique soluciones como seguridad de marca y mitigación de fraude donde la asistencia del navegador puede proporcionar una mejor solución. Permitir que terceros utilicen las capacidades del navegador del dispositivo o los servicios TEE para realizar estas funciones para sus clientes.
- Incorporar estándares ampliamente utilizados como OpenRTB para servicios de subastas o Broad para anuncios de vídeo en servicios y diseños de TEE. Esto ahorrará a las empresas tiempo y costos al integrar las API de Privacy Sandbox.
- Desarrollar plenamente las capacidades de Privacy Sandbox que Google quiere que la industria adopte primero. Si el TEE es un requisito, entonces desarrollar completamente el producto TEE antes de pedirle a la industria que lo experimente y lo adopte. El remarketing es un caso de uso perfecto con diseños actuales, pero también necesita una solución de extremo a extremo completamente desarrollada.
- Finalmente, abra el código de Google Chrome utilizado en la ejecución de las API de Protected Viewers. Las empresas deben sentirse seguras al construir sus negocios con ese código, especialmente cuando no existe ningún contrato, garantía comercial o responsabilidad por parte de Chrome.
Cualquier producto que pretenda ser el elemento básico de la industria debe ser un sistema completo que respalde las necesidades comerciales de extremo a extremo con las garantías comerciales, contratos, requisitos fiduciarios de empresas públicas y acuerdos de nivel de servicio requeridos. Privateness Sandbox no es una excepción.
“Pensamiento basado en datos” está escrito por miembros de la comunidad de medios y contiene nuevas thoughts sobre la revolución digital en los medios.
Seguir Laboratorio tecnológico IAB y AdExchanger es LinkedIn.
Para obtener más artículos sobre Shailley Singh, haga clic aquí.
