Para que el analista digital pueda realizar su trabajo en las mejores condiciones, necesita poder conectar los datos de las plataformas con las que trabaja con sus herramientas de análisis. Esta labor cada vez se hace más complicada, ya que a medida que van aumentando las fuentes de datos, establecer una conexión fiable es cada vez más difícil. Para poder hacer frente a esto, existen los data lakes, repositorios de almacenamiento en la nube en los que unir todas las fuentes de datos bajo un modelo de análisis.
Pero, ¿cuánto tiempo se necesita para un proyecto de estas características? Y lo que es más importante, ¿cómo podemos abordarlo? Para ahondar en este proceso, hoy cuento con la colaboración de un gran profesional, David García, Head of Data de Laboratorios ISDIN.
Fase 1: Punto de partida
En el instante en el que desde ISDIN deciden tomar la decisión de construir un data lake, lo hacen con el principal objetivo de unificar y consolidar los datos recopilados de las diferentes plataformas en un único repositorio. El momento era el idóneo ya que coincidió con la apertura de un nuevo mercado importante como es el de Estados Unidos. Vieron que, para evaluar el rendimiento real de sus campañas de publicidad en ese mercado, era fundamental aunar los conjuntos de datos a los que tenían acceso en un único repositorio y, además, poder tenerlos en propiedad para manejarlos sin depender de terceros.
Esta decisión supuso un gran reto para la compañía, ya que en aquel momento el modelo de madurez analítico no estaba del todo consolidado, por lo que para poder llevarlo a cabo, fue necesaria una reorganización que afectó tanto al almacenamiento de los datos como al propio departamento.
Fase 2: Planteamiento
Con los objetivos del data lake alineados con el negocio, llegó el turno de plantear la línea de trabajo desde la que iniciar el proyecto. En este aspecto, se valoraron dos opciones:
- Construir un equipo especializado, lo que suponía contratar a profesionales que pudieran seguir con su trabajo a lo largo del tiempo.
- Contratar una agencia especializada que diera soporte en el inicio del proyecto.
Al final se optó por contar con El Arte de Medir para que le ayudáramos a establecer los primeros pasos del data lake, entre los que se encontraba la elección de la plataforma cloud más adecuada para la construcción del mismo. Para esta elección, se tuvieron en cuenta las grandes plataformas dentro del mercado: Google Cloud, Amazon Web Services y Microsoft Azure. Las tres comparten características y precios similares, por lo que al final se decidieron por aquella que mejor se adaptara a las necesidades de ISDIN en ese momento, Google Cloud.
El último punto de esta fase fue determinar cuáles serían las métricas y KPIs del data lake. Para ello, lo ideal siempre es hablar con los diferentes stakeholders para conocer cómo ayudarles a dar respuesta a las dudas o problemas que surjan en el día a día. Si esto no es posible, como ocurrió en ISDIN, la elección de métricas dependerá de los objetivos del negocio que a medio y largo plazo puedan ayudar de una manera más directa.
Fase 3: Construcción
En esta fase entró en juego uno de los puntos claves del proyecto y, que sin duda, marcaron su rumbo: la construcción y explotación del dato dentro del data lake. Esta construcción se puede hacer de varias maneras: a través de terceros o desde la propia empresa (in house). En el caso de ISDIN, desde el comienzo del proyecto sabían que el data lake tenía que ser in house ya que, aunque el volumen de datos no era muy grande, contaban con fuentes de datos muy diversas (datos digitales, marketplaces, farmacias digitales), y gracias a este tipo de repositorio, tendrían una mayor flexibilidad en la explotación de los datos.
Sin lugar a dudas, contar con un data lake in house tiene muchas ventajas, como no depender de otros. Pero también tiene sus desventajas, como por ejemplo el difícil acceso a los datos en bruto de las plataformas de terceros. Esto se convirtió en uno de los puntos de fricción del desarrollo del proyecto, ya que cada plataforma tiene unas limitaciones con las que hay que saber lidiar.
A esto hay que añadirle otro punto muy importante: el nivel de detalle de información que se desea almacenar dentro del data lake, conocido como granularidad. ¿Por qué? Pongamos un ejemplo: cuando se quiere analizar los datos de inversión publicitaria en una plataforma como Facebook o Google, estas herramientas ofrecen un nivel de profundidad de análisis que un data lake in house no tiene. Por eso es importante tener claro desde el principio hasta dónde van a llegar los análisis que se vayan a realizar, sobre todo en las primeras fases del proyecto. La parte positiva es que al ser un proyecto vivo y en continua transformación, a medida que evoluciona, también lo hacen las necesidades de la compañía, por lo que se puede ir profundizando es esta granularidad.
Fase 4: Explotación
En lo que respecta a la explotación del data lake, aunque el verdadero potencial reside en propio repositorio, en ISDIN también le han sacado partido con diferentes elementos, como por ejemplo:
- Visualizaciones automatizadas de consulta diaria como dashboards en Google Data Studio.
- Creación de reportes y cuadros de mando ad-hoc para campañas y promociones puntuales.
En definitiva, lo que empezó como un proyecto básico ha ido evolucionando en el tiempo y hoy día sigue manteniéndose a pleno rendimiento. Cuando se afronta un proyecto como la construcción de un data lake, se puede llegar a pensar que es un proceso largo y complejo, pero nada más lejos de la realidad. En el caso de ISDIN, al partir con un volumen de datos no muy grande, pudieron comenzar a construir una base sólida con la que el negocio fuera evolucionando. En otras palabras, partieron de un Mínimo Producto Viable con el que sacar rendimiento al repositorio casi desde el primer minuto.
¿Te gustaría saber más acerca de lo que supuso la construcción del data lake para ISDIN? Te invito a que sigas la conversación en el episodio que le dedicamos en el podcast:
![]() |
![]() |
![]() |