Analítica web
Reflexiones sobre madurez digital, datos y tecnología

Analítica Atómica: building blocks

Se lee en 2 minutos

Todos los días manejamos herramientas con licencia por valor de una casa a las afueras de una gran urbe. Seguimos sus dogmas a la hora de estructurar el dato y amoldamos la analítica a sus productos.

Pero el dato, inherente al negocio, debe cambiar a lo largo del tiempo. No mantiene una estructura ni flujo constante. Es volatil pero trascendente. Es flexible pero vertebrado alrededor de ciertas necesidades inamovibles

¿Cómo estructurar, entonces, algo que plantea tantas dicotomías? La solución parece lógica. Un desarrollo inhouse permite ese grado de flexibilidad al no estar restringido por la funcionalidad de ninguna herramienta.

La pregunta pasa a ser entonces ¿cuál es la herramienta atómica de analítica que puedo implementar?

Para contestar a esta pregunta se debe primero diseccionar varias herramientas del mercado y así conocer, conceptualmente, sus partes constitutivas.

diagrama_bloques_herramienta_analítica
Fuente: Elaboración propia

Estructura

A simple vista diferenciamos tres grandes bloques:

  • Cliente: código que realiza la monitorización y envío de datos a la herramienta.
  • Servidor: encargado de operar sobre el dato.
  • Almacenamiento: almacena el dato a petición del servidor.

Cada uno de estas partes puede implementarse con una variedad de tecnologías siempre creciente.

Cliente

Aunque en la actualidad se emplea código JavaScript en su mayoría, los grandes frameworks frontend como Angular y React pueden utilizarse con mayor seguridad y escalabilidad en TypeScript. Éste provee un lenguaje tipado que nos ayuda a detectar posibles errores en la implementación y nos facilita la definición de la taxonomía.

Servidor

Existen, hoy en día, una variedad inmensa de frameworks backend. En Java contamos con Grails y Spring, en Ruby con RoR, tenemos MVC con C# y Node si empleamos JavaScript. Esta elección es, prácticamente, personal y dependerá de la experiencia de quién o quiénes deban implementar la solución con cada uno de estos lenguajes y frameworks.

El servidor en sí se modela como una serie de APIs de inserción y otras de recuperación para analizar los datos. Entre medias se puede diseñar como una serie de módulos pub/sub que filtran, actúan y generan datos nuevos a partir de los recibidos.

Almacenamiento

Dependiendo de los requisitos de seguridad y de la flexibilidad que queramos tener en el dato podemos recurrir a alguna de las siguientes opciones:

  • Almacenamiento local: alojar los datos en la propia red de la empresa, o en una DMZ.
  • Almacenamiento remoto: desplegando la base de datos en una VPS en cualquier proveedor de PaaS
  • Database as a Service: existen proveedores de bases de datos que abstraen toda la configuración y mantenimiento de la base de datos para que sólo tengas que preocuparte de llenarla. Algunos de estos servicios son Amazon Relational Database, Microsoft Azure SQL, Heroku Postgres, etc. Esta solución es especialmente interesante en cuanto a su escalabilidad.

Consideraciones

Evidentemente, un desarrollo de este tipo gana en flexibilidad sacrificando otras cualidades de herramientas de analítica que son, ahora, estándar de la industria. Si pensamos en herramientas como Google Analytics, Adobe Analytics y similares, estas funcionan out-of-the-box. No necesitan casi ninguna o ninguna configuración adicional, ahorrando tiempo de desarrollo. Además, el desarrollo inhouse requiere de un equipo de desarrollo y mantenimiento que no tiene por qué tener cabida en todas las empresas.

Tenemos que tener en cuenta, además, que los desarrolladores de estas herramientas son especialistas y dedican todo su tiempo a ello. Tienen un expertise acumulado importante. Si imaginamos la cantidad de clientes con que cuentan no es extraño pensar que conocerán muy bien cómo aportar valor a tu negocio y sorprendernos con nuevas funcionalidades continuamente.

 

Escribe tu comentario

2 × cinco =

Navegar