El Data Layer para Anunciantes

En primer lugar dejemos claro qué es lo que entendemos por un Data Layer, y creo que una de las mejores deficiones que he leído es la del gran Simo Ahava en la que dice lo siguiente:

• La descripción de los requerimientos y objetivos de negocio, alineados en un formato que es facilmente transferible a especificaciones técnicas.
• El concepto de una capa de información semántica almacenada en un contexto digital

Esto requiere de algunas explicaciones para explicar en roman paladino, como diría mi jefe, el significado de esta definición.

Un Data Layer es un conjunto de datos con una estructura jerárquica (taxonomía) que queremos usar para generar un contexto de negocio a cualquier interacción en un entorno digital, por ejemplo nuestro sitio web. Generalmente el propósito del data layer es el de poder pasar esos datos del contexto de negocio a otras aplicaciones como por ejemplo nuestra herramienta de analítica web, nuestro DMP (Data Management Plattform) o nuestro adserver a través de las etiquetas floodlight (en el caso de DoubleClick) en nuestro sitio web. Usemos un ejemplo de analítica web para poner un ejemplo práctico.

Trabajemos sobre una página correspondiente a una ficha de producto (PDP – Product Detail Page) en la web de Casa del Libro. De manera estandarizada, es decir sin que tengamos que hacer nada especial por nuestra parte en la implementación de Google Analytics, nuestra herramienta de analítica web es capaz de capturar una buena cantidad de información del navegador del usuario incluyendo la URL de la página, la versión del navegador, el Sistema Operativo del dispositivo, el lenguaje en el que está configurado, su resolución de pantalla… . Muchos de estos datos son interesantes pero no es infrecuente que desde la perspectiva de negocio sean de escasa utilidad.

Supongamos que el producto que ha visitado el usuario es un libro, “Los Relatos del Padre Brown” del gran G. K. Chesterton ( http://www.casadellibro.com/libro-los-relatos-del-padre-brown/9788496834460/122759 )

Una ficha de producto en un ecommerce tendrá una serie de elementos comunes independientemente de la tienda como por ejemplo el nombre del producto, el precio al que se ofrece, una categoría de producto (jerarquía de producto) o la referencia (SKU). Esos datos ya los ha definido Google Analytics en su estándar Enhanced Ecommerce lo que nos obliga a seguir su estándar para dichas variables. Pero es muy probable que el analista de la tienda de libros quiera capturar más datos de esta interacción con una ficha de producto como por ejemplo: ¿se trata de la edición en tapa dura o en cartoné? ¿es edición de bolsillo? ¿se trata del libro físico o la versión electrónica (ebook)? ¿puede ser interesante guardar el ISBN además del SKU de Casa del Libro?. Cualquiera de esas variables podrían ser variables de negocio mucho más ricas e interesantes que las que he mencionado anteriormente.

Es importante entender que en el ejemplo de Google Analytics hay variables que son obligatorias (como en el protocolo de Enhanced Ecommerce) pero que Google, en su versión Premium, nos ofrece la posibilidad de tener hasta 200 variables personalizadas para nuestras necesidades de negocio. Es evidente que entender los fundamentos de un data layer es fundamental pero lo que realmente es esencial es la definición de la taxonomía de negocio.

Aquella información que no se envíe a los servidores de la aplicación no estará disponible para su análisis posterior. Pero, como decía Jack el Destripador, vayamos por partes. Empecemos por la definición más técnica del data layer para luego pasar a consideraciones menos técnicas y más cercanas a negocio.

El Data Layer desde una perspectiva técnica

Técnicamente el Data Layer se crea como un objeto JavaScript en el código HTML de la página y puede estar compuesto de una o de varias variables anidadas con una relación jerárquica.

Una variable no es más que una especie de contenedor que sólo puede almacenar un valor de un tipo determinado a la vez. Cuando queramos juntar varias variables con diferentes valores tenemos que usar un array, otro tipo de variable que puede guardar varios elementos del mismo o de diferente tipo a la vez.

Veamos un ejemplo sencillo de data layer en el que incluyamos datos de identificación de un usuario (uid), el nombre del producto (productName)  y el valor del producto (productPrice). Para ello vamos a crear la variable ‘dataLayer’ que incluirá un array de variables con el formato ‘key:value’ («clave»:valor)

var dataLayer = {
  "userId": "1234",
  "productName": "Xbox One",
  "productPrice": 449.99
};

Acabamos de definir un objeto JavaScript que se llama ‘dataLayer‘ que contiene tres variables ‘userId’, ‘productName‘ y ‘productPrice‘ cuyos valores se han fijado a ‘1234‘ y ‘Xbox One‘ y ‘449.99‘ respectivamente. Se puede observar que el ‘userId‘ y ‘productName‘ se han guardado entre comillas, es decir, como un string de caracteres mientras que el ‘productPrice‘ como un número (sin comillas).Cuando queremos acceder a los valores tan sólo tenemos que usar la siguiente convención ‘dataLayer.productName‘, el nombre del objeto seguido de un punto y el nombre de la variable. Si ejecutamos el siguiente comando nos devuelve el valor de la variable ‘productName’:

Cuando hablamos de variables anidadas el objeto JavaScript toma otro aspecto diferente en otra versión del modelo de Data Layer (version 2):

var dataLayer = {
  "user": {
    "id": "1234",
    "email": "joe.bloggs@gmail.com"
  },
  "page": {
    "type": "product"
  },
  "product": {
    "name": "Xbox One",
    "id": "XB1",
    "price": 449.99
  }
};

En este caso cuando queramos usar una de las variables anidadas se incluye un punto para cada nivel adicional de la estructura de árbol. Siguiendo el caso anterior le diríamos que queremos del objeto ‘dataLayer‘ del objeto ‘product‘ y el atributo ‘nombre‘ :

Una vez que hemos «pintado» estos datos en el datalayer en nuestro código ahora es posible trasladar esas variables a nuestro floodlight para alimentar los datos de las variables personalizadas.

Hay que tener en cuenta que la complejidad de crear un Data Layer no está en la creación del objeto JavaScript, una tarea que cualquier técnico que hable JS con soltura puede hacer sin despeinarse, sino en traer la información de nuestros sistemas (back), recuperarla y “pintarla” en al Data Layer.

Bien ahora si vemos el data layer que utiliza Casa del Libro en nuestro anterior ejemplo podemos ver el siguiente código en su página:

Donde podemos ver cómo han creado la variable dataLayer primero y han decidido crear una variables que son sencillas de interpretar:

• ‘pageSection’: la sección a la que pertenece la página
• ‘pageType’: el tipo de página en la que nos encontramos, en este caso una ficha de producto
• ‘pageCode’: el código devuelto por el servidor a la petición del contenido (200, la respuesta estandar para un petición completada sin errores)
• ‘pageCategoryPath’: la ruta del rastro de migas de la página

Una de las ventajas del data layer es que es un formato estructurado de datos que es agnóstico de la herramienta que estemos utilizando, en otras palabras lo podemos usar en cualquier aplicación a la que necesitemos hacer llegar los datos que contiene el data layer. Precisamente esta característica es la que lo hace una pieza fundamental de cualquier estrategia de datos.

Si utilizamos una herramienta de debugging como Charles (la manera técnica de llamar a ver el detalle de lo que ocurre entre nuestro navegador y el servidor de analytics en este caso), podemos ver que las variables del data layer que acabamos de ver están viajando a Google Analytics:

A la Hora de Establecer una Taxonomía de Negocio

El origen de la palabra Taxonomía viene del griego Taxis (orden) y Nomos (ciencia), podíamos decir que hablamos de la ciencia de la ordenación, de la clasificación. Generalmente la relación entre los conceptos de una taxonomía suele ser jerárquica, es decir de padre a hijos.

En el mundo de la taxonomía normalmente son entes expertos los que definen los criterios de clasificación. El ejemplo clásico es el sistema de clasificación usado en las bibliotecas de todo el mundo desarrollado por Melvil Dewey en 1876 con base decimal (10) para clasificar cualquier libro en función de su temática y que perdura hasta nuestros días. La gran ventaja de las taxonomías en el mundo digital es que, a diferencia de sistemas como el de Dewey, no tienen que limitarse a un sistema de jerarquías cerrado, si queremos crear una nueva dimensión para nuestro análisis tan sólo tenemos que crear un nuevo atributo.

Es importante entender que no hay una única manera de crear una taxonomía para un mismo conjunto de elementos, será la explotación que queremos hacer de los datos el principal motor de una buena taxonomía.

La estructura jerárquica de una taxonomía nos permite obtener capas de agregación y de bajada a detalle en nuestro análisis. Por ejemplo si pensamos en la jerarquía de producto en función de su categoría con la siguiente estructura:

1. Nivel 1: Libros
2. Nivel 2: Novela Negra
3. Nivel 3: Autores Americanos

Nos permitiría hacer un análisis agregado para todos los libros (nivel 1) y bajar al detalle de todas las novelas negras de autores americanos (nivel 3).

A la hora de generar una taxonomía en muchas ocasiones tendemos a utilizar los conceptos más evidentes, es decir aquellos que de manera lógica describen el objeto. Por ejemplo una página de producto de un libro tendrá asociados una serie de atributos lógicos como el titulo del libro, el precio, el descuento que se le aplique en el momento, el autor o autora del libro, la editorial que publica el libro o el ISBN, por citar algunos ejemplos. Sin embargo lo que no es tan evidente es otro tipo de atributos que pueden permitir hacer análisis más longitudinales. Por ejemplo en una sitio web podemos usar una codificación para diferenciar los distintos tipos de página, por ejemplo: portada, ficha de producto, listado de productos, checkout y zona privada. De esta manera seremos capaces de hacer análisis por tipo de página independientemente de la sección o categoría a la que pertenezca en la navegación de nuestro sitio web.

Pero es muy probable que nos interese entender otro tipo de dimensiones, por ejemplo si guardamos como variable en el sistema la disponibilidad de stock del producto podremos hacer una análisis de la demanda de producto (cuanta gente lo está buscando o visitando) contra su disponibilidad en nuestros almacenes.

Otro factor que puede ser interesante en un ficha de producto es el número de imágenes que mostramos del producto. La producción de fotos de calidad para nuestro sitio web es una partida de gasto relevante por lo que si somos capaces de analizar al incorporar una imagen adicional con perspectiva cenital de nuestros zapatos, si guardamos ese dato en una variable, seremos capaces de comparar el performance de las fichas de producto que incluyen esa imagen de las que no lo incluyen y ver si realmente está impactando en la conversión.

En ocasiones no es tanto la creación de una nueva variables sino el uso de un concepto de agregación por encima de los valores de una variable que ya exista, me explico. Imaginemos que, por ejemplo, queremos clasificar las cestas de la compra por su valor. Lo más probable es que tengamos una variedad muy grande de cestas, desde clientes que sólo han comprado un artículo de bajo importe hasta cestas de varios productos de importes altos. Si incorporamos una variable que use rangos de cesta de la compra podremos hacer análisis de nuestras transacciones según el rango al que pertenezcan. Si cogemos todos los datos de nuestras transacciones, las ordenamos de mayor a menor y las dividimos en quartiles (en cuatro grupos: 25%, 50% y 75%, donde el 50% es la mediana de la distribución) tendremos una capa adicional de análisis.

Como decía al inicio la explotación de los metadatos es el motor de nuestra taxonomía y tenemos que tener eso en mente cuando trabajemos nuestro modelo de datos. Cada vez más con la llegada de los DMPs la capacidad para generar segmentos desde nuestros datos para activar en los DSPs nos obliga a pensar en otro tipo de datos que pueden ser de utilidad y que de manera natural no se recogen. Por ejemplo si queremos hoy en día crear un segmento de Google Analytics de aquellos usuarios que hayan visto al menos 2 páginas de producto no tenemos una manera de hacerlo, incluso aunque hayamos creado la variable de tipo de página en nuestro data layer. Pero si creamos una nueva variable que cuente el número de PDPs que ve el usuario durante su navegación (sumando 1 cada vez que ve una PDP adicional) tendremos una variable sobre la que crear nuestro segmento.

Dos recomendaciones finales, una sería que antes de crear la taxonomía fijándonos sólo en los elementos sobre los que queremos recoger información, sean estos páginas, productos o cualquier otro tipo de elemento, hagamos un esfuerzo por abstraernos un poco de esa realidad y tratemos de pensar en qué tipo de análisis y explotación de los datos querremos hacer a posteriori. Seguro que este ejercicio nos dará una perspectiva mucho más amplia a la hora de diseñar nuestro modelo de datos.

La segunda sería que tengamos en cuenta que los datos van a ser utilizados por muchas personas y no sólo por los que crearon la taxonomía.Tenemos que tener en cuenta que las variables no puede tener en su nombre espacios por lo que es necesario una convención de nombrado que haga legible la variable en la medida de lo posible. Si recurrimos a un estándar de nombrado de nuestras variables que sea comprensible para el común de los seres humanos estaremos facilitando mucho la tarea posterior a nuestro analistas.

En mi experiencia, trabajando con grandes profesionales en la parte técnica, es bastante común usar el estándar de nombrado camel case y su variante el lower camel case. Supongamos que la variable que queremos nombrar es nombre del producto, usando el lower camel case podríamos escribirla como nombreDelProducto o simplemente nombreProducto. El acoger un estándar de nombrado facilitará luego no sólo la lectura e interpretación de la variables sino que será más fácil usar las variables a la hora de construir una consulta a la base da datos para extraer un set de datos sobre el que realizar nuestro análisis.