Detección de errores en herramientas de medición

En programación existen multitud de errores que nos hacen la vida imposible, por eso, un programador (siempre que pueda) debe optimizar y dejar el código lo más legible posible.

En el mundo de la programación nos podemos encontrar varios tipos de errores y es importante conocerlos para poder detectarlos.

Tipos de errores

Errores de compilación

Estos tipos de errores se pueden ver con mucha frecuencia, ya que generalmente son errores de sintaxis (se te olvida cerrar una llave, variables no declaradas, etc.…). Estos errores no ejecutan la aplicación.

Errores de ejecución

Estos errores se producen cuando la aplicación se está ejecutando. Son menos comunes que los de compilación, ya que en la mayoría de los casos los tienes en cuenta a la hora de desarrollar la app. Por ejemplo, un usuario accede a una calculadora, y realiza una división entre 0, o introduce valores que no son los que pedimos (string entre número)

Errores lógicos

Por último, los errores lógicos son los más complicados de detectar, ya que son errores donde la aplicación se ejecuta de manera corriente, pero los resultados no son los esperados. Esto se suele producir por un mal diseño de algoritmo de la aplicación. Estos errores son muy corrientes en Google Analytics a la hora de realizar una implementación.

¿Cómo detectar Errores de compilación?

Como hemos comentado anteriormente estos errores son generalmente errores de sintaxis. 

¿Cómo se verán estos errores?

Como es un error de compilación la app dejará de funcionar. Por lo tanto, lo primero que deberemos hacer es meternos a la consola (f12 o clic derecho inspeccionar) y ver de qué tipo de error se trata.

Unos tips que uso yo y que me van bien son los siguientes

  1. Primero, analizo la frase de error. En este caso, es un SyntaxError: Invalid or unexpected token. Esto es importante porque ya sabemos el tipo de error que debemos buscar. 
  2. A continuación, te sale dónde y en qué línea está ocurriendo este error. Tras analizarlo, clicamos en paginaEjemplo.html:9
  3. Al hacer clic en el enlace de error, nos lleva a “Sources” y nos marca la línea donde se encuentra este error en concreto.
  4. Ahora lo difícil es saber dónde se encuentra exactamente, para así poder corregirlo. Analizamos poco a poco la línea 9 y como podemos observar el error está en la comilla ‘GTM-XXXXX’ 

A veces este tipo de errores son los que más dolor de cabeza dan, ya que piensas que es algo más complejo y luego es todo lo contrario, por eso hay que tener un cuidado especial con estos errores. 

Nota: La mayoría de los editores (por ejemplo, Sublime Text) te cambian de color la tipografía, según el lenguaje, por lo tanto, es muchísimo más fácil de localizar el error.

¿Cómo detectar errores de ejecución?

A diferencia de los errores de compilación, éstos sabemos que van a ocurrir y los podemos intentar remediar.

Por ejemplo, pedimos que introduzca el usuario un número mediante un prompt, y el puede introducir cualquier carácter. Si lo recogemos en una variable numérica, nos dará un error…

Por eso, en la medida de lo posible usaremos condiciones o try/catch.

Si introdujéramos un 0 saldría infinity o si introdujéramos una cadena nos daría NaN. Realmente estos problemas de ejecución no son frecuentes en el ámbito de la analítica, aunque de vez en cuando nos los podríamos encontrar y deberíamos saber remediarlos.

Por ejemplo:

En estos tipos de errores deberemos anticiparnos y pensar en todos los caminos posibles que podrá realizar el usuario para poder así minimizar los futuros errores.

¿Cómo detectar errores lógicos?

Los errores lógicos son los más complicados de detectar, ya que son muy genéricos. Los de compilación te dicen en la mayoría de los casos la línea exacta donde se encuentran, pero con éstos tendrás que buscar donde está el fallo.

Imaginemos que un día nos metemos en Google Analytics y nos encontramos con lo siguiente:

Lo primero que deberemos hacer es segmentarlo (como si fuera una pirámide donde la “imagen que vemos” es la base y el pico el error en concreto).

En Analytics podríamos añadir una dimensión secundaria para irnos acercando. Puede ser cualquiera, siempre y cuando te especifique donde ocurre o cuando ocurre ese error.

Por ejemplo, podrías poner la dimensión de acción de evento, etiqueta de evento, de url de la página… 

Una vez que hayamos visto y segmentado en Analytics y tengamos una ligera idea de donde se encuentra el error, deberemos irnos a la página y abrir la herramienta para desarrolladores (Inspeccionar). Una vez dentro, nos dirigimos al network (o si tenemos instalado el plugin de dataslayer) y filtramos por collect (es el tipo de hit que envía GA). Ahí vamos enviando los hits que creemos que van a dar undefined o el dato que se envía de manera incorrecta (clicando botones, banners, etc..).

Como podemos observar, tendremos que filtrar por collect, activar las siguientes opciones y saldrán todos los Hits. También podremos ver directamente a qué tipo pertenece (t=event).

Si pulsamos, aparecerá una ventana al lado derecho y en headers tendremos toda la información que se envía en el Hit a GA (Tipo, url, path, custom dimensions…).

Ahí podremos observar si sus valores son undefined o no son lo que se tienen que enviar.

¿Qué deberemos hacer una vez que tenemos el error localizado?

Cuando hemos localizado el error, miraremos las clases de la etiqueta o su implementación de JavaScript, ya que existe una gran probabilidad de que sea problema del método de recogida, mediante clases o identificadores.

Imaginemos que tenemos el siguiente ejemplo. Tenemos un botón (cuando pulsas envías el hit de evento) y un párrafo que será el label que se envíe en el datalayer. En este caso cogería todo correctamente y lo enviaría. De repente, en unos días te vuelves a meter en Analytics y la etiqueta de evento te aparece como undefined. Vamos al código y nos encontramos con esto:

A priori, vemos que han realizado cambios. Lo que deberemos hacer es identificar el lbl y ver su método de recogida. Como podemos ver, han cambiado la clase, por lo tanto tendríamos que cambiar el método de recogida.

Esto es muy frecuente cuando no tenemos los códigos fuente pero si tenemos scripts insertados mediante GTM donde enviamos los Hits desde el mismo.

En este caso, es un ejemplo que se ve muy claro, pero en la vida real tendrás cientos de secciones que comparten clases o selectores muy complejos y la búsqueda de estos son más complicados.

Cabe destacar, que cuando ya has identificado el error y sabes qué selector falla, en la consola puedes comprobar el nuevo método de recogida, así para comprobar en tiempo real si lo que estás recogiendo es correcto o es lo que quieres, ya que puedes cruzar los datos sin darte cuenta y coger otra etiqueta. Por ejemplo:

Si eres programador deberías tener el código limpio y refactorizado, ya que, en un futuro, cuando tengas miles de líneas de código, te sea más fácil encontrar el error. Por ello, mi recomendación es seguir el principio SOLID (Single responsibility, Open-closed, Liskov substitution, Interface segregation and Dependency inversion). 

¿Qué procedimiento sigues tu?

Pablo Chicano

Pablo Chicano

Share on facebook
Share on twitter
Share on linkedin
Share on email
4 min
Suscríbete a nuestra newsletter

Los mejores artículos de analítica digital para potenciar tu negocio.

Dejar un comentario

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *

Entradas relacionadas

Visualizaciones personalizadas de datos en google data studio

Google Data Studio se está posicionando como una de las herramienta más utilizada en el mundo de la visualización de datos y reporting. Como todas las herramienta de esta naturaleza, el tipo de visualización de datos que nos permite crear es limitada. Por ahora podemos mostrar nuestros datos a través de diferentes widgets: Scorecard Tablas

3 minutos

Dificultad

AudienceStream de Tealium

AudienceStream es un Customer Data Platform (CDP) de Tealium. Se trata de una herramienta para segmentar y crear audiencias en tiempo real.

2 minutos

Dificultad