Cómo crear un sistema de alertas automatizado

Por diferentes motivos personales, no había podido asistir a las últimas convocatorias del MeasureCamp de Madrid, así que este año... ¡no me lo quería perder!

Y esta vez, quería hacerlo de una forma diferente: ser un componente activo, compartiendo algo de lo aprendido en mis años como analista.




En concreto, quería aprovechar la oportunidad brindada para explicar el trabajo de una solución, a un problema que se me planteó:

Os pongo en contexto: una web consta a grandes rasgos de dos partes:


El área de persuasión, que es el espacio para disponer de los recursos y elementos que permitan persuadir al usuario de tal manera, que accedan al área de conversión, espacio en el que lograr la consecución de los objetivos del site.

Ambos espacios son muy diferentes: mientras que el primer área se caracteriza por existir muchos y diferentes toques del usuario, haciendo complejo su simplificación, la segunda área propone un funnel "generalmente" lineal, más fácil de analizar.

Hasta hace poco más de un año, había estado trabajando en diferentes sectores pero principalmente, me había centrado en e-commerce. Dichos sites se caracterizan por tener un único proceso de contratación (o área de conversión): independientemente de lo que compre el usuario (faldas, pantalones, zapatos... ), todo ello es añadido por el usuario a un único carrito, y de ahí se tramita la compra.

Este hecho conlleva a que sólo era necesario monitorizar UN área de conversión y las preguntas que me planteaba eran...

¿cuántos de los que han empezado, terminaron convirtiendo?
¿cuántos se caen en cada paso? ¿cuáles son los puntos de fuga?
Y todo esto segmentado por canal y cualquier otro tipo de dimensión personalizada propia del site.


Sin embargo, cuando empecé a trabajar en el sector de la banca me di cuenta de que el paradigma había cambiado: el proceso de contratación de una tarjeta no es el mismo al de un depósito o un fondo. 

Son distintos, únicos; Digamos que varían en distintos aspectos...

... El número de pasos: por ejemplo, para hacer una transferencia, el usuario necesita completar 2 pasos mientras que, para hacer un traspaso interno de fondos son necesarios 4.

... Cada uno tiene su propio ecosistema: es necesario crear dimensiones personalizadas propias de cada proceso, por ejemplo:
  • Para la contratación de un fondo de jubilación es necesario conocer si el usuario está jubilado/activo
  • Para la contratación de una cuenta es necesario conocer si el usuario la quiere vincular a una tarjeta nueva o que ya tiene contratada
  • Para el traspaso de fondos de otra entidad es interesante conocer de qué entidad proviene y cuánto importe traspasa
... El número de contrataciones de los distintos productos no son comparables al igual que la tasa de completado; Por ejemplo, mientras que los procesos de transferencias son uno de los más habituales y gozan de una tasa de completado elevada, el proceso de contratación de una cuenta focalizada para nuevos clientes nada tiene que ver: tanto la frecuencia como la tasa de conversión. Son muy diferentes debido a que son procesos enfocados a perfiles de usuarios diferentes, cliente y potencial.





Lo que quiero llegar a decir es que, el hecho de que las áreas de contratación de los distintos productos sean únicos, hizo que me planteara las siguientes preguntas:
¿cómo puedo controlar tal cantidad de procesos de contratación? ¿cómo puedo conocer si ha habido algún incremento especial en alguno de los pasos? ¿cómo puedo conocer si se ha roto la medición?

Esta última pregunta puede sorprender pero en el MeasureCamp me di cuenta de que era un problema que tenía más de uno. En grandes organizaciones donde la implementación del data-layer es ejecutada por los desarrolladores de mantienen y evolucionan el sitio web, se producen rupturas de medición con frecuencia; ¿Por qué sucede esto?

  1. Lo primero porque siemplemente se les pide que hagan una cosa sin explicar el contexto ni para qué sirve. Este hecho, a cualquiera, hace que no saquemos las tareas con las ganas que tendríamos si nos sintieramos parte del proceso comprendiendo en qué y para qué estamos colaborando.
  2. Y lo segundo, para los desarrolladores el sistema de Google Tag Manager que permite inyectar código de Javascrip, lo ven como una injerencia en el ecosistema del que son responsable, por lo que no son muy fan de ellas. Y como decían en las charlas, en caso de que el sitio web se caiga y quitando algún código GTM vuelve a funcionar, no dudan un minuto en eliminar la medición.


A la conclusión que llegué después de hablar con diferentes personas sobre este tema es que para paliar este problema son necesarias dos cosas:


- Formación a los equipos de desarrollo: hacerles formar parte del proyecto, explicarles cómo funciona la herramienta, que GTM dispone de un sistema preview en el que probar los cambios en real antes de su paso a producción,  y a su vez mostrarles en qué se traduce su trabajo: cuadros de mando, conclusiones y acciones que se han tomado gracias a que se disponía de ciertos datos que han podido ser recogidos gracias a ellos, etc...
Un compañero dijo que tras una formación las incidencias disminuyeron drásticamente así que entiendo que merece la pena y entraría dentro de las prioridades a abordar.



- Crear un sistema automatizado de alertas: que me permitiera saber con la mayor anticipación posible cuando se produjo un problema en la medición para ponerme manos a la obra.

Lo que si tenía claro es que quería algo automatizado que me evitara tareas manuales , me permitiera continuar con mi trabajo de analista, con mi foco en el análisis de los datos.

Para crear un sistema de dichas características existen distintas posibilidades...


  • DataStudio: implica un esfuerzo importante el dibujar cada uno de los procesos con la desventaja de que aún no permite obtener ratios de caída de cada uno de los pasos, ni tasa de conversión sobre datos segmentados.
  • Generar alertas en GA: se puede establecer para tener un control de las contrataciones de cada uno de los procesos. Ayudaría a conocer una ruptura del a medición en la parte final del proceso, porque aplicarlo a cada una de las fases del funnel, supone un trabajo titánico.

¿Y si buscamos una solución alternativa que haga más potente nuestro control? ¿y si aplicamos alguna de las técnicas estadísticas que hacen posible conocer por dónde se mueve el usuario, si se produce ruptura de la medición o vigilar cada uno de los pasos de los funnels?

Cuando hablamos de estadística todo el mundo piensa inmediatamente en R: sin duda es la herramienta top del momento pero antes de utilizarla creo que es importante plantearse por el nivel de madurez del equipo. ¿Hasta qué punto merece la pena montar algo complejo si no va a ser posible su mantenimiento a lo largo del tiempo? ¿por qué no empezamos con algo pequeño y en caso de que aporte valor, se evolucione hacia algo más potente?

Empecé con un excel

Utilicé la herramienta de Supermetrics (permite definir llamadas a la API de GA) para traerme los datos de Google Analytics de los pasos de un funnel con periodicidad semanal. En caso de que funcionara, lo extrapolaría a todos los funnels del sitio web.

La idea básica era comparar el dato de la semana anterior con los datos históricos: es decir, conocer si el dato en análisis se encontraba en el intervalo de Q1- Q3 del histórico.

- El hecho de que el dato se encuentre cerca de la media de la distribución, significa que el número de usuarios que han pasado por esa parte del funnel en la fecha de análisis ha sido normal.
- En caso de que fuera menor que Q1 o mayor que Q3, los datos están indicando que ha sucedido algo fuera de lo normal y hay que ponerse a bucear.





Comentar un par de puntos que hay que tener en cuenta:

- Para aplicar técnicas estadísticas es muy importante disponer de un histórico, cuanto mayor mejor, y que no haya sufrido cambios como puede ser la introducción de una campaña, el pasar a medir de otra manera (de código GA a GTM), etc... porque si no estamos hablando de distribuciones diferentes.

- Tampoco hay que olvidar el factor de la estacionalidad. Lo ideal en este caso sería disponer de un histórico de todo un año que recogiera las variaciones de cada una de las estaciones del año.

- Es necesario conocer la naturaleza de los datos para saber cuál es su correcta distribución: normal, poisson, etc...



Referente a las formas y herramientas de llevarlo a cabo existen varias, y habrá de elegirse en base a los recursos disponible y al nivel de madurez del equipo: 




Al establecer una alarma que saltara en los casos en los que el dato se encontrara fuera del rango, me iba a permitir conocer si estaba sucediendo algo extraordinario. Y para ello tenía ubicado no sólo el proceso en cuestión, sino también en qué parte del mismo, me explico:

Por ejemplo si el dato anómalo se produce únicamente en la parte final del funnel del simulador de hipotecas, los datos están indicando que aunque accedan al servicio un número de usuarios similar al histórico, estos gozan de un mayor interés/ se muestran verdaderamente por dicho producto, ya que se ha incrementado el número de peticiones de manera especial.

Con este ejercicio no sólo se logra un control de posibles incidencias sino también un mayor conocimiento de por donde se van moviendo los usuarios, en donde se está centrando el interés y en base a ello, actuar ;)







Y además...




Ahora bien, con un warning bien grande! la estadística no es fácil, así lo explicaba en un post anterior (Analística Web) porque se basa en axiomas que hay que tener en cuenta a la hora de hacer una correcta interpretación de los datos.

Comentarios

Entradas populares de este blog

¿Diseñamos un Dashboard con R?

Profundizando en Google Data Studio