El proceso de Cookie Matching explicado

Algunos básicos sobre las Cookies

Como todos sabemos la cookie es el identificador elemental en el mundo de internet, al menos en esa parte del mundo digital a la que accedemos mediante un navegador. A través de las cookies podemos identificar a los usuarios cuando visitan nuestro sitio web, volver a identificarles para hacer acciones de retargeting cuando navegan por cualquier otro sitio o fijar un número máximo de impactos para una campaña (frecuencia).

Pongamos que nuestro sitio web es nosotros.com, cuando el navegador del usuario hace una petición HTTP (HTTP request) a un contenido alojado en nuestro servidor podemos insertar una cookie en una carpeta del ordenador del usuario. Esta cookie es básicamente un identificador que se asocia con un ordenador y un navegador y no con una persona, hay que tener claro que las cookies no guardan información personal del usuario. La próxima vez que el usuario visite nosotros.com podremos consultar si tiene una cookie nuestra en su ordenador y, de esta manera, saber que es la segunda vez que nos visita a través de ese ordenador/navegador.

En sus orígenes, a principios de los 90, las cookies se concibieron como un elemento con el que poder persistir cierta parte de la experiencia de compra de un usuario a lo largo de una sesión: su cesta de la compra. Sin embargo hoy son la base sobre la que pivota todo el ecosistema de datos en la publicidad online.

Es importante entender que una cookie sólo se puede leer desde el dominio que la creo, siguiendo con el ejemplo anterior una cookie creada en la visita de un usuario a nosotros.com no puede ser leída por ElPais.com si el usuario lo visitase a posteriori. Esta característica tiene su origen en un principio de seguridad y privacidad, pero se convierte en un problema cuando queremos tratar de identificar en nuestro DSP (anunciante), o desde nuestro DMP (también de anunciante), a un usuario para el que el SSP (soporte) tiene una impresión disponible. Si no podemos saber qué información tenemos para establecer el valor de ese usuario ¿cómo vamos a definir nuestra puja para esa impresión en un proceso de Real-Time-Bidding (RTB)? es evidente que hay que buscar una forma en que las distintas plataformas puedan entenderse.

Qué es el Cookie Syncing

Para que diferentes plataformas puedan intercambiar datos para conectar sus usuarios hace falta que un proceso construya la relación entre los identificadores de ambas plataformas. Al proceso para hacer el match entre ambos identificadores se le denomina sincronización de cookies o cookie syncing (o cookie matching) en inglés.

Probablemente el nombre de Cookie Syncing no sea el más apropiado si tenemos en cuenta que lo que realmente se intercambia es un identificador hasheado a partir de la cookie y no el valor real de la cookie. Durante el proceso de intercambio de datos entre las plataformas tiene lugar un proceso en el que se transforma la cookie a través de una función que se llama (atención aquí viene el momentazo friki del post) collision-resistant one-way hash function. Esta función transforma cada cookie en un identificador único en un proceso que no se puede revertir, es decir, no hay manera de decodificar el hash del identificador único para obtener el valor de la cookie.

Ese identificador es precisamente el elemento que, como veremos a continuación, se utiliza para construir una mapeo entre los identificadores del Ad Exchange y los del anunciante. La relación entre los identificadores de las diferentes plataformas se guarda en una tabla que recibe el original nombre de matching table y que se parecería a algo como esto:

El proceso de Cookie Matching con Adx de Doubleclick

Es evidente que diferentes plataformas eligen maneras ligeramente diferentes de construir este proceso se sincronización, por ejemplo donde y quién mantiene la Match Table . Para este ejemplo voy a explicar como lo hace Doubleclick y el caso de uso voy a elegir alguien que acaba de borrar las cookies en su navegador. El siguiente gráfico resume el proceso que ocurre entre las diferentes partes del ecosistema:

1. El usuario visita ElPais.com y al cargarse la página se realiza un petición a DFP de un anuncio para servir en la página.
2. El Ad Exchange lanza una Bid Request a una serie de DSPs para subastar la impresión entre los bidders disponibles
3. Nuestro DSP responderá a la petición con una puja al Ad Exchange, el Exchange evalúa las pujas recibidas de los diferentes DSPs y establece un ganador, en este caso nosotros. Nuestro DSP responde con un anuncio y un pixel especial, match tag, que será el protagonista de la conexión de identificadores.
4. A continuación el Exchange servirá la pieza en ElPais.com junto con el pixel, en ese momento instala una cookie en el navegador del usuario.
5. El pixel de macheo (match tag) hace una llamada al servicio de macheo del Exchange. El servicio lee la cookie instalada en el paso anterior y procede a generar un identificador, que en el caso de Google se recoge en la variable `google_user_id`
6. El navegador carga la URL del DSP en la que el google_user_id viaja como un parámetro de la URL , a continuación genera una cookie y guarda en la Match Table la relación entre la cookie que acaba de generar y el identificador que le ha compartido Google. A esta parte del  proceso normalmente se le conoce como Piggybacking
7. El DSP responde con un pixel transparente de tamaño 1×1 pixeles  y coloca la cookie que acaba de generar en el ordenador del usuario.

DoubleClick sólo permite realizar el proceso de cookie matching con el bidder que ha ganado la impresión en la subasta, sin embargo otros players del mercado permiten que todos los bidders puedan realizar el cookie matching en cada impresión. Como consecuencia el sistema de Google tienen unas tasas de Match Rate (el porcentaje de IDs sincronizados desde las dos partes) más bajas que otros sistemas.

Debugging un proceso de Cookie Matching

A continuación voy a mostrar el detalle de una parte del proceso entre las llamadas (request) y las respuesta (response) con el pixel en el protocolo HTTP donde se muestra un ejemplo del proceso de intercambio de IDs en un cookie matching de DoubleClick con AppNexus en un ejemplo real de ElPais.com.

En la llamada por el método GET al pixel de macheo podemos ver que Google está enviando dos parámetros, el `google_nid` que identifica al comprador (network ID, en este caso appnexus1) y el `google_hm` que contiene información que el comprador quiere almacenar en la tabla de macheo (match table). A continuación podemos ver la respuesta:

Podemos ver que la respuesta es una redirección 302 a adx.adnx.com en la que viajan varios parámetros, entre ellos podemos identificar el `google_gid` que se corresponde con el valor del identificador de Google con el que se tiene que establecer el match. Adicionalmente podemos ver que incluye un parámetro adicional `google_ver` que se utiliza para indicar la versión de la cookie.