Resumen del proyecto

Contexto

• Proyecto del Sprint 5 del programa de Ciencia de Datos en TripleTen.

Problema de negocio

• Megaline ofrece dos tarifas de prepago (Surf y Ultimate). El objetivo es identificar cuál plan genera mayores ingresos promedio para optimizar decisiones de marketing y presupuesto publicitario.

Objetivos (qué se busca demostrar con datos)

• Preparar y depurar datos de uso (llamadas, SMS e internet) y de planes.
• Construir el consumo mensual por cliente y calcular ingreso mensual por usuario considerando:
  • cuota mensual,
  • servicios incluidos,
  • cargos por excedentes (minutos, SMS y datos).
• Analizar y visualizar distribuciones y patrones de uso/ingresos por plan.
• Probar hipótesis estadísticas sobre diferencias de ingresos promedio:
  • Surf vs Ultimate,
  • NY/NJ vs otras regiones.
• Redactar conclusiones y recomendaciones accionables.

Datasets (tablas) y atributos clave

• users (usuarios)
  • user_id: identificador único del usuario (llave para unir con las demás tablas).
  • first_name: nombre del usuario.
  • last_name: apellido del usuario.
  • age: edad del usuario.
  • city: ciudad de residencia (usada para el análisis regional).
  • reg_date: fecha de alta/registro del usuario.
  • churn_date: fecha de baja/cancelación (si no ha cancelado, suele estar vacía).
  • plan: plan contratado (surf / ultimate).
• calls (llamadas)
  • id: identificador único del registro de llamada.
  • call_date: fecha de la llamada.
  • duration: duración de la llamada (minutos; puede requerir redondeo/ajuste según reglas del proyecto).
  • user_id: identificador del usuario que realizó la llamada (para unir con users).
• messages (SMS)
  • id: identificador único del registro de mensaje.
  • message_date: fecha de envío del SMS.
  • user_id: identificador del usuario que envió el SMS.
• internet (sesiones de internet)
  • id: identificador único del registro de sesión.
  • session_date: fecha de la sesión.
  • mb_used: volumen de datos consumidos en la sesión (MB).
  • user_id: identificador del usuario (para unir con users).
• plans (planes)
  • plan_name: nombre del plan (surf / ultimate).
  • usd_monthly_pay: cuota mensual del plan.
  • minutes_included: minutos incluidos al mes.
  • messages_included: SMS incluidos al mes.
  • mb_per_month_included: MB incluidos al mes (se puede convertir a GB para cálculos).
  • usd_per_minute: costo por minuto extra.
  • usd_per_message: costo por SMS extra.
  • usd_per_gb: costo por GB extra.

Alcance temporal y población

• 500 clientes durante 2018.

Unidad de análisis

• usuario-mes: se agregan consumos mensuales por usuario para calcular ingresos y comparar planes de forma consistente.

Métricas

• Métrica principal: income (ingreso mensual por usuario).
  • Definición: ingreso = cuota mensual del plan (usd_monthly_pay) + cargos por excedentes.
  • Excedentes:
    • minutes_over = max(0, total_minutes - minutes_included)
    • messages_over = max(0, messages_count - messages_included)
    • gb_over = max(0, gb_used - gb_per_month_included)
  • Cargos por excedente:
    • cost_minutes_over = minutes_over * usd_per_minute
    • cost_messages_over = messages_over * usd_per_message
    • cost_gb_over = gb_over * usd_per_gb
  • Nivel de cálculo: usuario-mes.
• Métricas de soporte (uso): total_minutes, messages_count, gb_used agregadas por usuario-mes.
• Métricas de inferencia (estadística): comparación de medias de income entre planes y entre regiones (p-value vs alpha).

Entregables

• Notebook principal: https://github.com/cjhirashi/proyecto-sprint-5/blob/main/notebooks/megaline_analysis.ipynb

Herramientas utilizadas

• Python 3: lenguaje principal para ejecutar todo el flujo (lectura, limpieza, cálculos, visualización e inferencia).
• Pandas: manipulación de datos tabulares; se usa para cargar CSV, limpiar, transformar fechas, hacer groupby por usuario-mes, merges entre tablas y construir la tabla final para análisis.
• NumPy: soporte numérico para operaciones vectorizadas y cálculos auxiliares (por ejemplo, funciones de apoyo y transformaciones).
• Matplotlib: visualización en EDA (histogramas y boxplots) para comparar distribuciones de consumo e ingresos por plan y detectar colas/outliers.
• SciPy: inferencia estadística; ejecución de pruebas de hipótesis (p. ej., comparación de medias de ingresos entre planes y por región).
• Jupyter Notebook: formato de reporte reproducible; documenta el proceso paso a paso (código + narrativa + resultados).
• Pipenv: gestión del entorno y dependencias para asegurar reproducibilidad (instalación de librerías y control de versiones).

Proceso (clasificado por fases)

1. ¿Cuál es la mejor tarifa?

En esta sección se establece el contexto del reto y se define el objetivo analítico del proyecto.

• Objetivo: determinar cuál plan (Surf o Ultimate) genera mayores ingresos promedio con base en el comportamiento real de los clientes.
• Qué se define:
  • Alcance temporal (2018) y población (muestra de 500 clientes).
  • Pregunta principal y preguntas secundarias (comparación por plan y por región).
  • Roadmap de trabajo: exploración de datos → preparación → cálculo de ingresos → análisis/visualización → pruebas de hipótesis → conclusiones.
• Resultado de la sección: queda claro qué se va a medir, cómo se va a comparar y qué entregables producir.

2. Inicialización

En esta sección se prepara el entorno de trabajo.

• Objetivo: dejar listo el notebook para ejecutar de forma reproducible el flujo completo.
• Qué se hace:
  • Importación de librerías (pandas, numpy, matplotlib, SciPy, etc.).
  • Ajustes iniciales necesarios para que el análisis corra sin fricciones (por ejemplo, configuración de visualización).
• Resultado de la sección: ambiente listo para: cargar datos, limpiar/transformar, calcular ingresos, graficar y ejecutar pruebas estadísticas.

2.1. Cargar datos

En esta sección se realiza el ingreso de datos al notebook.

• Objetivo: construir los DataFrames base que alimentan todo el análisis.
• Qué se hace:
  • Lectura de los CSV y creación de DataFrames: users, plans, calls, messages, internet.
  • Revisión/documentación de columnas y significado (sirve como diccionario dentro del notebook).
• Resultado de la sección: quedan cargadas las 5 tablas y se valida que los datos están correctamente leídos y estructurados.

3. Preparar los datos

En el notebook, esta sección revisa cada tabla y, cuando aplica, ejecuta subsecciones de corrección y enriquecimiento.

Objetivo global de la sección: asegurar calidad y consistencia antes de cálculos (tipos correctos, reglas de cobro aplicables, eliminación de registros inválidos y preparación para agregación mensual).

Qué se hace en general (para todas las tablas):

• Exploración inicial con info(), tamaño (shape) y muestra (head()).
• Identificación de problemas: tipos incorrectos (fechas como texto), valores atípicos/invalidaciones, nulos esperados.
• Aplicación de correcciones puntuales por tabla.

Resultado global: cada DataFrame queda listo para agregación por usuario-mes y para monetización según el plan.

3.1. Tarifas (plans)

En esta subsección se valida que la tabla de planes esté lista para usar como fuente de reglas de cobro.

• Objetivo: confirmar límites incluidos y costos por excedente, y adaptar unidades a lo que se usará más adelante.
• Qué se revisa: estructura, tipos, nulos y coherencia entre Surf/Ultimate.

3.1.1. Corregir datos

Se ajustan unidades para alinear el plan a la lógica de cálculo.

• Qué se hace: creación de gb_per_month_included a partir de mb_per_month_included.
• Por qué: en pasos posteriores se calcula consumo en GB (redondeo al alza), por lo que el límite incluido también debe estar en GB.

3.1.2. Enriquecer los datos

No se agregan factores extra.

• Resultado de la subsección: el plan queda listo para calcular excedentes en GB (unidad usada después en la monetización).

3.2. Usuarios/as (users)

En esta subsección se prepara la tabla de usuarios como fuente de segmentación (plan y ciudad/región) y análisis temporal.

• Objetivo: dejar las fechas y campos categóricos listos para merges y análisis.
• Qué se revisa: tipos, nulos (especialmente churn_date) y valores válidos en plan.

3.2.1. Corregir los datos

Conversión de reg_date y churn_date a datetime.

• Objetivo: habilitar análisis temporal consistente (por ejemplo, filtrados/agrupaciones por fecha) y evitar errores por tipos incorrectos.
• Qué se hace (en práctica): se transforma cada columna desde object/texto a datetime.
• Criterio de calidad:
  • reg_date debe quedar completamente convertida.
  • churn_date puede conservar nulos (usuarios activos) sin ser un “error”.
• Resultado: tabla users lista para merges y análisis temporal.

3.2.2. Enriquecer los datos

No se agregan factores extra.

• Objetivo: evaluar si se requieren columnas derivadas (p. ej., cohortes, antigüedad), y confirmar que con los atributos actuales es suficiente.
• Decisión: no se crean variables adicionales porque el análisis requerido se apoya en plan y city + consumos mensuales.
• Resultado: fechas correctamente tipadas; churn_date se mantiene como nula para usuarios activos.

3.3. Llamadas (calls)

En esta subsección se prepara la tabla de llamadas para que refleje consumos facturables y permita agregación mensual.

• Objetivo: corregir fechas, limpiar registros inválidos y alinear duration con política de cobro.
• Qué se revisa: tipos, nulos y la validez de duration.

3.3.1. Corregir los datos

• validación y eliminación de registros con duration <= 0,
• conversión de call_date a datetime,
• redondeo al alza de duration (política de facturación por minutos enteros).
• Objetivo: asegurar que los minutos usados representen llamadas facturables y comparables con los límites incluidos del plan.
• Qué se valida:
  • existencia de llamadas con duración inválida (≤ 0) y su eliminación.
  • consistencia del campo temporal al convertir call_date.
• Regla de negocio aplicada: duration se redondea al alza (cada llamada se cobra en minutos enteros).
• Resultado: tabla calls lista para derivar month y agregarse por usuario-mes.

3.3.2. Enriquecer los datos

No se agregan factores extra.

• Objetivo: confirmar si se requieren variables adicionales (p. ej., tipo de llamada) para el alcance del proyecto.
• Decisión: no se agregan factores; con user_id, call_date y duration es suficiente.
• Resultado: dataset de llamadas facturables y consistente con política de cobro.

3.4. Mensajes (messages)

En esta subsección se prepara la tabla de mensajes para análisis temporal (por mes) y agregación por usuario.

• Objetivo: asegurar que la fecha sea usable como datetime para agrupar por mes.
• Qué se revisa: estructura, nulos y tipo de message_date.

3.4.1. Corregir los datos

Conversión de message_date a datetime.

• Objetivo: permitir agregación mensual por usuario usando funciones de fecha.
• Qué se hace: transformación de message_date a datetime.
• Resultado: tabla messages lista para crear month y calcular messages_per_month.

3.4.2. Enriquecer los datos

No se agregan factores extra.

• Objetivo: validar si se necesita enriquecer mensajes (por ejemplo, longitud del SMS) para el problema.
• Decisión: no aplica; el análisis requiere solo conteos por usuario y mes.
• Resultado: tabla lista para agregación mensual.

3.5. Internet (internet)

En esta subsección se prepara la tabla de sesiones de internet para cálculo de consumo mensual y conversión a GB.

• Objetivo: garantizar valores válidos en consumo (mb_used) y fechas correctas para análisis temporal.
• Qué se revisa: nulos, tipo de session_date, y la existencia de valores negativos en mb_used.

3.5.1. Corregir los datos

• validación de mb_used < 0 (y eliminación solo si existieran),
• conversión de session_date a datetime.
• Objetivo: asegurar que el consumo de datos sea válido y que el campo temporal permita agregación mensual.
• Qué se valida: no existan consumos negativos (se conservan consumos 0 porque representan sesiones sin tráfico).
• Resultado: tabla internet lista para crear month y calcular internet_per_month.

3.5.2. Enriquecer los datos

No se agregan factores extra.

• Resultado de la subsección: tabla consistente (sin consumos negativos) y lista para agregación mensual y conversión a GB.
• Objetivo: evaluar si es necesario crear variables extra (p. ej., categorías de consumo) antes de la agregación.
• Decisión: no se agregan factores; la transformación clave ocurre después en la agregación mensual (MB→GB con redondeo).

4. Estudiar las condiciones de las tarifas

• Confirmación de condiciones de Surf/Ultimate (incluidos + costos por excedente).
  • Propósito dentro del flujo: fijar explícitamente las reglas de monetización que se aplicarán para calcular ingresos.
  • Qué se obtiene: un checklist claro de parámetros (cuota, incluidos, costos extra) que alimentan el cálculo de excedentes e ingresos.

4.1. Agregar datos por usuario

• Construcción de consumo mensual por usuario:
  • calls_per_month (conteo de llamadas),
  • minutes_per_month (minutos totales),
  • messages_per_month (conteo de mensajes),
  • internet_per_month (MB totales + conversión a GB con redondeo al alza).
• Unión de tablas mensuales en user_month_data.
• Merge con users (plan, ciudad) y con plans (parámetros del plan).
• Cálculo de excedentes (*_over) y costos (cost_*_over) y finalmente income.
  • Resultado de la subsección: una tabla final usuario-mes que incluye consumo, parámetros del plan y el ingreso mensual calculado por usuario.
  • Notas de implementación (según notebook):
    • uso de outer merges para no perder meses/usuarios y posterior manejo de nulos.
    • uso de clip(lower=0) para excedentes (evitar valores negativos).
    • redondeo al alza en GB para que el cobro por datos siga la política establecida.

4.2. Estudia el comportamiento de usuario

Sección de análisis exploratorio (EDA) para comparar patrones de uso y su relación con la rentabilidad.

• Objetivo: identificar diferencias de comportamiento por plan (y su impacto potencial en ingresos) antes de pasar a inferencia estadística.
• Qué se hace:
  • Estadística descriptiva por plan.
  • Visualizaciones para tendencia (por mes), distribución (histogramas) y dispersión/outliers (boxplots).

4.2.1 Llamadas:

Promedios por plan/mes + distribuciones y gráficos.

• Objetivo: comparar cómo cambia el uso de llamadas entre Surf y Ultimate.
• Qué se trabaja: minutos mensuales y su variación por plan/mes.
• Visualizaciones (según notebook): barras (promedios), histogramas (distribución) y boxplots (outliers).
• Qué se interpreta: exposición a excedentes (Surf) vs cobertura por plan (Ultimate) y presencia de outliers.

4.2.2. Mensajes:

• Objetivo: comparar patrón de envío de SMS entre planes y detectar meses con mayor volumen.
• Qué se trabaja: messages_count mensual por usuario (agregado a nivel usuario-mes).
• Visualizaciones (según notebook):
  • Gráfico de barras (promedio por plan/mes),
  • histograma (distribución),
  • boxplot (dispersión/outliers).
• Qué se interpreta: diferencias de hábito entre planes, dispersión y presencia de outliers que podrían generar excedentes en Surf.

4.2.3. Internet

En esta subsección se analiza el consumo de internet (datos móviles) por usuario y cómo varía según el plan (Surf vs Ultimate).

• Objetivo: identificar patrones de consumo (tendencia por mes, dispersión y outliers) y estimar el riesgo de excedentes en GB (principal driver de cargos extra, especialmente en Surf).
• Qué se trabaja:
  • Se utiliza la tabla mensual internet_per_month (MB agregados por usuario y mes) y su conversión a GB mediante redondeo al alza (gb_used = ceil(mb_used/1024)), alineado a la política de cobro.
  • Se compara el comportamiento por plan y por mes para entender estacionalidad y variabilidad.
• Visualizaciones (consistentes con el notebook):
  • Gráfico de barras del promedio mensual de GB por plan.
  • Histograma para la distribución de GB mensuales por plan.
  • Boxplot para comparar dispersión y presencia de outliers.
• Qué se interpreta:
  • Diferencias de consumo típico entre planes.
  • Colas largas/outliers que explican meses con cargos extra por GB.
  • Implicación de negocio: segmentación de usuarios Surf con alto consumo para migración a Ultimate.

4.2.4 Ingreso

En esta subsección se analiza el ingreso mensual (income) ya calculado en user_month_data, comparándolo entre planes y observando su distribución.

• Objetivo: entender no solo el consumo, sino el impacto monetario (cuánto ingresa la empresa) y la variabilidad por plan.
• Qué se trabaja:
  • Comparación de ingresos mensuales por plan (promedio/mediana) y su dispersión.
  • Identificación de cómo los excedentes (minutos/SMS/GB) influyen en meses con ingresos atípicamente altos.
• Visualizaciones sugeridas por el flujo del notebook:
  • Distribuciones (histograma) y dispersión (boxplot) del ingreso mensual por plan.
  • Comparativos por mes para identificar estacionalidad.
• Qué se interpreta:
  • Si Ultimate mantiene ingresos más estables por su cuota fija.
  • Si Surf presenta más variabilidad por cargos extra.
  • Cómo esto alimenta las recomendaciones de marketing.

5. Prueba las hipótesis estadísticas

En esta sección se realizan pruebas de hipótesis para validar con estadística inferencial si las diferencias observadas en EDA también se sostienen a nivel de población.

• Hipótesis 1 (planes):
  • H0: el ingreso promedio de usuarios Surf y Ultimate es igual.
  • H1: el ingreso promedio difiere entre Surf y Ultimate.
• Hipótesis 2 (regiones):
  • H0: el ingreso promedio de usuarios en NY/NJ y en otras regiones es igual.
  • H1: el ingreso promedio difiere entre NY/NJ y otras regiones.
• Procedimiento (como guía de lectura del notebook):
  • Definición del nivel de significancia alpha.
  • Preparación de muestras (filtrado de user_month_data según plan o región).
  • Ejecución de la prueba (t-test de medias con SciPy) y obtención de p-value.
  • Decisión: si p-value < alpha, se rechaza H0.
• Salida de la sección: conclusión estadística por cada hipótesis y su interpretación de negocio.

6. Conclusión general

Se integra todo lo anterior (preparación + cálculo de ingresos + EDA + pruebas de hipótesis) en un cierre ejecutivo.

• Qué incluye:
  • Resumen de hallazgos: patrones de consumo por plan, estructura de ingresos y variabilidad.
  • Resultado final sobre qué plan es más rentable en promedio.
  • Resultado sobre diferencias regionales (NY/NJ vs otras).
  • Recomendaciones: enfoque de marketing, migración de usuarios y segmentación.
  • Observaciones sobre outliers/colas largas y su impacto en promedios.

Resultados e impacto técnico

Preparación e integración de datos

• Se cargaron y validaron las tablas del proyecto: users, calls, messages, internet, plans.
• Se corrigieron tipos de fecha (ej. altas/bajas y fechas de eventos) para habilitar agregaciones temporales.
• Se aplicaron reglas de negocio necesarias para que el consumo fuese facturable (por ejemplo, ajuste/redondeo de minutos por llamada según la política del reto).

Transformación y agregación (nivel usuario-mes)

• Se agregaron consumos mensuales por usuario:
  • minutos totales,
  • cantidad de SMS,
  • consumo de internet (MB→GB con redondeo/ceil, alineado a la forma de cobro).
• Se integraron los consumos con atributos del usuario (plan, ciudad) y condiciones del plan (incluidos y precios por excedente) para construir la tabla final de análisis (usuario-mes).

Cálculo de ingresos (monetización)

• Se calcularon excedentes vs. lo incluido en el plan (minutos/SMS/GB) y sus cargos correspondientes.
• Se obtuvo el ingreso mensual por usuario (income) como:
  • cuota mensual fija + cargos por excedentes.
• Resultado: dataset final listo para comparar rentabilidad por plan y para segmentación por región.

Resultados del Notebook (EDA + comportamiento)

• El análisis exploratorio (gráficas de barras, histogramas y boxplots) muestra diferencias de uso entre planes:
  • Usuarios de Ultimate tienden a consumir más minutos y datos.
  • Usuarios de Surf tienden a mostrar mayor uso de SMS.
• Se observaron valores atípicos (colas largas) en consumo e ingresos, relevantes para interpretar promedios y dispersión.

Resultados del Notebook (ingresos y variabilidad)

• En la distribución de income, el plan Ultimate tiende a presentar ingresos mensuales más altos y, típicamente, más estables por la mayor cuota fija (menor dependencia de excedentes).
• El plan Surf presenta mayor variabilidad asociada a cargos por excedentes, especialmente en meses de alto consumo.

Resultados del Notebook (pruebas de hipótesis)

• Se probaron hipótesis para evaluar si existen diferencias significativas en ingresos promedio (Welch’s t-test, α=0.05):
  • Surf vs Ultimate
    • p-value = 5.697848749357264e-13
    • Decisión: se rechaza H0 ⇒ hay diferencia significativa en ingresos promedio.
  • NY/NJ vs otras regiones
    • p-value = 0.00436
    • Decisión: se rechaza H0 ⇒ hay diferencia significativa en ingresos promedio por región.

Implicaciones técnicas y de negocio

• El pipeline permite identificar perfiles con alta probabilidad de excedentes (drivers de ingreso) y soporta decisiones de marketing/segmentación.
• Recomendación técnica: reportar medias junto con medidas robustas (mediana/IQR) por la presencia de outliers en income.