Translate

lunes, 11 de mayo de 2020

Eligiendo como visualizar el análisis de datos en 🐍 Python para EDA usando pandas

Hace unos días, me di cuenta que necesitaba una forma de visualizar datos para Adhoc análisis y EDA.
Siempre he sido bastante reacia a perder el tiempo haciendo gráficos en matplotlib porque me parece muy complicado el disenno.

Pero, tras haber perdido parte del código que usaba en Python para hacer todo más rápido por no subirlo a Github, me he dado cuenta de que necesito esto.


Primero vamos a ver que tipo de librerias tenemos en Python que podemos usar en Jupyter Notebook

  • matplotlib
  • Seaborn
  • bokeh
  • plotly
  • cufflinks (plotly + pandas)


matplotlib

 Es la libreria por antonomasia para usar con Pandas.

Seaborn

Basada en matplotlib tiene automatizados muchos gráficos para hacerlos de forma más sencilla. La parte negativa es que no es interactiva

bokeh

La sintaxis y el modelo, no tiene nada que ver con las dos anteriores. Así que hay que aprenderla desde cero. Como puntos destacados puedes exportarse para usarse con JS y es interactiva, eso significa que puedes hacer dashboards con los que se pueden seleccionar variables por ejemplo.

plotly

Es una librería propietaria, pero permite hacer muchos gráficos. Tiene buena usabilidad, así que no necesitas aprender mucho código y la documentación es muy buena. Hay una versión de pago, así que no es totalmente libre. Sería como el debian de las librerias de visualización de datos en Python.

viernes, 1 de mayo de 2020

Segmentando clientes en Python usando el modelo RFM

 Ya en 2016 escribía un post sobre el modelo RFM de segmentación de clientes, para qué servía o qué preguntas podíamos responder y cómo se podía hacer una sencilla consulta en SQL para conseguirlo.
Cinco annos más tarde puedo decir ya con bastante más experiencia que estos datos 
  • 'Recency
  • Frecuency
  • Monetary Value
no se encuentran tan facilmente en las empresas en las bases de datos. Así que para empezar nos va a tocar pasar bastante tiempo limpiando los datos. El modelo sigue siendo utilizado para la segmentación de CRMs y nos va a dar buenas pistas de los usuarios en lo que debemos que poner más atención ya que son nuestros mejores usuarios. 
También podemos usar el mismo modelo para ver que clientes nos han abandonados o qué clientes están inactivos y potencialmente podemos volver a activar. Email Marketing preparado.
Para esto hay diferentes formas de hacerlo. Aquí voy a tirar del usor de percentiles ya que es una de las formas másfáciles de calcular ya que tenemos funciones para ello y además de las que mejor resultado tienen.

Qué formato tienen que tener nuestros datos

Para poder realizar este análisis vamos a necesitar datos de forma transaccional. Es decir por cada acción que haga nuestro usuario como por ejemplo una compra de ecommerce, vamos a tener una línea. Estas transacciones normalmente tienen un ID Además vamos a necesitar que al hacer esa transacción también se guarde un id de cliente. Siempre es más fácil trabajar con numeros y id que con nombres, pero esto último lo podemos arreglar al limpiar los datos antes del analísis. Así que no cunda el pánico.

Para no hace muy largo este post voy a poner un ejemplo con código de la parte de frecuency y recency para poner labels a nuestros usuarios en función de estas dos variables. Así podremos saber en qué fase están nuestros clientes inactivos, activos, engaged, nos abandonado (churn). Estos nos va a ayudar a crear algunas métricas como el churn rate. Qué porcentaje de clientes no vuelven a comprarnos.

Etiquetar a nuestros clientes

Un ejemplo de como podemos etiquetar a nuestros clientes es
- Activos - Active
- Inactivos - Inactive
- Abandonado - Churn


Para llevar acabo el analisis completo de RFM, aquí puedes acceder a un script donde la analista usa también los percentiles. Así que va más allá de lo explicado aquí con la creación de etiquetado.
En este Jupyter Notebook además comenta con bastante detalles que preguntas hay que hacerse para limpiar los datos y qué decisiones toma en base a como están los datos.





lunes, 6 de abril de 2020

User story - historia de usuario - en Metodologias Agiles

Qué son las User stories o historia de usuarios
Las User Stories son artefactos usados en Scrum, el framework más usado en Agile o Metodologías Ágiles.

Para qué se usan la user story en Agile
En Agile, siempre se intentan descomponer las tareas en unidades más pequenas. Las historias de usuario suponen la parte más pequena en la que trabajar en un producto o feature.

Cómo se crean historia de usuarios
Normalmente este siguen el siguiente esquema

“Como [ tipo de usuario ] 
necesito/quiero [ el qué ] 
así puedo [ beneficio ]”

Por qué usar historias de usuarios para definir nuestras tareas
Con esta sentencia ponemos al usuario en el centro de nuestras tareas tratando de resolver un problema que el usuario tiene por encima de lo que nosotros creamos que es mejor o más fácil de hacer

He creado algunos ejemplos de historia de usuarios en github qué puedes visitar aquí

lunes, 23 de diciembre de 2019

Trabajar en Agile o metodologías Ágiles

Cada uno tiene su historia y

De cómo Agile llegó a mi vida

Hace un par de años empecé a trabajar en el Gobierno Británico. Ya conocía GDS por diferentes cursos que había hecho sobre Experiencia de Usuario y porque siempre me ha interesado el tema de la colaboración como Socióloga que soy la psicología social siempre me ha fascinado.

También conocía de oídas Agile y las metodologías Ágiles. Como analista digital siempre me ha tocado mi parte de project management y negociación. Al estar en el centro del negocio nos toca lidiar con todo tipo de stakeholders e influenciar a los programadores o techies para que hagan los cambios que necesitamos. Sin ellos no samos nadie. Así que desde que empecé en digital esto soy una ferviente leedora de blog y libros de como ser más productivos y suelo guardar los mejores artículos aquí  https://www.scoop.it/topic/productividad-y-tic,

Pues bien, el papel de transformación digital en GDS no puede entenderse sin Agile. Tengo que decir que al principio me costó pillar que estábamos haciendo y por qué trabajábamos así. Sin embargo ahora me he dado cuenta que la visión de Agile en la creación de software es la correcta. Entiendo que a las empresas les pueda dar un poco de miedo este cambio, sin embargo, cada vez que hablo con otros compañeros del sector que siguen trabajando con otras metodologías me reitero que Agile es la forma adecuada de trabajar para crear productos digitales - desarrollo de software.

De que va todo esto de Agile...


  • De entrega rápida de software, en vez de mega proyectos que nunca se terminan (te suena...)
  • De Trust o confianza y mucha transparencia. Hay mucho de psicología social y sociología en todo esto para los miembros de la empresa. 
  • De tener en cuenta a los usuarios para darles lo que necesitan, adaptando el producto a sus necesidad en vez de que ellos se adapten al producto. Al fin y al cabo vivimos en un mundo cada más global donde la competición es cada vez más grande y los productos están en constante evolución.


Y si lo pensamos, asi es como deberia ser. Deberiamos confiar en nuestros jefes, en nuestros compañeros de equipo y en las personas que tenemos a nuestros mando. Una vez que todo esto se ha conseguido, todo va como la seda. Pero hasta que llegamos allí va a un largo camino y para ello alguien debe velar por que esto se pueda hacer y que esa confianza no se rompa.

Ya había comentado que Agile es una metodología, pero seguro que habrás oido hablar de Scrum, Lean ,de Kanban, de poner al usuario en el centro,... .Ahí un va un poco de luz a todo esto.

Agile es una metodología. Todo empezó con un manifiesto,aquí puede leer los principios del manifesto en inglés.Y  aquí puedes leerlo en castellano.
Sin embargo aunque esos principios no han ido cambiando con los años, si que se lo ha hecho como utilizarlos.

Dentro de Agile podemos encontrar dos frameworks ampliamente usados- Scrum (el más usado y más reglado) y Kanban. Sí, a mi también me sonaba a chino.


viernes, 6 de diciembre de 2019

MVCC - multiversion concurrency control en base de datos

Hace unas semanas me pasó un marrón considerable. Fui a sacar dinero al cajero y úna vez puestos mis 400 euros, el cajero me dió un error y suspendió la transacción. Así que como yo quería mi dinero volví a repetirlo todo y esta vez si obtuve m dinero.
Cual es mi sorpresa cuando miro en la APP que había sacado dinero dos veces.

Seguido de un sudor frio y un ahora qué

Empecé a imaginarme tener que llamar  a mi banco, al cajero, a mi cuenta de Reino Unido, a ver como explico yo que estaba diciendo la verdad y nada más que la verdad. Joder 400 euros, es una pasta eh. Y no tengo testigo. A ver si le da mi dinero al segundo que llegue... overthinking

Y al llegar a casa y llamar al banco, me dicen que todo esta bien y que ese dinero esta en mi cuenta. 
Pero, sennorita, que yo lo he visto con mis ojos. Y ella, pues vuelve a mirar. Tachán ahí estaba.

Acaso he entrado en un agujero del tiempo del camino del banco. Nota mental - Dark y Rick y Morty me están afectando seriamente.

Pues no, tiene pinta que ha sido tema MVCC.  Y aquí ya hay que ponerse un poco nerd.

Qué es el MVCC

El control de concurrencia mediante versiones múltiples (Multiversion concurrency control o MVCC) es un método para control de acceso generalmente usado por SGBDs para proporcionar acceso concurrente a los datos, y en lenguajes de programación para implementar concurrencia.
En la wikipedia tienes más información  https://es.wikipedia.org/wiki/Multiversion_concurrency_control

Para que sirve el Multiversion concurrency control

Pues para que no pasen errores como el mio. Yo pedí sacar un dinero y seguramente hubo un timeout en medio de la query. Al usar el banco de otra sucursal en mi app salió como que ya había cogido ese dinero. Entonces miré en la app, y mi dinero había desaparecido. Más tarde el cajero del banco mandaría un código de error como que no se había completado la transacción. Así que la base de datos de mi banco volvió al estado anterior, es decir no completó esa transacción.

Mmmmmm todo tiene sentido ahora. Y oye, esto es bastante importe porque estas cosas pueden pasar varias veces al día. 

Cómo funciona el control de concurrencia mediante versiones múltiples

La verdad, es que el tema es un poco complicado de explicar con palabras, así que lo mejor es tirar de diagramas. Dejo aquí un artículo que lo explica muy bien. 

En que bases de datos se puede dar el MVCC


lunes, 18 de noviembre de 2019

Como calcular la mediana en SQL


La mediana es una médida de tendencia central que nos va a ayudar a abrir los ojos cuando nos encontremos con datos que puedan estar sesgado. Es como una media aritmética mejorada para casos en los que los datos no parezcan una montannita.

Así que antes de ponerte a calcular la media de algo, deberías visualizar que forma tienen estos datos.  Si ya has decidido que la media no te sirve o simplemente quieres comparar la media y la mediana y no sabes como calcular esta última
     
Primero, la parte fácil.

Como calcular la media de una columna en SQL

AVG(columna)

Ejemplo

SELECT AVG(columna) FROM tabla

Como calcular la mediana de una columna usando SQL

Aquí la cosa ya se complica un poco más. Así que tenemos que tirar de definición de mediana.
percentile_disc(0.5) WITHIN GROUP (ORDER BY columna) AS mediana
Vamos a desmenuzar que es lo que estamos haciendo:

La mediana es el igual al percentil 50, es decir lo que queda justo en la mitad de todos nuestros datos. Esto ya explica el percentile_disc y el (0.5)

Otra cosa que tenemos que tener en cuenta es que para calcular la mediana necesitamos tener ordenados nuestros datos por ellos vamos a usar el ORDER BY.

Finalmente, queremos renombrar la columna como mediana. Así que AS mediana

Ejemplo práctico con media y mediana eb una sentencia SQL

SELECT categoria,
      avg(precio) AS media,
       percentile_disc(0.5) WITHIN GROUP (ORDER BY precio) AS mediana
  FROM producto
 GROUP BY categoria
 ORDER BY avg(precio);

viernes, 1 de noviembre de 2019

📊 👨‍👩‍👧‍👦 DataOps Manifesto - Cuando mezclas Data y Agile en un equipo



En mi último equipo tuvimos que encargarnos de hacer desde cero todo el sistema de reporting de la unidad, desde la investigación de nuevas métricas usando metodologías user experience research como entrevistas y focus group a crear todo el sistema de eventos en AWS, la ETL pipeline y el dashboarding y reporting en Python. Y todo esto usando metodologías Agile. No veas que converaciones teniamos más frikis de vez en cuando sobre métricas, calidad de los datos y performance.

Yo por mi parte además me llevaba muy bien con el depatamento de Devops o Reliability Engineering que eran los que usaban Kubernetes, Dockers y bases de datos, y todo lo que tenía que ver con PaaS (Platform as a Service). Y uno de mis compas le encantaba explicar lo que aprendía sobre analytics y tenía super paciencia al explicarlo. Eso me llevó a aprender sobre la existencia de balanceadores, la posibilidad de tener el backup en dos ´nubes´ diferentes o el reporting en Prometheus

Como firme defensora de trabajar en Agile en equipos multidisciplinares y diversos hay una cosa que no me terminaba de encajar al principio. Explicar a los programadores que había que testear los datos y que la definition of done no era la misma para los analistas que para los programadores nos trajo al equipo muchos dolores de cabeza y conversaciones metafísicas. Y mucho ensayo-error hasta encontrar la mejor metodología, donde tanto analistas como ingenieros tuvieramos nuestros requerimientos requeridos.El mayor problema era que tras meses implementando algo y darlo por finalizado, debíamos mejorarlo, o las necesidades de los usuarios cambiaban o nos mandaban hacer un análisis adhoc. Todo esto significó que tuvimos que aprender a trabajar juntos, y a su vez desaprendimos a trabajar como lo haciamos antes. Eso es lo bonito de Agile.

Y si llevamos todo mi largo comentario a metodología de Big Data e Inteligencia Artificial y la posiblidad de hacer todo esto en la nube podemos encontrarnos que este problema lo van a tener todas las empresas Data-Driven. Son mucho los equipos de desarrollo de software que se encuentran en esta tesitura, y por ello sólo era cuestión de tiempo que apareciera un nuevo manifiesto - DataOps.

DataOps o DevOps

DataOps toma la forma de su primo los DevOps, y lo que pretenden es que se integre esa mejora continua en los datos, mejorando así además la calidad de estos. Así que no, no se dan por finalizadas las tareas tan facilmente como ocurre en otros equipos de software, igualmente que los DevOps tienen que mantener operativa la plataforma 24/7. Como comenta IBM en su artículo en Data y Analytics hay una gran diversidad que operaciones a realizar y aunque todos sean con data, requieren de diferentes procesos y herramientas. (´Big Data Workloads are Diverse.´)

El DataOps manifiesto en castellano

El manifiesto empieza al igual que el Agile Manifiesto con las siguientes afirmaciones

  • Personas e interacciones en lugar de procesos y herramientas
  • Soluciones de analítica eficientes en lugar de documentación comprensiva
  • Colaboración con el consumidor en lugar de negociaciones contractuales
  • Experimentación, interacción y retroalimentación en lugar de un diseño extensivo directo
  • Titularidad multidisciplinar de las operaciones en lugar de responsabilidades aisladas.
La traducción del manifiesto la puedes encontrar en el siguiente enlace, cuenta con 18 puntos que van desde la formación de los equipos, a la calidad de los datos y la necesidad de procesos de retroalimentación para la mejora continua. Están bastante claros, así que no vale la pena que los detalle aquí.
https://www.dataopsmanifesto.org/dataops-manifesto.html?lang=es .

Métricas para medir el Performance de tu equipo de Analítica o Data team

Este video explica alguna de las métricas que se pueden usar para medir el éxito del esfuerzo del equipo
https://www.youtube.com/watch?v=Ch4gJz3n8qw&list=PLVbsAdgZXvtyy6HVKCP0HChjCcq2oW3eK&index=18&t=0s

Más información para ampliar 

https://en.wikipedia.org/wiki/DataOps
https://www.gartner.com/en/newsroom/press-releases/2018-09-11-gartner-hype-cycle-for-data-management-positions-three-technologies-in-the-innovation-trigger-phase-in-2018
https://www.ibmbigdatahub.com/blog/3-reasons-why-dataops-essential-big-data-success
Canal youtube sobre DataOps
https://www.youtube.com/playlist?list=PLVbsAdgZXvtyy6HVKCP0HChjCcq2oW3eK