Diseñando un Data Product: factores a tener en cuenta para hacerlo con éxito

Considerar Data Products (o Productos de Datos) como soluciones está siendo un factor competitivo diferenciador que algunas empresas están empezando a experimentar. La reducción de costes por uso de estos productos o el mayor retorno de inversión están permitiendo la popularización de este concepto.

En este artículo nos proponemos revisar los factores más relevantes que han de considerarse en el momento de la definición de un Data Product, pero primero recordemos este concepto. 

Consideraremos como Data Product aquel cuyo principal objetivo sea utilizar los datos disponibles para facilitar el alcance de un objetivo final. Este tipo de soluciones han de contener la información suficiente para entender los datos que maneja y la utilización que se les puede dar para solventar un caso de uso en un dominio específico.

Por este motivo, no consideraremos a Netflix como un Producto de Datos, ya que su objetivo no es puramente analítico, pero sí su recomendador de películas o series.

Antes de lanzarnos a definir un nuevo Producto de Datos tendremos que plantearnos algunas preguntas tales como si alguien va a necesitar o utilizar nuestro producto, qué decisiones o consideraciones pueden tomarse a partir de su uso, qué acciones pueden implicar y cómo van a medirse los resultados derivados de tales acciones.

Las estadísticas nos demuestran que muchos Productos de Datos quedan en standby en sus últimas fases o bien una vez desplegados.  Entre ellos, también nos encontramos con algunos que aportan escaso o nulo valor analítico o bien son fallidos.

Estos son algunos de los motivos que nos llevan a considerar la relevancia de la fase de definición de un Data Product y seguimiento de algunas buenas prácticas que nos permitan construir Productos de Datos exitosos.

¿Por dónde empezar a construir un Data Product?

Como la mayoría de cosas, proponiendo lo más simple y tratando de mantenerlo así el máximo tiempo posible.  Si en el momento de la definición lo complicamos en exceso, acabará siendo un producto sin posibilidades de desarrollo, evolución o amigable para sus usuarios.

En estos primeros momentos planteamos qué queremos que el usuario de nuestro Data Product obtenga cuando lo utilice, qué acciones puede llevar a cabo con la información recibida y cuál es la experiencia que el usuario tendrá durante y posterior uso del Producto.

Si conseguimos construir un Producto exitoso, podremos centrar nuestros esfuerzos posteriormente en evolucionarlo y añadirle funcionalidad más sofisticada.

¿Cómo será el proceso?

Inicialmente el equipo responsable del desarrollo deberá formular con Negocio el problema en términos de valor analítico y cómo podrá medirse este valor de forma efectiva en el dominio en el que se implemente. Este factor será clave para determinar si el producto será finalmente un éxito.

Con este punto de partida, será conveniente llevar a cabo una prueba de viabilidad en el que se pueda validar la propuesta en términos de necesidades de negocio.

A continuación se deberá tener presente para la implementación los distintos tipos de usuarios y de qué forma pueden interactuar con el producto. Para ello es recomendable definir un modelo conceptual que contemple el uso de los datos en las distintas interfaces tales como APIs, Dashboards u otros.

Un posterior refinamiento permitirá definir un modelo físico más detallado que además contemple los metadatos suficientes para su entendimiento.

Tras su despliegue y puesta en marcha el Producto de Datos estará diseñado para facilitar su evaluación y evolución durante su ciclo de vida mediante la interacción con los usuarios.

¿Qué características debería tener un Data Product?

Entre las características más importantes que podemos considerar en la definición de un Data Product están las siguientes:

• Utilidad: No perder de vista el uso que pueda dar un usuario al Producto de Datos independientemente del esfuerzo que sea necesario realizar para mantener los datos actualizados y preprocesados. Un producto que no se utiliza no aporta valor.
• Escalabilidad: Los productos exitosos son usualmente sobre utilizados y las fuentes de datos suelen aumentar en tamaño y en número con lo que tener en cuenta esta situación es clave para su futuro desempeño.
• Potencial: Para medir su efectividad habrá que determinar métricas que permitan evaluar su resultado, tales como por ejemplo la “precisión” y “recall” en un posible motor de recomendación. Asumir que el producto de datos fallará y cómo preservar la experiencia del usuario en esos casos es un aspecto a tener en cuenta.
• Coleccionar datos de forma pasiva: Recoger datos del usuario sin interferir en su experiencia de uso es importante para proporcionar un valor añadido. Es el caso de los acelerómetros o gps en los smartphones, por ejemplo.
• Validación constante del performance: Acumular métricas históricas habilita la implementación de tests A/B que permiten evaluar la variación entre distintas versiones de un producto y la toma de decisiones más informadas. Un modelo que actualmente funciona es posible que no siga haciéndolo en el futuro, por eso se ha de monitorizar la evolución de estas métricas y revisar su degradación o mejora.
• La transparencia genera confianza: El usuario puede ser escéptico a los resultados del producto, por lo que información adicional al resultado en forma de probabilidades, scores de confianza o atributos que más contribuyen a una inferencia pueden significar la diferencia entre un producto confiable o cuestionable.
• Ágil en su actualización:  Existen Data Products que son susceptibles de actualización contínua ya que puede significar una diferencia competitiva esta cualidad. En tales casos haciendo “deploy” de versiones regularmente con nuevas “features” de forma segura y diligente impactará positivamente en la experiencia del usuario.

Pero también existen atributos indeseables en un Producto de Datos que pueden generar desconfianza en el usuario o una mala experiencia. Es el caso por ejemplo de un producto que proporciona información errónea o de escasa calidad. En ocasiones, no implementar las suficientes validaciones referentes a la calidad del dato pueden llevar a que los resultados sean confusos o erróneos lo que potencialmente podría generar grandes pérdidas. Luego la calidad del dato en los datasets gestionados por estos Data Products se convierte en una prioridad para sus responsables.

Otras situaciones poco recomendables son las que se producen cuando un producto genera información ingente de datos (data vomit). Dependiendo del perfil del usuario puede ser que no sea la mejor forma de presentar la información de interés y que ésto desemboque en una situación paralizante.

En definitiva, definir y desarrollar un Data Product con garantías de éxito requiere de una planificación cuidadosa, una correcta implementación supeditada a la utilidad y experiencia del usuario, y un testeo y monitorización contínuos que permitan la evaluación contínua de su performance.