Tipos de Data Products

En los últimos 3 artículos hemos hablado sobre qué es un Data Product y algunas consideraciones a tomar en cuenta a la hora de pensar en construir uno.

También hablamos de los elementos básicos que deben tener. Mencionamos algunos ejemplos específicos de Data Products, tanto los que podrían ser obvios, como los que podrían ser un poco menos evidentes.

Pensemos un poco en el flujo de datos de una empresa, desde que recibimos los datos hasta que se presentan. Un flujo muy sencillo y básico se vería algo así:

Normalmente pensaríamos en que los data products están contenidos en el paso de ‘transformación’, que es donde transformamos los datos que adquirimos de las fuentes y las preparamos para que puedan ser consumidos y presentados.

Tradicionalmente, las fuentes están a cargo de algún equipo externo al equipo de datos y la presentación está a cargo del equipo de Business Analytics.

Hemos definido ya que un Data Product se puede resumir en usar datos para lograr un objetivo y que Data as a Product es darle Product Thinking a los datos.

Así que, si pensamos de esta manera, ¿por qué no podemos considerar a cada paso del flujo de datos como una posible Data Product?

Es cierto que las fuentes de datos normalmente son administradas por equipos ajenos a equipos de datos pero eso no quiere decir que no puedan ser pensadas como un Data Product y cumplir con algunos componentes básicos como esquemas definidos y contratos de datos, seguridad, accesibilidad, etc.

Creo que es importante que dentro de tu estrategia de datos se mire a los datos end to end y no solo la parte que tradicionalmente relacionamos con productos de datos.

Podemos tener un equipo de Ingeniería de Datos y Científicos de Datos muy robusto, pero si las fuentes de datos no registran datos correctos, entonces nuestra presentación siempre estará defectuosa.

Como dicen, Garbage in – Garbage Out.

De igual forma, si la presentación de datos no se toma como un data product, entonces podemos tener muy buenos datos y modelos pero una manera de presentarla que no logre sacar todo el provecho a los datos.

Veamos un poco más en detalle los tres pasos mencionados arriba y cómo se podrían tomar como un Data Product cada paso del flujo.

1. Fuentes de datos:

Las fuentes de datos pueden ser cualquier tipo de información que recopilemos sobre nuestros clientes, operaciones, sistemas, finanzas, datos externos, etc.

Pueden venir en cualquier formato como archivos de texto, bases de datos, eventos generados por clientes, informes externos, artículos, eventos generados por sistemas internos, resultados de encuestas, reportes generados de manera offline por gente de nuestro equipo, reportes de proveedores o incluso reportes de nuestro propio equipo de datos.

Vamos a asumir que las fuentes de datos inician con un Productor de Datos. Un productor sería el que genera los datos de manera cruda.

En este punto, no podríamos considerar que esto es un Data Product, pero sí podríamos aplicar algunos principios para mantener un flujo de datos adecuado.

Por ejemplo quisiéramos que los esquemas de los datos, tanto los campos que se generan como la semántica (ej: no cambiar el valor de un campo de Dólares a Euros, que las relaciones entre elementos se mantengan constantes, etc.), tuvieran nombres consistentes y descriptivos de lo que se está midiendo, que se mantuvieran constantes y si fueran a cambiar que se notificara sobre un cambio.

Quisiéramos también que los datos fueran confiables, fáciles de descubrir y acceder, con gobernanza, etc.

Sobre todo, es muy importante que los productores de datos contengan los datos que se requieren para realizar análisis.

Por ejemplo, una aplicación que genera eventos cada vez que un usuario ve un error al intentar hacer una compra en nuestra página web podría almacenar los datos en logs que a) son difíciles de consumir, b) se borran cada 7 días y c) no contiene información de qué usuario vio el error.

Si no consideramos para qué se van a utilizar los datos y qué datos requerimos es probable que, aunque capturemos esta información, los mismos no nos sean útil para realizar análisis.

Como estos datos pueden ser generados por cualquier sistema, tanto online como offline, o cualquier persona, interna o externa, muchas veces puede ser difícil mantener la consistencia deseada y tener un estándar bien definido.

También debemos considerar que no todos los datos estarán almacenados en una base de datos. Por ejemplo, una encuesta realizada a usuarios en un focus group tendrían que ser digitalizadas y luego almacenadas.

Necesitamos considerar un componente Consumidor que capture los datos fuente y los pueda a) Estandarizar, b) Almacenar o redirigir a otros sistemas y c) Aumentar los datos cuando sea posible, según sea necesario.

En el caso de sistemas internos de la compañía, los consumidores pueden ser parte de los productores de datos.

Por ejemplo, una aplicación que permite a un usuario crear una cuenta en nuestro sitio web podría almacenar estos datos en una base de datos.

En este caso podríamos decir que el productor y el consumidor son uno mismo.

Sin embargo, si hay que considerar el componente del consumidor porque esta misma aplicación podría almacenar solamente los datos que le son requeridos al sistema para permitir a un usuario hacer login a nuestra aplicación (ej: email y contraseña) y no almacenar otros datos que nos pueden servir para hacer análisis (ej: geolocalización, tipo de dispositivo, fecha de creación de cuenta, etc). 

El consumidor en este modelo sí puede ser un Data Product como se ha descrito anteriormente y debe cumplir con todos los requisitos que hemos mencionado.

Finalmente, para poder realizar análisis debemos considerar que los datos deben ser almacenados en un sistema que luego podamos consumir.

Los datos almacenados deben ser seguros, de calidad, accesibles, con un esquema definido y que no cambie, etc.

Muchas veces los equipos de datos no tienen injerencia sobre el tipo de almacenamiento (ej: logs, bases de datos relacionales vs noSQL vs series de tiempos, archivos CSV, eventos en un broker, etc) ya que estos van a depender de la aplicación que necesita hacer uso del tipo de almacenamiento pero en lo que si tenemos injerencia es en pedir que se almacenen los datos que necesitamos para análisis, que se mantenga consistencia en los datos, que los nombres de las filas y columnas sean representativas de lo que se almacena, etc.

Si vemos todos los componentes que pueden ser parte de las fuentes de datos, aunque no todos son necesariamente un Data Product, si los podríamos considerar como uno ya que intentan resolver un problema con datos y debemos aplicar ciertas reglas.

2. Transformación:

Aquí es donde generalmente entra lo que se considera  un Data Product y lo que generalmente conocemos como un ETL (Extract – Transform – Load) ya que vamos a extraer los datos de las fuentes, transformarlas y almacenarlas (o reenviarlas) nuevamente.

En este paso los equipos de datos si que tienen injerencia sobre lo que se debe realizar, cómo y para qué.

Dependiendo del tipo de datos de la fuente, el paso de transformación se podría saltar.

Por ejemplo, si la fuente de datos son eventos generados en la página web por una librería de recolección de datos, los datos podrían ir directamente a una aplicación final de Product Analytics y ser transformados y modelados en la herramienta.

Estos eventos también se podrían almacenar y pasar por el paso de transformación si así se requiere. 

Es importante que en la fase de transformación se tome en cuenta quiénes serán los consumidores de los datos para poder modelar, reenviar y almacenar los datos de manera que sean fácilmente consumibles por los consumidores.

Es importante hacer un trabajo de descubrimiento para entender tanto el objetivo del modelo como el uso final que se le dará.

Dentro del paso de transformación, a mi me gusta dividirlo en tipos de modelados diferentes.

El primer paso es el de limpieza y preparación.

Este paso es donde podríamos extraer los datos de las fuentes, quitar los datos que no nos sirvan, agregar metadata que sea necesaria, unir los datos que tengan relación entre ellas, normalizar los nombres de los campos (si no se hizo en las fuentes, que es lo más aconsejado) y hacer el primer paso de validaciones antes de correr más análisis.

En muchos casos, la limpieza y preparación está incorporado al segundo paso pero si lo haces como un paso independiente puedes reutilizar estos modelos.

El segundo paso es generar Modelos Descriptivos.

Estos modelos son generados para modelar ciertos escenarios que se quieran analizar y  simplificar el consumo de los datos y generalmente sirven para generar reportes, visualizaciones o análisis ad-hoc.

Lo ideal es tener un modelo de datos limitado a un caso de uso específico.

Por ejemplo, podríamos tener un modelo para ver a clientes, otro para ver transacciones, otro para ver resultados financieros, uno para datos de servicio al cliente, uno para el equipo de contabilidad, etc.

Los modelos son una representación real de lo que está ocurriendo y no intentan predecir.

Dependiendo de la madurez de tu arquitectura de datos es posible que no tengas un modelo limitado pero la idea es hacerlo lo más granular posible.

Los modelos descriptivos pueden tener también modelos derivados que tengan datos agregados (ej: suma de todas las transacciones agrupada por ciertos criterios vs un registro por cada transacción con todos los criterios disponibles) para que el consumo por usuarios finales sea más fácil.

Finalmente, podemos generar Modelos Predictivos usando técnicas de Machine Learning e Inteligencia Artificial.

Los modelos predictivos se pueden beneficiar de usar los modelos descriptivos ya que estos modelos ya describen la historia y se agrupan por datos comunes.

Los modelos predictivos también se alimentan de sí mismos para aprender y mejorar la calidad de la predicción.

El propósito de los modelos predictivos es intentar entender qué podría ocurrir en el futuro.

Ejemplos podrían ser modelos que predicen resultados financieros, cómo van a usar nuestro producto un grupo de usuarios, Liftetime value de clientes potenciales, predecir qué usuarios no van a seguir usando nuestro producto, control de inventarios, control de precios, etc.

El resultado de estos modelos pueden ser usados para generar estrategias para mejorar nuestros productos y resultados, para usar en campañas de marketing, predecir qué productos debemos tener en stock, predecir visitas a nuestras tiendas, etc.

Los modelos predictivos muchas veces son los últimos en generarse.

Primero debemos poder describir y entender lo que está pasando y luego podemos predecir.

Es bueno pensar en que los modelos descriptivos pueden ser entradas a los modelos predictivos y modelarlos con esa consideración.

3. Habilitación:

El último paso del flujo es permitir habilitar el uso de los datos que fueron modelados o recolectados.

Nuevamente, podríamos debatir si este paso también debería ser considerado un Data Product y ahora vamos a intentar explicar por qué si los debemos considerar como tales.

La parte de habilitación generalmente está compuesta por dos partes: Herramientas y personas.

Las herramientas pueden ser cualquier producto que nos permita consumir los datos.

Algunos ejemplos aquí pueden ser herramientas de visualización como Tableau o Looker, herramientas de Product Analytics como MixPanel o Amplitude, herramientas de Marketing como Google Ads, Facebook Ads, Salesforce Marketing Cloud o Airship o bases de datos que almacenan el resultado de los modelos.

Estas bases de datos sí están en control del equipo de datos y se puede elegir una que satisfaga las necesidades de los equipos de Ingeniería y de Business Analytics.

¿Por qué podríamos considerar estas herramientas como Data Products dentro de la empresa?

Por las mismas razones por las que consideramos a las fuentes como Data Products.

Aunque, generalmente, no podemos modificar las herramientas, si debemos asegurarnos de elegir las herramientas correctas para el trabajo que queremos hacer.

Debemos recolectar y modelar los datos de manera que sean compatibles con nuestras fuentes y modelos.

Por ejemplo, si vamos a usar Tableau para visualizar datos tenemos que asegurarnos que los modelos sean almacenados en un formato permitido por Tableau.

También debemos considerar cómo se diseñan los modelos para que funcione Tableau adecuadamente y sin problemas de rendimiento.

Si vamos a usar una herramienta como MixPanel para hacer Product Analytics, tenemos que asegurarnos que los datos que estamos recolectando puedan ser utilizados correctamente en MixPanel.

Todas estas herramientas se deben elegir en base a los datos que recolectamos, los modelos que tenemos y, sobre todo, las necesidades específicas de los clientes finales.

Es importante que haya un dueño empoderado que pueda elegir las herramientas correctas, coordinar la integración de los datos con las mismas, documentar y evangelizar sobre su uso, ser capaz de resolver errores e iterar sobre cualquier mejora, configurar las herramientas para que sean utilizables por usuarios finales.

Si vemos este listado de requerimientos, es muy parecido al que definimos para un data product.

Tiene que ser descubrible, accesible, con contratos y metadata, limitado en alcance, confiable y bien gobernado.

El modelo de data product es un poco distinto aquí, pero internamente lo podemos considerar como un Data Product que necesita un dueño y un plan a futuro.

De nada nos sirve recolectar buenos datos y tener buenos modelos si las herramientas de consumo no son las adecuadas o no funcionan como es de esperar.

Si los datos no llegan de manera correcta a las herramientas, podemos cometer errores iguales de grandes que cuando el modelo es incorrecto.

El otro aspecto de la habilitación de datos está en las personas que van a consumir los datos.

Aquí podemos pensar en analistas que hacen consultas, product managers que generan dashboards en herramientas de product analytics, mercadólogos que generan segmentos para mercadeo, analistas de cualquier área que necesitan hacer self-service y cualquier persona que quiera usar todas estas herramientas para hacer insights y storytelling.

Nuevamente, es importante que este segmento también se tome en cuenta como data product.

Un usuario generando un dashboard, un reporte, una lista de usuarios o un segmento para mercadeo debe considerar muchos de los mismos aspectos de un Data Product.

Si no lo hacemos así, los reportes finales pueden tener errores o la interpretación de los datos puede ser incorrecta.

Pensemos en una consulta SQL o un tablero de visualización. Ambos deberían ser fáciles de entender, modificar y desplegar.

Usuarios finales deberían ser capaces de descubrir y acceder a los resultados, los esquemas de los datos no deben cambiar de tablero a tablero o de una versión a otra, y deben pasar por controles de calidad.

Aunque estos no son Data Products tan sofisticados como los que se pueden encontrar en las fuentes y modelos, si deben cumplir con las mismas reglas para ser útiles, independientes y escalables.

Si vemos todo esto en un esquema un poco más completo al descrito al inicio del artículo, se vería algo así:

Este esquema es una representación muy básica de cómo se podría ver el flujo de datos en tu empresa.

Puede ser tan simple o tan sofisticada como quieras, dependiendo en dónde estés en la madurez de tu estrategia de datos.

Es bueno que antes de empezar tu estrategia de datos te sientes a pensar en cómo se puede ver este diagrama, qué quieres implementar, cómo y cuándo y usar esto como tu punto de partida para empezar a construir tus productos de datos.

Es importante que todos los pasos del flujo de datos sean considerados como Data Products.

Queremos asegurarnos que tengamos un flujo confiable, que los datos sean precisos, que sean fáciles de interpretar, que el flujo no se rompa por cambios de esquema, etc. y la única manera de asegurarnos es interpretar todos los pasos como si son un Data Product.

The post Tipos de Data Products first appeared on KVERGE.