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

Quién soy y a dónde voy: Cross Device Tracking (Parte II: Adobe Analytics)

Se lee en 6 minutos

En un mundo donde el usuario es cada vez más multidispositivo (y si no os lo creéis os invito a ver este informe de comScore), analizar el customer journey se está convirtiendo en poco menos que una necesidad de cara a obtener un análisis real de cómo están funcionando nuestros diferentes activos digitales. Necesitamos saber cómo los distintos activos digitales y canales funcionan en conjunto, y cómo contribuye cada uno de ellos a la conversión. Sin embargo, esta necesidad choca, frontalmente, con las barreras que imponen las implementaciones tradicionales de las herramientas de analítica.

Device lab

Si en el anterior post sobre cross-device tracking os hablábamos del User-ID de Google Analytics, ahora es el turno de la otra gran herramienta de analítica presente en el mercado: Adobe Analytics, también conocida como SiteCatalyst. En este post os contaremos cómo funciona el cross-device tracking de Adobe Analytics, qué posibilidades nos ofrece y cómo implementarlo.

¿Quién soy para Adobe Analytics?

Al igual que Google Analytics y la mayor parte de herramientas de analítica, Adobe Analytics utiliza como principal mecanismo de identificación las cookies. Principalmente, hace uso de una cookie denominada s_vi. Esta cookie tiene una expiración a dos años y contiene un identificador único generado por los servidores de Adobe. Además, la s_vi puede ser tanto de tercera parte, cuando se usa como tracking server un dominio de Adobe, como de primera parte, cuando se hace una implementación para usar cookies de ese tipo (CNAME).

En el caso de que el usuario tenga deshabilitadas las cookies de tercera parte y no se hayan implementado cookies de primera parte, entra en juego un método de “reserva” (fallback). Originalmente, este método usaba la combinación de la dirección IP y del User Agent del usuario para identificarlo. Sin embargo, como os contaba en el anterior post, este mecanismo no es muy fiable, por lo que Adobe ideó otro método de fallback más robusto. Dicho método se basa en la creación, mediante el código en página (AppMeasurement o s_code), de un identificador único generado aleatoriamente que se almacenará en una cookie de primera parte con expiración a dos años denominada s_fid. Aunque esto es más fiable que el uso de la IP y el User Agent, es importante tener en cuenta que Adobe no garantiza que el identificador generado aleatoriamente mediante este mecanismo sea único, destacando como factores que afectan la unicidad el volumen de valores s_fid creados para el site y el número de hits concurrentes de usuarios que aterrizan en el mismo milisegundo. Por último, Adobe sigue manteniendo el método de IP y User Agent como mecanismo de identificación en caso de que el usuario no acepte ninguna clase de cookie.

¿Cómo Adobe Analytics te sigue?

Ahora que sabemos cómo nos identifica Adobe Analytics, veamos cómo nos sigue.

Cuando se produce una identificación por cookies, el seguimiento por defecto de Adobe Analytics está limitado a dispositivo y navegador: mientras el usuario use el mismo navegador dentro de un dispositivo, será el mismo visitante. De igual forma, si el usuario cambia de dispositivo o incluso de navegador, algo que es relativamente habitual a día de hoy, se convierte en varios visitantes disociados, sin ningún punto en común a ojos de la herramienta.

Aunque esta falta de asociación en la herramienta se ha venido solventando mediante el estudio e interpretación de los datos realizado por los analistas, Adobe consideró en su versión 15 de SiteCatalyst esta necesidad de unir los diferentes visitantes que conformaban un usuario multidispositivo y creó su técnica “Cross-Device Visitor Identification”, también llamada “Visitor stitching”.

El visitor stitching de Adobe Analytics está basado en alimentar, en todos los dispositivos, la variable s.visitorID con un identificador único para cada usuario. Típicamente, este identificador único se consigue tras un login o tras cualquier otra acción que permita identificar unívocamente al usuario. En el hit donde se alimenta la variable s.visitorID, la herramienta busca en su sistema otro perfil (datos de usuario) con ese mismo identificador y, en caso de existir, le asocia la información que recopile a partir de ese momento, dejando de utilizar el perfil previo y sin persistir ningún dato. Por otro lado, de no existir un perfil con ese identificador, se crea uno nuevo y comienza una nueva visita asociada a él, copiándose, además, las variables persistentes de un perfil a otro. El identificador que se asocie a la variable s.visitorID será siempre el prioritario a la hora de identificar usuarios.

s.visitorID > s_vi > s_fid > IP/User Agent

Pongamos un ejemplo para aclarar todo esto:

Un usuario llega por octava vez a un site y se alimentan la eVar1, que expira tras visita, con el valor “rojo” y la eVar2, con una expiración de dos días, con el valor “coche”. Tras esto, se registra y se alimenta la s.visitorID con un identificador único, creándose un nuevo perfil. Comenzaría entonces una nueva visita y se incrementaría en uno el número de usuarios únicos. Además, la eVar2 mantendría su valor “coche”, pero la eVar1 lo perdería al comenzar la nueva visita. Esto se puede ver en la siguiente tabla, donde cada fila representa un hit.

persistencia1
Al día siguiente, el mismo usuario llega al site desde otro dispositivo, por lo que un nuevo visitante único es generado (nuevo valor de s_vi), y se alimentan las variables eVar1 con el valor “azul” y la eVar2 con el valor “moto”. De nuevo se registra, por lo que la visita desde ese momento en adelante se asocia al perfil creado en la visita del día anterior sin incrementarse el número de visitantes únicos. Los datos recogidos hasta entonces no persisten, sin embargo, sí persisten los datos asociados a ese perfil, como es el caso del valor “coche” del día anterior que tenía expiración a dos días.

persistencia2
Visto esto, las posibilidades que ofrece la implementación de la variable s.visitorID son muchas, permitiendo mediante la unificación del visitante seguir su traza a lo largo de los diversos dispositivos, crear segmentos avanzados que hagan foco en usuarios multidispositivo para comprender cómo funcionan tus activos en conjunto, etc. Además de todo esto, también permite, como es de esperar, identificar el verdadero canal de primer toque de un usuario a través de los diferentes dispositivos, así como los diferentes canales que contribuyen a la conversión.

¿Y ahora qué? Marketing Cloud Visitor ID

Adobe, en su Marketing Cloud (si no os acordáis de qué es, podéis leer este post), ha modificado el proceso de generación de IDs mediante la introducción del “Marketing Cloud Visitor ID Service”. Este método se ejecuta antes que el código AppMeasurement y obtiene los IDs de Marketing Cloud y de Analytics para que estén disponibles cuando el código de AppMeasurement esté cargado. El principal cambio que introduce es que la cookie para el visitor ID se crea ahora usando JavaScript en lugar de la cabecera HTTP, lo que resulta que la cookie generada es de primera parte.

Una vez configurado el Marketing Cloud Visitor ID Service, el proceso funciona de la siguiente manera en los casos en los que no se esté usando un CNAME:

1º) Cuando un usuario llega al site, el mecanismo del visitorID busca una cookie de nombre AMCV_###@AdobeOrg. Esta cookie es la propia del Marketing Cloud y es la que contiene todos los identificadores de visitante. Si existe, el ID de esa cookie se utiliza como identificador de Marketing Cloud. En caso de que no exista, el servicio de visitor ID hace una petición a los servidores de Marketing Cloud (dpm.demdex.net) para obtener un identificador único de Marketing Cloud, que se almacenará en la cookie y se usará siempre para ese usuario, incluyéndose en los hits en el parámetro “mid”.

2º) Se busca un Analytics ID en la cookie AMCV_###@AdobeOrg, usándolo si está presente. En caso de que no lo esté, el servicio de Visitor ID hace una petición al data collection server del site para comprobar si existe un identificador de Analytics antiguo (cookie s_vi). En caso de que el usuario tenga una cookie s_vi, su valor se almacena como identificador de Analytics y se envía en los hits como parámetro “aid”. En caso de que la cookie s_vi no exista, el identificador de Analytics se configura como una cadena vacía, usándose el Marketing Cloud ID como identificador para analítica y no alimentándose el parámetro “aid”.

Además, el Marketing Cloud Visitor ID Service permite seguir alimentando la variable s.visitorID para identificar a los usuarios entre dispositivos, en cuyo caso seguirá siendo el primer mecanismo de identificación, quedando el orden de este modo:

s.visitorID > s_vi > AMCV_  creada por Marketing Cloud Visitor ID Service > s_fid > IP/User Agent

 

Así pues, Adobe Analytics permite identificar y seguir a los usuarios entre dispositivos con una implementación relativamente sencilla, al igual que lo hace Google, aunque con ligeras diferencias en cómo se procesan los datos. Vosotros, ¿cuál preferís, User-ID o Visitor Stitching?

¿Quieres más información sobre Adobe Analytics? Contacta con nosotros aquí.

3 Comentarios

  1. Nicolás Lozano Responder

    Muy buen post Hector. Ya que preguntas cual preferimos, a mi me gusta el User-ID, simplemente porque creo que da más visibilidad de como un usuario interactua con nuestros activos digitales. No considero que se deba partir la sesión cuando el usuario se loga y se comience a usar el ID de usuario (ya sea el User-ID o el visitorID) para identificarlo. Quitando este punto, no veo una gran diferencia entre ambos y me parece que cumplen bastante bien su cometido.
    ¿Tu tienes algún favorito?

    • Héctor Camblor Responder

      Hola Nico,

      Es cierto que el hecho de que Google Analytics no incremente el número de visitas ni de visitantes cuando se comienza a usar el identificador de usuario es un gran punto a su favor. Por otro lado, algo favorable al visitor stitching de Adobe Analytics es la capacidad que tiene de no requerir que se envíe el identificador en cada medición, evitando tener que obtenerlo de nuevo o pasarlo entre páginas, y facilitando por tanto su implementación. Sin embargo, de momento, le doy una ligera ventaja a Google en cuanto a medición cross-device.

      Un saludo

  2. hola, tengo una pregunta relacionada con esto, me gustaría estudiar la atribución cross-channel con los datos de omniture pero no se bien de donde puedo extraer los toques intermedios entre el first y el last touch, es posible acceder a esta información?
    Muchas gracias

Escribe tu comentario

1 × 3 =

Navegar