#3.3: Identity War
Capítulo 3. Google Privacy Sandbox
Booooooommmmba! Provocando el mismo efecto que el inicio de la canción de King África, al menos a mí, todo el sector digital se sobresaltó por la publicación del equipo de ingeniería de Google Chrome en agosto de 2019, donde anunciaban su intención de eliminar todas las cookies de terceros en un plazo de dos años a través de un programa llamado Privacy Sandbox.
Es cierto que la noticia no hacía otra cosa que consolidar una tendencia que ya venía produciéndose. Como hemos comentado en anteriores posts tanto Safari como Firefox ya habían comenzado con las restricciones de cookies para dotar de mayor seguridad a los usuarios. Pero, es lo que tiene romper con lo establecido, que nunca deja de sorprenderte cuando presencias el golpe definitivo.
Antes de empezar a revolcarnos en el barro y os aviso que hoy lo haremos mucho, es importante señalar que esta actualización programada de Chrome no tiene la intención de afectar a las cookies de origen -first-party cookies-.
Cookieless by Google. Todos podemos jugar, pero en su cajón de arena
La propuesta de Google está compuesta por una serie de APIs (como soy majo os regalo un enlace por si no sabéis lo que es un API o queréis refrescar la memoria) con el objetivo de habilitar al navegador del usuario que actúe en su nombre, utilizando su dispositivo, y, de ese modo, proteger toda la información asociada a la identificación de ese usuario mientras navega.
Pregunta de examen. ¿A qué os suena? Tic, tac, tic, tac… ¡Premio! Un perrito piloto para los que habéis dicho Edge Computing. Como hablamos en el anterior capítulo, la propuesta de Google se basa en la computación en el dispositivo.
Las APIs de Privacy Sandbox permiten casos de uso como la personalización de anuncios o la medición de las conversiones, pero siempre teniendo en cuenta no revelar información privada y personal a nivel individual. De hecho, en términos de ingeniería, un sandbox es un entorno protegido. Y, de hecho, un principio clave del Privacy Sandbox es que la información personal de un usuario debe protegerse y no compartirse de una manera que permita identificar al usuario a través de distintos sitios web.
Si algo debemos avalar de Google con esta nueva propuesta para la industria Adtech cookieless, es que todas las propuestas las está sometiendo en un entorno colaborativo para promover el debate técnico y a nivel de casos de usos concretos. Otra cosa es lo que acabe haciendo cuando el plazo llegue a su fin. Pero de momento, no tenéis excusa. Si queréis aportar vuestro grano de arena a este sandbox (un aplauso por ese juego de palabras al más puro estilo gongoriano), ya estáis entrando en los distintos hilos creados en GitHub y que están resumidos en esta wiki.
De cara a poder ayudaros con algo de orden en la ingente documentación que encontraréis, a continuación listamos las principales propuestas de Google Privacy Sandbox:
Privacy Model for the Web. Se pretende establecer el rango de actividad web a través del cual un usuario pueda permitir al navegador que determinados sitios conozcan algunos datos que tracen su identidad. También analizar las formas en que la información puede moverse a través de los límites de la identidad sin comprometer esa separación.
Privacy Budget. El objetivo es limitar la cantidad total de datos potencialmente identificables a los que pueden acceder los sitios. Así mismo, quiere hacer que el acceso a datos potencialmente identificables sea medible.
Willful IP Blindness. Con esta propuesta la idea es permitir que los sitios queden 'ciegos' a las direcciones IP para evitar consumir un elemento que introducen y que llaman privacy budget.
Trust Token API. Aquí se trata de permitir que un origen de confianza para un usuario emita tokens criptográficos para ser almacenados por el navegador y que puedan ser utilizados en otros contextos y así evaluar la autenticidad del usuario.
First-Party Sets. Habilitar que los nombres de dominio relacionados que pertenecen a la misma entidad, como dominios distintos de una misma marca, se declaren pertenecientes y por lo tanto se traten como first-party.
Aggregated Reporting. Con esta solución se quieren proporcionar mecanismos de preservación de la privacidad para admitir casos de uso muy típicos en la actualidad, como la conversión post-impression.
Click Through Conversion Measurement Event-Level. La idea es proporcionar medición de conversión de clics pero preservando la privacidad.
Federated Learning of Cohorts. En este punto, se propone que el navegador agrupe a muchos usuarios con historiales de navegación similares en un grupo (o "flock"). De ese modo, los anunciantes pueden personalizar anuncios para este grupo grande, pero no pueden reconocer a las personas individuales en este.
TURTLEDOVE. Habilitaría un tipo de 'subasta' en el dispositivo con el fin de personalizar los anuncios más relevantes en función de un interés previo del usuario.
El demonio está en los detalles
Con el objetivo de aterrizar la propuesta de Google en casos de uso concretos y de sobra conocidos por todos los profesionales de la industria Adtech, hablaremos de cómo cambiaría Privacy Sandbox los escenarios de medición y personalización.
Al ser propuestas todavía vivas y no confirmadas intentaré dar todos los detalles que pueda, aunque me temo que os quedará algún “pero” o incluso un “WTF” en la cabeza. Sí es así, no dudéis en preguntar en los comentarios.
Medición de conversiones
En la propuesta de Google de Click Through Conversion Measurement Event-Level, hay dos enfoques basado en que la información sobre las impresiones y conversiones de anuncios permanece dentro del navegador, y donde solo se ofrece información de formas muy controladas, en aras de una mayor privacidad, para que esa información llegue a los anunciantes:
Click Through Conversion Measurement Event-Level donde se permite a los anunciantes determinar qué clics fueron los que más tarde acabaron en conversión.
Aggregated Reporting que agrega datos de navegación para múltiples sites y múltiples usuarios en un solo informe. Preserva la privacidad porque solo permite información agregada.
Aunque no solo Google trabaja en esta línea, ya que en el tablero también tenemos soluciones que aportan otras compañías sobre cómo serán los nuevos escenarios de medición. Aquí os listo algunas:
Facebook's Cross-Browser Anonymous Conversion Reporting.
Apple's Ad Click Attribution API.
Brave's ad conversion attribution.
Si nos referimos a la solución de Click Through Conversion Measurement Event-Level, hasta ahora, solo admite la medición de conversiones post-click. La medición de conversiones post-impression aún no es compatible, debido a que estas conversiones son muy difíciles de determinar preservando la privacidad. Aunque como hemos dicho son áreas de trabajo que todavía están abiertas y en proceso.
Además, esta API se puede usar con dos tipos de links (<a>):
Links en un contexto propio (first-party), como anuncios en una red social o una página de resultados de un motor de búsqueda.
Links en un iframe de terceros (third-party), como en el sitio de un medio que utiliza una solución Adtech.
De esa forma, cuando el usuario hace clic en un anuncio, el navegador (es decir, en el dispositivo local del usuario) registra el evento, junto con la configuración de conversión y los datos de clic especificados por los atributos de Click Through Conversion Measurement Event-Level en el elemento <a>.
Posteriormente, el usuario puede visitar el sitio web del anunciante y realizar una acción que dicho anunciante o su proveedor de tecnología publicitaria categorizan como conversión (una suscripción, una compra, etc.). Si esto sucede, el navegador del usuario hace coincidir el clic en el anuncio y el evento de conversión.
El navegador finalmente programa un informe de conversión que se enviará al endpoint (para los menos duchos en tecnología, una URL que recibe o devuelve información de una API web) especificado en los atributos del elemento <a>. Este informe incluye datos sobre el clic en el anuncio que generó esta conversión, así como datos sobre la conversión.
Veámoslo más en detalle con la ayuda del pinta y colorea del sector digital, aka diagramas, y comparémoslo con el escenario actual que usa cookies de tercera parte.
FUENTE: Web.dev. https://web.dev/
Como podéis ver, en el modelo con third-party cookie, adtech.example usa la cookie como un identificador único cross-site para reconocer al usuario en todos los sitios web. Además, adtech.example puede acceder a datos detallados sobre clics -incluso tiempo de visualización o conversiones concretas- y, así, vincularlos.
Por consiguiente, adtech.example puede rastrear el comportamiento de un usuario en distintos sites entre una visualización -impresión-, un clic y una conversión.
El Ad ID del modelo con cookies y el Click ID del caso que usa Event Conversion Measurement API (es el nombre resumido de Click Through Conversion Measurement Event-Level), son identificadores que permiten la asignación de una serie de datos. En este segundo escenario, se refiere solo a clic porque únicamente está cubierto en este API de medición las conversiones click-through.
Así que, sin una alternativa a las cookies de terceros, no tendremos la capacidad técnica de atribución que está presente actualmente en la industria AdTech. A lo sumo, si adtech.example estuviera presente tanto en el sitio del publisher (medio) como en el del anunciante, se podría acceder a los datos de click-time o conversion-time, pero no se podrían vincular entre sí.
Es decir, como veis, siempre se prima la conservación de la privacidad del usuario por encima de todo y, en contra, los anunciantes pierden datos muy valiosos para optimizar la inversión publicitaria. Por esto último, en mi opinión, la propuesta de Event Conversion Measurement API debe continuar avanzando.
Personalización de anuncios
Los anuncios personalizados, siempre y cuando sea de forma relevante, son más favorables para los usuarios y más rentables para los publishers. Las herramientas de personalización de anuncios de third-party hacen que el espacio publicitario tenga más valor para los anunciantes, lo que a su vez aumenta los ingresos de los sitios web gracias a la publicidad y, de esa forma, permite que se cree y publique contenido gratuito en Internet. Vamos, como en el Rey León. Un ciclo sin fin que ahora se rompe.
Hay muchas formas de hacer que los anuncios sean relevantes para el usuario, A continuación, se mencionan algunas:
First-party data. Se muestran anuncios personalizado de temas sobre los que un usuario ha informado (ejemplo mediante un formulario o porque está presente ese interés en el CRM) a un sitio online o también por el contenido que un usuario ha visto anteriormente gracia a su historial de navegación.
Contextual. Se elige donde mostrar los anuncios en función del contenido del sitio. Si tengo una sección de coches deportivos de lujo, podría mostrar anuncios de Ferrari.
Remarketing: Se muestran anuncios a los usuarios que han visitado un sitio web, cuando están navegando en otros sitios. ¿A quién no le ha perseguido algún producto que incluyó en el carrito de Amazon por toda la red?
Interest-based: Se seleccionan anuncios basados en el historial de navegación del usuario. Por ejemplo, "Muestre este anuncio a los usuarios cuyo comportamiento de navegación indique que podrían estar interesados en viajar a Mallorca".
Los casos de fist-party data y la selección de anuncios contextuales se pueden hacer, normalmente, sin cookies de tercera parte por lo que no se verían impactados en el futuro cookieless que vislumbra Google.
En cambio, el caso de uso de remarketing generalmente se realiza utilizando cookies u otras formas de seguimiento de usuarios entre sites. Asimismo, el método de interest-based también suele basarse en cookies para rastrear el comportamiento del usuario en tantos sitios web como sea posible.
Por lo que como estáis imaginando, Google Privacy Sandbox ha propuesto dos alternativas para el remarketing y para interest-based. Y que son:
TURTLEDOVE para remarketing. Este método permite que la "subasta" final de anuncios elija los anuncios más relevantes para moverlos al navegador. La API aprovecha la información que solo se almacena en el navegador, sobre los anunciantes en los que el usuario había expresado previamente un interés, junto con información sobre la página actual. Se envían dos solicitudes de anuncios: una para recuperar un anuncio basado en datos contextuales y otra para recuperar un anuncio basado en un interés definido por el anunciante. El navegador tiene la responsabilidad de garantizar que estas solicitudes sean independientes y no estén correlacionadas, de modo que no puedan vincularse entre sí para que una red publicitaria sepa que las solicitudes provienen de la misma persona.
FLoC para audiencias interest-based. La propuesta genera grupos de personas similares, conocidas como cohortes o "flocks". Los datos se generan localmente en el navegador del usuario, no por un tercero. El navegador comparte los datos generados del grupo o cohorte, de tal modo que no se pueden utilizar para identificar o rastrear usuarios individuales. Esto permite a las empresas seleccionar anuncios basados en el comportamiento de personas con un comportamiento de navegación similar, mientras se preserva la privacidad.
Últimos movimientos. Entre pájaros anda el juego
Tal como hemos descrito anteriormente, todas las propuestas que está haciendo Google son elementos vivos que la industria puede recoger para enmendar, evolucionar o deconstruirlas. De hecho, recientemente, hemos sido testigos de dos movimientos interesantes que toman de base Privacy Sandbox. En concreto:
SPARROW
En mayo de este año, la empresa francesa Criteo, lanzó una propuesta en respuesta a TURTLEDOVE de Chrome. Continuando con los nombres de aves (turtledove significa tórtola), Criteo nombró a su propuesta SPARROW, como el acrónimo de Secure Private Advertising Remotely Run On Webserver y que significa gorrión (mira que les gusta el juego).
Si bien TURTLEDOVE propone que toda la segmentación basada en intereses a través de grupos sucedería en el navegador y no permitirá, por ejemplo, frequency capping o A/B testing, el concepto detrás de SPARROW es mover esos procesos a un servidor de terceros dedicado (third-party server), conocido como gatekeeper.
De ese modo, las empresas de AdTech como los DSP y SSP, podrían añadir modelos y lógica de bidding y subasta a ese third-party server.
Sin duda, SPARROV es una evolución interesante, pero rápidamente surgieron dos preguntas en forma de desafíos que son necesarios aclarar antes de la adopción por parte de la industria:
¿Quién será el gatekeeper? Lo que está claro, independientemente de que habría muchas postulaciones a ese cargo (muchas de ellas seguro con gran interés), es que tendría que ser una organización independiente y que no tuviera intereses comerciales. Algunas voces hablan de una entidad como la IAB.
¿Y qué hay del mandamiento de la privacidad? Con la propuesta de SPARROV existen más posibilidades de que los datos que almacene ese servidor de terceros, el gatekeeper, puedan ser utilizados con la finalidad de identificar usuarios y, por ende, existir riesgo de fuga o venta de datos. Para superar este desafío, el propio Criteo propone que el gatekeeper esté sometido a auditorías periódicas por parte de las Data Protection Authorities (DPAs), así como la creación de API públicas para que la industria pueda asegurarse de que los datos se están gestionando siguiendo los máximos estándares de privacidad.
Dovekey
Muy poco tiempo después, más concretamente en septiembre de 2020, varios equipos de Google lanzaron una propuesta recogiendo el guante lanzado por Criteo con su propuesta SPARROW y que han bautizado Dovekey (paloma en castellano).
Dovekey está diseñado para ser una mejora de SPARROW que soluciona algunas de sus deficiencias o desafíos que hemos comentado antes. La característica principal de Dovekey es la introducción de un servidor third-party KEY (KV), que se utilizará para manejar los procesos de licitación y subasta de TURTLEDOVE.
Este KV Server que podría ser ejecutado por una empresa tercera (no solo Google), recibiría una “key” (como una señal de anuncio contextual sumado a un grupo de interés) y devolvería un valor (una puja).
Dovekey solo cubre los elementos de bidding y subasta de la compra de anuncios para casos de uso de retargeting, pero no para casos de uso de medición.
FUENTE: GitHub: https://github.com/google/rtb-experimental/tree/master/proposals/dovekey
De hecho, este último movimiento se está interpretando como un acercamiento de posturas entre la industria Adtech y Google. A medida que Google va concretando los conceptos para un futuro sin cookies (a veces de forma un poco desestructurada), los distintos stakeholders de la publicidad digital se remueven. Como resultado de una de esas sacudidas, las asociaciones líderes como ANA, 4A’s e IAB formaron en agosto el Partnership for Responsible Addressable Media (PRAM).
Google, con su lado oscuro de la fuerza, quiere dejar de ser el centro de atención de políticas antimonopolio (ya que se juega muchos millones de $ en sanciones), pero al mismo tiempo también está interesado en una solución cookieless que acepte la mayor parte de la industria. Un ejemplo de lo que comento lo podéis ver en la reciente propuesta que ha hecho Google en la World Wide Web Consortium (W3C).
And the winner is…
Desde mi punto de vista el ganador de la Identity War será Google Privacy Sandbox, al menos a corto plazo teniendo en cuenta que el reloj ya está descontado el tiempo para el fin de las third-party cookies y la publicidad online tal como la conocíamos.
Y aunque nos pueda alegrar, disgustar o dar igual el reloj que marca los tiempos es de arena. De la arena que está llenando el Google Privacy Sandbox.
¡Ojo! No creo que sea la única solución en una industria Adtech sin cookies de terceros, pero sí la mayoritaria. Así que hasta el todopoderoso Google tendrá que convivir con otras soluciones que, aunque no tengan el mismo alcance, le exigirán y harán que no pueda relajarse. Aquí pienso en soluciones de Universal ID, más propuestas de Edge Computing, otros golpes en la mesa de los gigantes de Internet que quedan (los Walled Garden de Facebook y Amazon no tienen un tamaño que se pueda ignorar) y, porque no, proyectos que ni imaginamos aún.
De las grandes guerras y las crisis más severas, siempre salen las mejores iniciativas. Pero todas estas nuevas ideas deben tener un propósito bien presente: la privacidad. Los esfuerzos de privacidad se están expandiendo y evolucionando en todos los navegadores, por lo que no es de extrañar que Google Chrome haya puesto su particular pica en Flandes. Asimismo, como hemos dicho en varias ocasiones, todos los avances hacia más control y transparencia en la privacidad de los datos de los usuarios son un hecho que el mercado está demandando y la regulación exigiendo cada vez más.
Todo tiene un final y esta serie de capítulos no podía ser la excepción. Aunque si os habéis quedado con ganas de profundizar o debatir sobre un tema concreto, Madtech Soul es vuestro espacio, por lo que no dejéis escapar ni un segundo en escribir un comentario 📢