Leemos constantemente la necesidad de implementar un data layer a la hora de desplegar una solución de analítica digital basada en un tag manager; pero ¿sabemos qué es, por qué es necesario y para qué sirve? Este post contiene una reflexión sobre un término que ya se incorporado a nuestro día a día, y que cada vez tiene más peso en la definición de una estrategia de medición online.
El data layer es el esqueleto de datos resultante de la toma de requerimientos de negocio. Una cajita donde iremos metiendo toda la información que no se recoge por defecto, pero queramos tener disponible para accionarla después. Es pues, un elemento clave en el diseño de una solución de analítica digital robusta, transversal y modular; y definirá una estructura de datos que luego podrán enchufarse a las diferentes aplicaciones contenidas dentro del gestor de etiquetas.
A nivel un poco más técnico, un data layer es una capa de abstracción intermedia entre lo que visualiza el usuario y las aplicaciones que hacen seguimiento de lo que se está visualizando. Como cualquier modelo de capas, ha de establecer interfaces entre capas colindantes. Una de esas interfaces, la que conecta con la capa que ve el cliente, es una variable JavaScript que consiste en un objeto JSON plano (aunque en el caso de Google Tag Manager se trata de un array de objetos, hay situaciones que las que no tiene por qué ser plano, etc…). Un lugar donde se cotejan claves y valores, definidas de manera adecuada a los objetivos que se espera obtener del despliegue de la solución de analítica. Considero muy adecuado extender el concepto de data layer a todos los elementos sobre los que pivotará la medición. Esto es, la capa de datos no tiene por qué ser únicamente lo que se defina en ese JSON, sino que puede ser también una cookie donde se pinte el identificador del usuario, o el típico parámetro con las keywords de los buscadores internos.
Es muy difícil que un data layer se defina completamente a la primera. Por ello, debemos ser conscientes de que no va a ser un esfuerzo puntual y ya, como toda solución digital ha de evolucionar para adaptarse a las nuevas necesidades.
Como se desprende de los párrafos anteriores, la implantación de un tag manager no exime de incluir código en página. Ocurre que ahora se utilizará ese código en página para alimentar diferentes aplicaciones, y no sólo la herramienta de analítica dispuesta. Es algo similar a lo que anticipaba Adobe con los contextData para el uso de Processing Rules; una estructura de datos entendible y transparente para el desarrollador, que luego se “mapea” a variables de Adobe Analytics.
Ahora bien, pese a que no todos los datos a utilizar estén definidos en el objeto JSON de página, siempre debemos convertir esas fuentes de datos en elementos de datos dentro del gestor de etiquetas. Esto es, traducir claves a módulos dentro del gestor de etiquetas (Data Sources en Tealium iQ, Datas en Ensighten Manage, Variables en Google Tag Manager…), para luego “mapearlos” donde más convenga. De esta manera, si algo falla y cierta variable deja de tener valores, no tendremos que sumergirnos en el código JavaScript que se implantaba en los despliegues onpage, y acudiremos a la definición del módulo que indico anteriormente para ver qué ha fallado.
Por otra parte, hay situaciones en las que no hay disponibilidad para el despliegue de código en página, y se recoge información mediante jQuery basándose en la estructura de la página. Aunque un objeto alimentado desde el back-end nos daría mayor robustez y fiabilidad, no es el fin del mundo realizar una medición basada en el cuerpo del HTML. Eso sí, si tenemos definidos elementos de datos de la manera más modular posible dentro del gestor de etiquetas, será mucho más sencillo arreglar ese se ha dejado de recoger el ID de las transacciones porque ha cambiado el estilo de la página al tener esa fuente de datos centralizada.
Por ser su intención la de ampliar las capacidades por defecto de las herramientas, un buen data layer deberá ir más allá en la información recogida acerca de la página que se está visualizando. Por ejemplo, los gestores de contenido suelen proveer de la temática asociada a una publicación (nubes de tags). Volcar esta información en la capa de datos permitirá hacer un análisis desglosado de temas para ver cuál ha triunfado en esa franja de tiempo; pero también ofrecer a un usuario interesado en una sección de artículos de la misma en la portada.
Esa información nos permitirá tener datos centrados en el sitio, pero la tendencia es a ir hacia una visión customer centric. Un buen contexto digital centrado en el usuario nos aportará una visión que pivote a su alrededor, en las acciones que ha hecho a lo largo de nuestros activos digitales y nos llevará a una segmentación más avanzada en nuestra herramienta de reporting. El despliegue acertado de un data layer nos puede ayudar a caminar por esa senda.
Además, como he indicado más arriba, los datos se pueden y deben vincular a las herramientas que nos parezcan adecuadas. Un visitante identificado ya no será un navegador. Rellenar el data layer con el identificador del usuario nos permitirá tener todo su customer journey de principio a fin en cualquier herramienta que permita ese tipo de seguimiento. Pero, además, podremos alimentar nuestro DMP para que aprenda de dicha persona. Y como ya hemos tenido que acceder al CRM para determinar el identificador del usuario, ¿por qué no personalizar el contenido que le muestro en función de su localización? Y si… ¿le muestro los anuncios que funcionan -brindis al sol- en todos los dispositivos que tenga vinculados?, ¿por qué no decirle a Optimizely, sin un nuevo desarrollo adicional, que ese usuario entra dentro del grupo que siempre paga sus facturas, y trato de premiarle con ese banner que creo que va a funcionar?
¿Y tú?, ¿cuáles crees que son los puntos más críticos a la hora de implementar un data layer?, ¿qué claves te sacarías de la manga para dar un giro original a tu medición?
Créditos de la imagen: What is a data layer? | Tealium. (2016). [online] Tealium. Disponible en: http://tealium.com/what-is-a-data-layer/.
