Business Payments, una empresa de servicios financieros de vanguardia, ha estado ofreciendo soluciones innovadoras de adelanto de efectivo desde su creación en 2020. Con un compromiso de proporcionar adelantos de dinero gratuitos y precios transparentes, Business Payments ha logrado construir una base de usuarios sólida. Como parte de su esfuerzo continuo por mejorar sus servicios y entender el comportamiento de los usuarios, Business Payments encargó este proyecto a nuestro equipo para realizar un análisis avanzado de insights y cohortes.
Equipo:
- Cristian Largo Reina
- Albert Bañeres Rovirosa
- Elvis Ortega Ochoa
Se puede ver la organización y planificación de las tareas del equipo en la pestaña Projects --- https://github.com/elvisortegaec/businessPayments/projects
En este proyecto, se realizó una extracción de insights accionables, un análisis avanzado de cohortes y una segmentación de datos exhaustiva proporcionada por Business Payments. El objetivo principal fue analizar cohortes de usuarios relevantes, definidas según el período en el que realizaron su primer adelanto de efectivo. Además, se seguió la evolución temporal de métricas clave para estas cohortes y se propuso insights relevantes, así como modelos de regresión y clasificación, que permitirán a Business Payments obtener valiosas perspectivas sobre el comportamiento de los usuarios y el rendimiento de sus servicios financieros.
Este es un informe resumido de los hallazgos clave del análisis exploratorio y de calidad de datos, así como los insights obtenidos, diseñado para los stakeholders de Business Payments.
A continuación se presenta el análisis de cada una de las bases de datos, enfocándose en los valores faltantes. Como se puede observar, no hay registros duplicados, pero sí hay datos faltantes en ambas bases de datos.
Graficamente los valores faltantes en extract - cash request - data analyst se puden observar de la siguiente manera:
Graficamente los valores faltantes en extract - fees - data analyst se puden observar de la siguiente manera:
Soluciones
-
Se comprobó que la columna
idde la primera base de datos corresponde a la columnacash_request_idde la segunda base de datos. En este sentido, se decidió fusionar las dos bases de datos considerando estos campos como equivalentes. 2913 registros de cash request no tienen un valor fee asociado. Dado que los datos no asociados no son de interés para el análisis de las métricas, se decidió tomar en cuenta solo los registros de cash request que tienen un registro de fee asociado. Por otro lado, dado que las columnasid,created_atyupdated_attienen el mismo nombre en ambas bases de datos, se decidió añadir el sufijo_feea todas las columnas de la segunda base de datos, exceptocash_request_id. -
Se verificó que los valores nulos de
user_idcorresponden a los valores dedeleted_account_id. En ese sentido, se rellenaron los valores nulos enuser_idusandodeleted_account_id. Se recuperaron 906 datos perdidos enuser_id. -
Consecuentemente, fue necesario convertir el tipo de datos de las columnas de interés a tipos que faciliten el manejo de los datos en las métricas. Las columnas
created_atycreated_at_feese cambiaron de tipo de datos de objeto a tipo de fecha. A partir de ese formato, se crearon dos nuevas columnas,cohortymonth, con la finalidad de facilitar en análisis de datos por cohortes y meses, tanto de las fechas de creación de las solicitudes de dinero como de las tasas aplicadas. -
Seguidamente, se procedió a documentar el proceso para completar los valores faltantes. A continuación, se presentan los códigos que se usaron para completar los valores faltantes en las columnas mencionadas, seguido de una explicación. La explicación se tomó de Lexique - Data Analyst.xlsx. En los casos en que aparece un signo de interrogación en la explicación, es porque no se ha encontrado una justificación para los datos faltantes; consecuentemente, se completaron los datos con "Null". Dado que esos campos no son de utilidad en los futuros análisis, no fue necesario implementar otra estrategia.
Códigos para información faltante basados en Lexique - Data Analyst.xlsx:
| Nombre de la Columna | Código | Explicación |
|---|---|---|
| moderated_at | 98 | No necesita una revisión manual |
| deleted_account_id | 98888888 | No hay cuenta eliminada |
| cash_request_received_date | 98 | No se envió un débito directo SEPA |
| money_back_date | Null | ? |
| send_at | Null | ? |
| recovery_status | 98 | La solicitud de efectivo nunca tuvo un incidente de pago |
| reco_creation | Null | ? |
| reco_last_update | Null | ? |
| category_fee | 98 | No incident |
| paid_at_fee | Null | ? |
| from_date_fee | 98 | No hay tarifas pospuestas |
| to_date_fee | 98 | No hay tarifas pospuestas |
Evaluación de la calidad de los datos para cleaned_merged_cash_request_fees.csv
Valores faltantes en cleaned_merged_cash_request_fees.csv:
id: 0amount: 0status: 0created_at: 0updated_at: 0user_id: 0moderated_at: 0deleted_account_id: 0reimbursement_date: 0cash_request_received_date: 0money_back_date: 1356transfer_type: 0send_at: 3487recovery_status: 0reco_creation: 14163reco_last_update: 14163id_fee: 0cash_request_id: 0type_fee: 0status_fee: 0category_fee: 0total_amount_fee: 0reason_fee: 0created_at_fee: 0updated_at_fee: 0paid_at_fee: 5526from_date_fee: 0to_date_fee: 0charge_moment_fee: 0
Filas duplicadas en cleaned_merged_cash_request_fees.csv:
- 0
Graficamente los valores Null en cleaned_merged_cash_request_fees se puden observar de la siguiente manera:
Resultados del análisis exploratorio de los Datos, utilizando diversas gráficas para representar la distribución, explorar relaciones entre variables y detectar valores atipicos que requieran una investigación específica.
Visualizamos la variable Recovery status:
Inicialmente realizamos un grafico de barras de la variable Recovery Status para ver su distribución ya que es la que queremos predecir inicialmente:
La mayor parte de los valores se encuentran como que nunca se ha recibido ninguna incidencia sobre ese cash request
*Sobre los otros posibles valores, se indica si una vez creada la incidencia se ha completado, pendiente, cancelada o pendiente pero con una transferencia SEPA en proceso.
Análisis Univariado
| Variable | Count | Mean | Std | Min | 25% | 50% | 75% | Max |
|---|---|---|---|---|---|---|---|---|
| id | 21057 | 16318.45 | 6656.15 | 1456.00 | 11745.00 | 17160.00 | 21796.00 | 27010.00 |
| amount | 21057 | 81.83 | 26.95 | 1.00 | 50.00 | 100.00 | 100.00 | 200.00 |
| deleted_account_id | 21057 | 94634827.00 | 20063077.00 | 3857.00 | 98888889.00 | 98888889.00 | 98888889.00 | 98888889.00 |
| id_fee | 21057 | 10646.67 | 6099.14 | 1.00 | 5388.00 | 10654.00 | 15926.00 | 21193.00 |
| cash_request_id | 21057 | 16318.45 | 6656.15 | 1456.00 | 11745.00 | 17160.00 | 21796.00 | 27010.00 |
| total_amount_fee | 21057 | 5.00 | 0.03 | 5.00 | 5.00 | 5.00 | 5.00 | 10.00 |
| time_diff | 21057 | 8327430.00 | 3754475.00 | 24.34 | 5172280.00 | 7416928.00 | 11060680.00 | 23307870.00 |
amount tiene un comportamiento sesgado hacia valores altos (mediana en 100). Esto podría afectar la predicción y merece exploración.
total_amount_fee parece una variable discreta con un rango pequeño (5-10), lo que la hace menos informativa.
time_diff tiene una variación significativa y podría ser clave en la predicción si se relaciona con recovery_status.
Variables categóricas
| Status | Frecuencia |
|---|---|
| money_back | 18,918 |
| direct_debit_rejected | 1,858 |
| active | 155 |
| direct_debit_sent | 72 |
| transaction_declined | 48 |
| canceled | 6 |
| User ID | Frecuencia |
|---|---|
| Null | 906 |
| 16391.0 | 37 |
| 15593.0 | 28 |
| 3045.0 | 25 |
| 17144.0 | 24 |
| ... | ... |
| Charge Moment Fee | Frecuencia |
|---|---|
| after | 16,720 |
| before | 4,337 |
Análisis Bivariado
| Recovery Status | ID | Amount | Deleted Account ID | ID Fee | Cash Request ID | Total Amount Fee | Time Diff |
|---|---|---|---|---|---|---|---|
| 98 | 17565.16 | 82.17 | 9.56e+07 | 11195.31 | 17565.16 | 5.000353 | 7.82e+06 |
| Cancelled | 23127.00 | 100.00 | 9.89e+07 | 16008.00 | 23127.00 | 5.000000 | 5.36e+06 |
| Completed | 13851.78 | 81.26 | 9.15e+07 | 9281.89 | 13851.78 | 5.000000 | 1.01e+07 |
| Pending | 13494.55 | 80.71 | 9.58e+07 | 10130.27 | 13494.55 | 5.000000 | 7.38e+06 |
| Pending Direct Debit | 14515.85 | 85.59 | 9.89e+07 | 9516.35 | 14515.85 | 5.000000 | 9.42e+06 |
Correlación entre variables Numéricas
Distribución de Transfer Type vs Recovery Stats
Distribución de Time Diff vs Recovery Stats
Variables a tener en cuenta modelo predictivo
Ejemplos de variables con un p-value < 0.05 y Chi-cuadrado significativo:
moderated_at: chi2=41894.79, p-value=0.000
reimbursement_date: chi2=15903.45, p-value=0.000
send_at: chi2=69478.84, p-value=0.000
type_fee: chi2=5413.51, p-value=0.000
status_fee: chi2=9537.93, p-value=0.000
Frecuencia de Uso del Servicio segmetado por trimestres
La frecuencia de uso aumenta drásticamente del segundo al tercer trimestre, pero muestra una ligera reducción en el cuarto trimestre, aunque se mantiene en un nivel alto en comparación con el segundo trimestre. Esto podría indicar un crecimiento inicial en el uso del servicio, seguido de una estabilización.
Tasa de incidentes
Hay una clara tendencia a la baja en la tasa de incidentes a medida que avanza el tiempo, lo que podría indicar una mejora en la gestión de incidentes o un cambio positivo en las condiciones subyacentes.
Ingresos Generados por Cohorte
La cohorte 2020Q3 generó los mayores ingresos, destacándose como un modelo exitoso que debería replicarse. La cohorte 2020Q4 tiene buen potencial, pero es necesario acelerar la conversión de clientes a estados generadores de ingresos. Optimizar estrategias en cohortes recientes puede maximizar las ganancias futuras.
Frecuencia de Recovery Status por Cohortes y Trimestres
El estado predominante es 1-98 en todas las cohortes, indicando que la mayoría de los clientes probablemente tienen ese estado inicial o base.
El número de clientes que completaron (1-completed) el proceso parece ser significativo, especialmente en las cohortes 2020Q3 y 2020Q4.
Estados como 1-cancelled y 1-pending_direct_debit son poco frecuentes, mostrando que son escenarios menos comunes en estos datos.
Proporción de Recovery Status por Cohortes y Trimestres
Foco en la conversión: Es crucial investigar por qué en la cohorte 2020Q4, la mayoría de los clientes (80%) no avanzan más allá del estado inicial. Podría ser necesario revisar los procesos internos, la experiencia del cliente o las políticas operativas.
Lecciones de cohortes anteriores: Las cohortes 2020Q2 y 2020Q3 muestran mejores tasas de finalización. Analizar lo que funcionó bien en esos períodos podría ayudar a replicar el éxito con nuevas cohortes.
Estrategias proactivas: Diseñar iniciativas específicas para mover a más clientes hacia 1-completed podría mejorar la eficiencia operativa y generar más ingresos. Esto podría incluir automatización, seguimiento personalizado o incentivos para avanzar en el proceso.
Frecuencia de Ingresos por semana
El servicio tiene una tendencia ascendente en la frecuencia de ingresos por semana, con un aumento significativo en los trimestres.
Elasticidad Temporal de ingresos por semana
En la semana que incluye el 2020-05-10, la elasticidad temporal alcanza un pico muy alto (superior a 7), sugiriendo un evento o campaña que provocó un gran aumento en los ingresos.
En general, los ingresos son estables a lo largo del tiempo, con oscilaciones moderadas.
Series Temporales de Tipos de Usuario
Observamos la clara diferencia de Tendencia entre los nuevos usuarios y la recurrencia de los usuarios ya existentes, indicativo que la captación de nuevos usuarios esta funcionando muy bien pero no se esta logrando la recurrencia de los usuarios ya existentes.
Predicciones Tipos de Usuario
Vemos como a pesar de la creciente tendencia que se mantiene sobre los nuevos usarios, cuesta incrementar la retención de ellos, indicativo para mejorar la experiencia de usuario y la calidad del servicio.
Distribución de Segmentos de Usuario (RFM)
Observamos como la mayor parte de los usuarios se encuentran en el segundo segmento mas bajo del Estudio, lo que nos podria dar un indicio de que la estrategia de marketing actual no esta siendo efectiva para atraer a todos esos clientes potenciales.
Distribución de Segmentos de Usuario Potential Loyalist (RFM)
Recency: Muchos clientes están activos recientemente, lo que sugiere un buen nivel de retención. Frequency: La baja frecuencia general indica que los clientes interactúan pocas veces y podrían necesitar incentivos para incrementar la frecuencia. Monetary: Aunque el gasto promedio es moderado, los valores atípicos altos representan clientes con un mayor potencial económico.
Comparación en Gasto de Segmentos de Usuario (RFM)
Al igual que en la Distribución de los Segmentos de usuario, esa gran masa donde se encuentran los perfiles que pueden ser potencialmente clientes son los perfiles que estan gastando más en nuestro servicio.
Análisis y predicción de transacciones en Business Payments usando regresión lineal, para anticipar incidencias y optimizar la gestión.
Hemos decidido ir a predecir la variable "status" y la variable "recovery_status" para esta rúbrica.
Podemos ver que los campos que están relacionados son los de ID, variables que a nivel predictorio nos aportan poca capacidad predictiva.
El 40.1% de la variabilidad en la variable dependiente (recovery_status_encoded) está explicada por las variables independientes en el modelo con el R².
También obtenemos que el p-value de distinitas variables es menor a 0,005, lo que nos da una significancia positiva confirmada.
Regresión Lineal:
Error Cuadrático Medio (MSE): 0.7876582240511442 R2: 0.35304526580937523 Coeficientes: [-0.00164849 -0.0155265 0.61151403 0.81330906] Intercepto: 0.5015476024153426
El MSE nos da un valor muy alto, ya que cuanto menor sea menor será el error del modelo.
El R² tampoco captura el 65% de la variabilidad de recovery_status.
Vemos que category_fee(0,8133) y fee_status (0,6115) són las variables que más explican el modelo.
Regresión Logística para predecir "status"
Hemos utilizado una regresión logística multinomial para predecir la variable categórica status de un conjunto de datos. En este caso hemos implementado una función sigmoide.
Se usó la función log-loss para medir errores entre predicciones y etiquetas. El modelo obtuvo un 89.53% de precisión en pruebas después de:
- Implementar una función log-loss y hacer One-Hot encoding de la variable status (categórica).
- Entrenar al modelo introduciendo pesos y sesgos.
- Hacer la predicción con los pesos y los sesgos ya en el modelo.
Concluimos que se muestra un rendimiento sólido y esto implica su capacidad para clasificar correctamente transacciones según su estado.
Predicción y Recall
El modelo predice excelentemente la clase "transaction_declined" (90% precisión, 100% recall), pero falla en las otras clases (precisión y F1-score de 0.00). La precisión global es 0.90, dominada por la clase mayoritaria, indicando un problema de desbalance de clases.
Es por eso que introducimos hiperparametros y utilizando el algoritmo SMOTE, creamos de manera sintética observaciones en las clases más desvalanceadas para ver que capacidad de predicción y de recall tiene el modelo entonces:
El recall mejoró en algunas clases como money_sent y waiting_user_confirmation, pero sigue bajo en approved (~0.4) y disminuyó en transaction_declined. Esto indica riesgo de falsos positivos y una predictividad alta solo en transaction_declined.
Las fintech enfrentan el reto de prevenir fraudes, que aunque representan menos del 0.3% de transacciones, tienen alto impacto. Este análisis identifica patrones sospechosos como montos inusuales, usuarios inactivos y transacciones rechazadas para mitigar riesgos.
Métricas clave para detectar usuarios fraudulentos:
-
Filtrar "transaction_declined" o "rejected": Identificar usuarios con alta incidencia en estos estados para detectar patrones sospechosos.
-
Transacciones de monto máximo (200): Usuarios con este monto deben considerarse casos sospechosos.
-
Diferencial entre created_at y updated_at: Diferencias muy cortas pueden indicar intentos de manipulación o fraude.
-
Transacciones entre 1-4 AM: Actividad nocturna inusual puede ser indicativa de fraudes.
-
"direct_debit_rejected": Identificar usuarios con rechazos en débitos directos como posible señal de fraude.
Tras aplicar los filtros, se identificaron usuarios que aparecen en hasta 3/5 criterios, siendo posibles casos de fraude. Estos user_id se añadieron al dataframe para analizar si realmente son fraudulentos o simples coincidencias.
Random Forest para detección de falsos positivos:
El modelo Random Forest evaluó usuarios sospechosos, mostrando su desempeño en precisión, recall, F1-score y accuracy mediante la matriz de confusión y reporte de clasificación para detectar fraudes.
Los resultados de la clasificación de fraude con Random Forest son los siguientes:
Verdaderos Negativos (VN): 4181 transacciones no fraudulentas correctamente identificadas. Falsos Positivos (FP): 5 transacciones no fraudulentas clasificadas erróneamente como fraudulentas. Falsos Negativos (FN): 17 transacciones fraudulentas clasificadas erróneamente como no fraudulentas. Verdaderos Positivos (VP): 9 transacciones fraudulentas correctamente identificadas.
Resultados del modelo Random Forest:
Precisión:
Fraude (1): 0.64, lo que significa que el 64% de las transacciones clasificadas como fraudulentas realmente lo eran. No fraude (0): 1.00, indicando que el 100% de las transacciones clasificadas como no fraudulentas realmente no lo eran.
Recall:
Fraude (1): 0.35, lo que muestra que solo el 35% de las transacciones fraudulentas fueron identificadas correctamente. No fraude (0): 1.00, lo que indica que el modelo identificó correctamente el 100% de las transacciones no fraudulentas.
F1-Score:
Fraude (1): 0.45, lo que refleja un desempeño moderado en la detección de fraudes, con un equilibrio entre precisión y recall. No fraude (0): 1.00, lo que demuestra un rendimiento casi perfecto en la clasificación de transacciones no fraudulentas.
Conclusión sobre el uso de Random Forest:
Bajo desempeño en la detección de fraudes: Aunque el modelo tiene una precisión general alta (99%), su bajo recall para fraudes (0.35) indica que solo una pequeña parte de las transacciones fraudulentas es identificada, lo que requiere mejoras en la detección de fraudes.
Desbalance de clases: El modelo está sesgado hacia la clase mayoritaria (no fraude), lo que explica la alta precisión. Se recomienda explorar técnicas como submuestreo, sobremuestreo o ajustes en el umbral de decisión para mejorar la detección de fraudes sin sacrificar demasiado la precisión.
Este histograma muestra la distribución de usuarios, donde 1 representa usuarios fraudulentos y 0 no fraudulentos. Con un ajuste de 0.2 en el modelo, la mayoría de los nuevos usuarios se clasifican como no fraudulentos. Esto indica que, tal como está operando Business Payments, el modelo está capturando cada vez menos usuarios fraudulentos, lo que sugiere una tendencia preocupante en la detección de fraudes.
Esta matriz muestra la segmentación de los resultados utilizando Random Forest: verdadero negativo, falso positivo, falso negativo y verdadero positivo. Podemos observar que, en este caso, se han identificado correctamente 9 usuarios fraudulentos como verdaderos positivos, lo que indica que el modelo ha logrado detectar algunas transacciones fraudulentas, aunque con un número limitado de aciertos.
La curva ROC es una herramienta utilizada para evaluar la capacidad discriminativa de un modelo en pruebas diagnósticas dicotómicas. En esta curva, se presenta la sensibilidad (proporción de verdaderos positivos) en el eje vertical y el complemento de la especificidad (proporción de falsos positivos) en el eje horizontal. Los valores de ambos ejes van de 0 a 1, lo que refleja una escala del 0% al 100%. La curva se forma conectando los puntos correspondientes a distintos umbrales de corte.
El AUC (Área Bajo la Curva) es una métrica clave para interpretar la capacidad discriminativa del modelo:
0.5: El modelo no tiene capacidad discriminativa. 0.5-0.6: Test malo. 0.6-0.75: Test regular. 0.75-0.9: Test bueno. 0.9-0.97: Test muy bueno. 0.97-1: Test excelente.
Este análisis ayuda a seleccionar el mejor punto de corte y comparar la efectividad de diferentes modelos.
En este gráfico de barras podemos observar la importancia de cada variable en la predicción de usuarios fraudulentos. El peso asignado a cada variable indica su influencia en la determinación de si un usuario es fraudulento o no. Las barras más largas representan las variables que tienen mayor impacto en la clasificación, lo que permite identificar los factores más relevantes para predecir el fraude.