Analítica web
Reflexiones desde el mercado español de Analítica Web

Adobe: Identificación de usuarios (AEC)

Se lee en 6 minutos

Una de las principales preocupaciones a la hora de identificar usuarios en las distintas herramientas de analítica es la posibilidad de que su visita se pueda romper. El hecho de que se rompa su visita implica, entre otras cosas, que no tenemos una visión completa de la navegación del usuario.

Pero, ¿a qué nos referimos con que una visita se rompe? Una de las formas en las que las herramientas de analítica identifican a cada usuario, es a través de un ID interno que se almacena en una cookie y que es consultado para saber si el usuario ha visitado ese sitio con anterioridad. Decimos que una visita se rompe, cuando un mismo usuario tiene varios identificadores al navegar entre activos en los cuales interesa saber que, en realidad, es el mismo usuario. Por ejemplo, si una empresa tiene varias marcas repartidas en varios dominios, puede ser interesante conocer cual fue la navegación del usuario a través de todos esos dominios de cara a analizar su comportamiento.

A lo largo de este post hablaré de unos de esos identificadores, el Adobe Experience Cloud ID, e intentaré explicar, además de su funcionamiento, cómo podemos evitar, en la medida de lo posible, esa ruptura en la visita.

El Adobe Experience Cloud ID es el ID que utiliza Adobe para identificar a un mismo usuario a través de sus propias herramientas, como Target o Adobe Analytics. Además, permite identificar a un mismo usuario entre distintos dominios. Para ello, se basa en una cookie de tercera parte fijada a “demdex.net”.

En navegadores como Chrome, que acepta cookies de tercera parte, el usuario es identificado de forma correcta entre los distintos dominios. Pero si nos vamos a navegadores como Safari, que no acepta cookies de tercera, al realizar únicamente la implementación del Adobe Experience Cloud ID sin tener en cuenta nada más, nos encontraremos que un mismo usuario tiene distinto identificador en dos dominios distintos que envían a la misma cuenta de Adobe. Es decir, se romperá la visita.

¿Cómo funciona el Adobe Experience Cloud ID?

Supongamos que tenemos dos dominios. En uno de ellos se venden productos de de gama alta (productoscaros.es) y en otro productos de gama baja (productosbaratos.es). Los dos dominios mandan datos al mismo grupo de informes en Adobe Analytics y tienen implementado el Adobe Experience Cloud ID. Suponiendo que el usuario está navegando con Safari y pasa del domino de productos de gama baja al dominio de productos de gama alta, un resumen de los pasos que se suceden para generar el ID sería el siguiente:

  1. El usuario entra en “productosbaratos.es”.
  2. Se realiza una petición a “demdex.net” para fijarle una cookie de tercera con la que será capaz de generar otra cookie de primera con el Adobe Experience Cloud ID.
  3. Safari no le permite crear esa cookie de tercera, y por tanto, la implementación no se puede basar en ella para crear la cookie de primera.
  4. Mediante javascript, la implementación del Adobe Experience Cloud ID, es capaz de generar un ID “aleatorio” sin basarse en la cookie de tercera y guardarlo en una cookie de primera parte fijada al dominio “productosbaratos.es”.
  5. Se realiza una petición al servidor de Adobe (“omntrdc.net”) y todos los datos se envían a Adobe identificando al usuario con el ID guardado en la cookie de primera parte fijada para el dominio “productosbaratos.es”.
  6. En visitas y hits posteriores en “productosbaratos.es” el usuario seguirá siendo identificado con ese ID.
  7. El usuario entra en “productoscaros.es”
  8. Se busca la cookie de tercera de demdex, no se encuentra y se realiza una petición a “demdex.net” para fijarle al usuario una cookie de tercera con la que será capaz de generar otra cookie de primera con el Adobe Experience Cloud ID.
  9. Safari no le permite crear esa cookie de tercera, y por tanto, la implementación no se puede basar en ella para crear la cookie de primera.
  10. Mediante javascript, la implementación del Adobe Experience Cloud ID es capaz de generar un ID “aleatorio” sin basarse en la cookie de tercera y guardarlo en una cookie de primera parte fijada al dominio “productoscaros.es”. Este ID es distinto al generado en la cookie de primera parte para el dominio de “productosbaratos.es”.
  11. Se realiza una petición al servidor de Adobe (“omntrdc.net”) y todos los datos se envían a Adobe identificando al usuario con el ID guardado en la cookie de primera parte fijada para el dominio “productoscaros.es”.

Consecuencia: un usuario que ha realizado una visita, a ojos de Adobe Analytics, son dos usuarios que han realizado dos visitas distintas.

Esta es la problemática que nos encontramos en el navegador de Safari y, aunque la realidad es esta, sí que podemos minimizar el daño haciendo uso de un registro CNAME. Un CNAME permite asignar un alias a un dominio canónico. Un antifaz que podemos ponerle al dominio del servidor de Adobe y que, gracias a esta pequeña “trampa”, permite “engañar” a Safari para que no nos rompa el usuario y la visita.

Funcionamiento del Adobe Experience Cloud ID (usando CNAME)

Supongamos los dominios anteriormente descritos y, ahora, vamos a ponerle un alias al servidor de Adobe Analytics a donde se envían los datos (“omntrdc.net”). El alias será “m.productosbaratos.es”. Esto quiere decir que ahora las peticiones a Adobe se realizarán a “m.productosbaratos.es”. Si volvemos a realizar la visita anterior, ahora ocurriría lo siguiente:

  1. El usuario entra en “productosbaratos.es”.
  2. Se realiza una petición a “demdex.net” para fijarle una cookie de tercera con la que será capaz de generar otra cookie de primera con el Adobe Experience Cloud ID.
  3. Safari no le permite crear esa cookie de tercera, y por tanto, la implementación no se puede basar en ella para crear la cookie de primera.
  4. Mediante javascript, la implementación del Adobe Experience Cloud ID, es capaz de generar un ID “aleatorio” sin basarse en la cookie de tercera y guardarlo en una cookie de primera parte fijada al dominio “productosbaratos.es”.
  5. Se realiza una petición al servidor de Adobe (“m.productosbaratos.es”) y todos los datos se envían a Adobe identificando al usuario con el ID guardado en la cookie de primera parte fijada para el dominio “productosbaratos.es”.
  6. En visitas y hits posteriores en “productosbaratos.es” el usuario seguirá siendo identificado con ese ID.
  7. El usuario entra en “productoscaros.es”
  8. Se busca la cookie de tercera de demdex, no se encuentra y se realiza una petición a “demdex.net” para fijarle al usuario una cookie de tercera con la que será capaz de generar otra cookie de primera con el Adobe Experience Cloud ID.
  9. Safari no le permite crear esa cookie de tercera, y por tanto, la implementación no se puede basar en ella para crear la cookie de primera. No se crea.
  10. Mediante javascript, la implementación del Adobe Experience Cloud ID es capaz de generar un ID “aleatorio” sin basarse en la cookie de tercera y guardarlo en una cookie de primera parte fijada a “productoscaros.es”. Este ID es distinto al generado en la cookie de primera parte para el dominio de “productosbaratos.es”.
  11. Se realiza una petición al servidor de Adobe (“m.productosbaratos.es”) y en este punto está el truco. Por defecto, Safari envía todas las cookies del dominio al que se hace la petición, en este caso “productosbaratos.es”, independientemente de si para el dominio actual son consideradas de tercera. Nosotros tenemos una cookie fijada a ese dominio, que fue creada cuando visitamos “productosbaratos.es”, y es la que guarda el ID con el que fuimos identificados en “productosbaratos.es”. Finalmente, a pesar de tener una cookie de primera fijada al dominio de “productoscaros.es”, la implementación del Adobe Experience Cloud ID es capaz de asociar todos los datos que se envían a Adobe Analytics al usuario con el ID guardado en la cookie de “productosbaratos.es”.

Consecuencia: el usuario no se rompe y, a ojos de Adobe Analytics, será un usuario que ha estado en dos dominios en la misma visita.

En este ejemplo, si el usuario hiciera la visita a la inversa, es decir, entrando primero en “productoscaros.es” y después en ”productosbaratos.es”, la visita y el usuario se romperían, pero una vez que vuelva a “productoscaros.es” ya será identificado con el mismo ID en ambos dominios. Por ello es importante que a la hora de usar el CNAME, se realice sobre el dominio que sepamos que va a recibir más tráfico de usuarios y minimizar así el número de visitas rotas.

Espero que sigáis conscientes después de leer este laberinto de cookies y peticiones, y que os ayude a tomar decisiones a la hora de realizar implementaciones del Adobe Experience Cloud ID 😉

Escribe tu comentario

seis − uno =

Navegar