Categoría: Capstone Projects

Capstone Projects

  • Course Recommendation Engine

    Course Recommendation Engine

    Desarrollo de un Motor de Recomendación para Plataformas MOOC mediante Machine Learning

    Este proyecto corresponde al Capstone Project del programa profesional IBM Machine Learning Professional Certificate, finalizado en 2025. Como trabajo final de la certificación, integra de forma práctica los conocimientos adquiridos a lo largo de todo el itinerario formativo, incluyendo análisis exploratorio de datos, ingeniería de características, aprendizaje supervisado y no supervisado, reducción de dimensionalidad, procesamiento de datos textuales y sistemas de recomendación.

    El objetivo del proyecto es resolver un problema empresarial real mediante la aplicación de técnicas de Machine Learning, siguiendo una metodología similar a la empleada en entornos profesionales de ciencia de datos e inteligencia artificial.

    Reestructuración del Proyecto y Gestión de Datos

    Durante el análisis inicial de este proyecto se identificó que los notebooks originales funcionan de forma relativamente independiente y utilizan distintos conjuntos de datos previamente preparados. Lo que constituye una de las debilidades de muchos proyectos educativos: el pipeline real está oculto o simplificado para centrarse en la técnica que se quiere enseñar. Esto dificulta la comprensión del flujo completo de datos y la trazabilidad de las transformaciones realizadas a lo largo del proyecto.

    Con el objetivo de construir una solución más cercana a un entorno profesional de Ciencia de Datos y Machine Learning, se ha decidido reorganizar el proyecto siguiendo una arquitectura basada en etapas claramente definidas. Para ello, se identificarán los conjuntos de datos originales proporcionados por IBM y se establecerá un flujo de procesamiento donde cada notebook consumirá los resultados generados por la fase anterior.

    El proyecto partirá de tres fuentes de datos principales:

    • course_genre.csv, que contiene la información categórica de los cursos.
    • course_processed.csv, que contiene la información textual de los cursos utilizada para las tareas de procesamiento de lenguaje natural.
    • ratings.csv, que almacena las interacciones entre usuarios y cursos.

    La arquitectura final seguirá un enfoque tipo pipeline, donde los datos evolucionan progresivamente desde su estado original hasta convertirse en las características y estructuras necesarias para los diferentes sistemas de recomendación implementados. Este enfoque aporta varias ventajas:

    De esta manera, el proyecto mantiene el mismo problema de negocio planteado en el Capstone de IBM, pero adopta una estructura de datos más sólida, transparente y alineada con las buenas prácticas de desarrollo de proyectos de Machine Learning en entornos reales.

    Introducción

    Los sistemas de recomendación se han convertido en una pieza fundamental dentro de las plataformas digitales modernas. Empresas como Netflix, Spotify, Amazon, YouTube o Coursera utilizan algoritmos de recomendación para personalizar la experiencia de sus usuarios, facilitar el descubrimiento de contenido relevante y aumentar los niveles de interacción dentro de sus ecosistemas.

    En este proyecto se aborda el diseño y desarrollo de un sistema de recomendación aplicado al sector de la formación online. El escenario se sitúa en una plataforma MOOC (Massive Open Online Course) denominada AI Training Room, una empresa dedicada a la distribución de cursos relacionados con inteligencia artificial, machine learning, ciencia de datos, computación en la nube y desarrollo de software.

    Debido al rápido crecimiento de la plataforma y al incremento constante del catálogo de cursos disponibles, surge la necesidad de ayudar a los estudiantes a identificar contenidos de interés de forma eficiente. Un sistema de recomendación permite resolver este problema mediante el análisis de los cursos existentes y del comportamiento de los usuarios, generando sugerencias personalizadas que facilitan la construcción de itinerarios formativos adaptados a cada alumno.

    Desde una perspectiva empresarial, una recomendación más precisa no solo mejora la experiencia de aprendizaje, sino que también puede incrementar indicadores clave como la retención de usuarios, el número de inscripciones por estudiante y los ingresos de la organización.

    El objetivo principal de este proyecto consiste en explorar, implementar y comparar diferentes enfoques de recomendación utilizando técnicas de aprendizaje automático tanto supervisadas como no supervisadas. Para ello se trabajará con información relativa a cursos, contenidos y registros de inscripción de estudiantes.

    A lo largo del proyecto se desarrollará un flujo de trabajo completo de Machine Learning que incluye:

    • Comprensión y exploración de los datos disponibles.
    • Análisis exploratorio de datos (EDA).
    • Extracción de características textuales mediante técnicas de Bag of Words (BoW).
    • Construcción de sistemas de recomendación basados en contenido.
    • Aplicación de algoritmos de aprendizaje no supervisado como métricas de similitud, K-Means y Análisis de Componentes Principales (PCA).
    • Desarrollo de modelos de filtrado colaborativo utilizando algoritmos como K-Nearest Neighbors (KNN), Non-negative Matrix Factorization (NMF), Redes Neuronales Artificiales y modelos clásicos de Machine Learning.
    • Comparación del rendimiento de los distintos enfoques mediante evaluaciones offline.

    El proyecto no busca únicamente obtener un modelo funcional, sino analizar las ventajas, limitaciones y casos de uso de cada técnica de recomendación. De esta forma, se reproduce un escenario real de investigación y desarrollo dentro de una empresa tecnológica, donde la selección del modelo adecuado requiere equilibrar precisión, escalabilidad e interpretabilidad.

    Finalmente, este trabajo constituye una demostración práctica de competencias en análisis de datos, procesamiento de lenguaje natural, aprendizaje supervisado, aprendizaje no supervisado y sistemas de recomendación, áreas que representan una parte esencial de las aplicaciones modernas de Inteligencia Artificial.

    1. Exploratory Data Analysis (EDA)

    Antes de desarrollar los modelos de recomendación, fue necesario comprender la estructura y las características de los datos disponibles. Esta fase de análisis exploratorio tuvo como objetivo identificar los principales temas presentes en el catálogo de cursos, analizar la distribución de las categorías y detectar patrones relevantes en las inscripciones de los estudiantes.

    <class 'pandas.DataFrame'>
    RangeIndex: 307 entries, 0 to 306
    Data columns (total 16 columns):
     #   Column           Non-Null Count  Dtype
    ---  ------           --------------  -----
     0   COURSE_ID        307 non-null    str  
     1   TITLE            307 non-null    str  
     2   Database         307 non-null    int64
     3   Python           307 non-null    int64
     4   CloudComputing   307 non-null    int64
     5   DataAnalysis     307 non-null    int64
     6   Containers       307 non-null    int64
     7   MachineLearning  307 non-null    int64
     8   ComputerVision   307 non-null    int64
     9   DataScience      307 non-null    int64
     10  BigData          307 non-null    int64
     11  Chatbot          307 non-null    int64
     12  R                307 non-null    int64
     13  BackendDev       307 non-null    int64
     14  FrontendDev      307 non-null    int64
     15  Blockchain       307 non-null    int64
    dtypes: int64(14), str(2)

    El conjunto de datos de cursos contiene 307 cursos online clasificados en 14 categorías tecnológicas diferentes, incluyendo Machine Learning, Data Science, Cloud Computing, Python, Big Data y Desarrollo Web. La ausencia de valores nulos y la representación binaria de las categorías proporcionan una base sólida para la construcción de sistemas de recomendación basados en contenido.

    Para obtener una visión general del catálogo, se generó una nube de palabras a partir de los títulos de los cursos. El análisis reveló una fuerte presencia de tecnologías ampliamente demandadas en la industria, como Python, Machine Learning, Artificial Intelligence, Data Science, TensorFlow y Cloud Computing. Estos resultados confirman que la plataforma está orientada hacia competencias técnicas de alta relevancia en el mercado laboral actual.

    Posteriormente, se analizó la distribución de las categorías para identificar las áreas temáticas más representadas. Este análisis permitió comprender el equilibrio del catálogo y detectar los dominios con mayor oferta formativa. Asimismo, se exploraron combinaciones de categorías, identificando cursos que integran áreas complementarias como Machine Learning y Big Data, una combinación especialmente relevante para el desarrollo de soluciones escalables basadas en datos.

    Finalmente, se examinó el conjunto de datos de inscripciones con el objetivo de identificar los cursos más populares y los patrones generales de participación de los estudiantes. Estos hallazgos proporcionaron información valiosa tanto para comprender el comportamiento de los usuarios como para fundamentar el diseño posterior de los modelos de recomendación.

    Los 20 cursos con más estudiantes enrolados:

                                               TITLE  Enrolls
    0                        python for data science    14936
    1                   introduction to data science    14477
    2                                   big data 101    13291
    3                                     hadoop 101    10599
    4                      data analysis with python     8303
    5                       data science methodology     7719
    6                   machine learning with python     7644
    7                           spark fundamentals i     7551
    8   data science hands on with open source tools     7199
    9                          blockchain essentials     6719
    10                data visualization with python     6709
    11                             deep learning 101     6323
    12                        build your own chatbot     5512
    13                            r for data science     5237
    14                                statistics 101     5015
    15                         introduction to cloud     4983
    16   docker essentials  a developer introduction     4480
    17              sql and relational databases 101     3697
    18                            mapreduce and yarn     3670
    19                     data privacy fundamentals     3624

    En conjunto, esta fase permitió obtener una comprensión profunda de los datos disponibles y sentó las bases para las etapas posteriores del proyecto, donde se aplicaron técnicas de recomendación basadas en similitud, clustering y filtrado colaborativo.

    2. Ingeniería de Características: Representación Bag of Words (BoW)

    Uno de los principales desafíos en la construcción de un sistema de recomendación basado en contenido es que los algoritmos de machine learning no pueden procesar directamente información textual. Aunque los títulos y descripciones de los cursos contienen información valiosa sobre las tecnologías, habilidades y temáticas abordadas, es necesario transformar ese contenido en una representación numérica antes de poder utilizarlo en modelos analíticos y algoritmos de recomendación.

    Para resolver este problema, se implementó una estrategia de Bag of Words (BoW), una de las técnicas fundamentales del Procesamiento del Lenguaje Natural (NLP). El proceso comenzó con la preparación y limpieza del texto de los cursos mediante técnicas de tokenización, eliminación de palabras vacías (stopwords) y normalización del contenido textual. Este paso permitió reducir el ruido de los datos y conservar únicamente los términos más representativos de cada curso.

    Una vez procesado el texto, se construyó un vocabulario global a partir de todos los términos presentes en el catálogo de cursos. Posteriormente, cada curso fue transformado en un vector numérico donde cada dimensión representa una palabra del vocabulario y su valor indica la frecuencia de aparición de dicho término en el curso correspondiente. De esta manera, el contenido textual quedó convertido en una estructura matemática apta para ser utilizada por algoritmos de machine learning.

    El resultado de este proceso fue una matriz Bag of Words que captura la composición temática de cada curso y permite cuantificar el nivel de similitud entre ellos. Los cursos que comparten conceptos, tecnologías o áreas de conocimiento generan vectores similares, facilitando la identificación automática de contenidos relacionados incluso en ausencia de información histórica de los usuarios.

    Esta fase constituye uno de los pilares del sistema de recomendación, ya que transforma datos no estructurados en características cuantificables sobre las que posteriormente se aplicarán métricas de similitud, algoritmos de clustering y modelos de recomendación basados en contenido.


    Objetivos de la fase

    • Transformar información textual en variables numéricas procesables por algoritmos de machine learning.
    • Aplicar técnicas básicas de Procesamiento del Lenguaje Natural (NLP) para limpiar y estructurar el contenido de los cursos.
    • Construir un vocabulario representativo de las tecnologías y habilidades presentes en el catálogo.
    • Generar una matriz Bag of Words que describa matemáticamente cada curso.
    • Preparar la base de características que servirá como entrada para los modelos de recomendación desarrollados en las siguientes etapas del proyecto.

    Tecnologías utilizadas

    • Python
    • Pandas
    • NLTK
    • Bag of Words (BoW)
    • Procesamiento del Lenguaje Natural (NLP)
    • Ingeniería de Características (Feature Engineering)

    Resultado obtenido

    Se generó una representación vectorial de los cursos basada en su contenido textual, permitiendo convertir descripciones y títulos en información cuantificable. Esta transformación constituye la base sobre la que se calcularán similitudes entre cursos y se construirán los modelos de recomendación personalizados del proyecto.

    Imagen recomendada para esta sección: diagrama del pipeline Texto → Tokenización → Limpieza → Vocabulario → Matriz Bag of Words → Vector de Características.

  • AdventureWorks Power BI Data Analyst

    AdventureWorks Power BI Data Analyst

    Proyecto de Dashboard 360° para AdventureWorks 2022. Se extrajeron y exploraron los datos con SQL, se limpiaron y transformaron usando Python y Pandas, y finalmente se visualizaron en Power BI. El proyecto abarca todo el proceso ETL: consultas y modelado de datos en SQL, manipulación y preparación de datos en Python, y construcción de visualizaciones interactivas en Power BI para análisis integral de finanzas, ventas, clientes y productos.

    El proyecto de curso original solo incluía elaborar un dashboard con datos provenientes de tablas de Excel aportadas por el curso.

    Tecnologías utilizadas

    • SQL Server (base transaccional)
    • SQL Server Management Studio + VS Code (extensión MSSQL)
    • Python (pandas, pyodbc, sqlalchemy, seaborn)
    • Power BI Desktop + Power BI Service

    Diagrama de ETL del proyecto

    1. Exploración profunda de la base de datos

    Lo primero y más importante: nunca empieces a extraer datos sin entenderlos al 100 %.

    Acciones realizadas:

    • Generé un script SQL individual de exploración para cada una de las 18 tablas relevantes. Cada script incluye:
      • Descripción de las variables
      • Rango de fechas
      • Valores únicos y ejemplos de las columnas clave
      • Identificación de claves primarias y foráneas reales (aunque no estén definidas en la BD)

    Como resultado se creó un Diccionario de Datos completo en Excel y un diagrama relacional.

    2. Diseño del Modelo Analítico

    Definición de un modelo dimensional robusto, siguiendo las mejores prácticas de arquitectura BI. Para garantizar un rendimiento óptimo en Power BI y un análisis consistente, se diseñó un modelo en estrella (Star Schema), manteniendo únicamente algunas jerarquías naturales con forma de snowflake cuando aportaban claridad sin afectar el rendimiento.

    Definición de la Granularidad del Hecho

    Establecer la granularidad exacta de cada tabla de hechos:

    • Ventas: transacción por línea de pedido.
    • Inventario: snapshot por producto y almacén.
    • Finanzas: nivel contable por periodo.
    • Encuestas: respuesta por cliente.

    Definición de Métricas y KPIs Clave

    Se seleccionaron los indicadores esenciales para la visión 360°:

    • Ventas Totales (Sales Amount)
    • Coste del Producto (Total Product Cost)
    • Beneficio Bruto (Profit)
    • Margen (%)
    • Tendencias temporales: variaciones y crecimiento frente a periodos anteriores (YOY/MOM)
    • Valor Medio del Pedido (Average Order Value / AOV)
    • Rotación de Inventario y Alertas de Bajo Stock
    • Presupuesto vs Real (indicadores financieros)
    • Efectividad de Promociones

    Entregables Generados

    Durante esta fase se produjeron los documentos técnicos clave del proyecto:

    • Modelo_Dimensional: esquema visual del modelo en estrella.
    • Documento de Requerimientos Funcionales (.pdf): base formal para validar las necesidades del negocio con cada área.

    3. Extracción desde SQL Server

    Preparación de datos mediante vistas SQL

    Se crearon vistas en SQL Server, segun el documento de Requerimientos, que estructuran y preparan los datos para su posterior procesamiento en Python y análisis en Power BI.

    Las vistas incluyen:

    • Claves y relaciones: Se conservaron solo las necesarias para unir hechos y dimensiones sin duplicar información.
    • Atributos descriptivos y demográficos: Se mantuvieron columnas relevantes para análisis y segmentación (edad, género, ingresos, educación, categoría de producto), mientras que la información sensible de clientes se anonimizó o eliminó.
    • Métricas y valores numéricos: Se seleccionaron columnas necesarias para calcular KPIs como ventas, margen, ticket promedio, inventario y cumplimiento de cuotas.

    Además, se aplicaron transformaciones básicas dentro de las vistas, como el cálculo de edad a partir de la fecha de nacimiento y la unificación de jerarquías de productos, simplificando la carga y limpieza de datos en Python.

    Resultado: Una capa de datos limpia, consistente y segura, lista para análisis avanzado en Python y visualización interactiva en Power BI, cumpliendo los objetivos del dashboard ejecutivo.

    4. Limpieza y Transformación de Datos

    En esta fase se consolidan los datos de SQL Server y se preparan para su análisis en Power BI, asegurando datasets limpios, consistentes y listos para modelado.

    Extracción de Datos

    Se crearon cuadernos de Jupyter para extraer vistas SQL a CSV:

    • Conexión a SQL Server mediante SQLAlchemy.
    • Exportación de cada vista a /data/raw, eliminando prefijos vw_ en los nombres.
    • Mensajes de seguimiento en consola para validar éxito o fallo de cada extracción.

    Carga y Exploración

    Los CSV se cargaron en DataFrames de Pandas para exploración:

    • Inspección de registros y tipos de datos.
    • Identificación de valores nulos e inconsistencias.
    • Funciones reutilizables (CheckData) para revisión rápida de los datasets.

    Limpieza y Transformación

    Se aplicaron transformaciones consistentes por tabla de hechos:

    • Conversión de tipos, fechas y valores categóricos.
    • Tratamiento de nulos mediante reglas específicas según columna y tipo.
    • Estilo de limpieza coherente con los notebooks iniciales, mostrando resúmenes y primeras filas.

    Automatización del ETL

    Se desarrollaron scripts para consolidar el flujo:

    1. config.py: define rutas de trabajo y conexión a SQL Server con SQLAlchemy.
    2. etl_pipeline.py: ejecuta automáticamente:
      • Carga consultas SQL.
      • Genera DataFrames.
      • Limpia los datos según reglas definidas.
      • Guarda datasets limpios en /data/processed.
      • Proporciona logs y seguimiento en consola.

    Este enfoque permite reproducir todo el proceso con un solo comando, manteniendo la trazabilidad y calidad de los datos para análisis en Power BI.

    5. Exportación de Datasets Limpios

    Tras la limpieza y transformación, los datasets se preparan para su consumo en Power BI:

    • Se exportan en formato Parquet (recomendado por eficiencia) o CSV comprimido para reducir espacio.
    • Cada tabla del modelo se guarda en un archivo independiente: dimCliente.parquet, factVentas.parquet, etc.
    • Se incluye la fecha de generación en el nombre del archivo o en una tabla de control.
    • Se mantiene un registro maestro de datasets (datasets_control.xlsx) que documenta: nombre del archivo, número de filas y columnas, fecha de exportación.
    • Todos los archivos se almacenan en /data/final/, listos para el análisis.

    Este procedimiento asegura que los datos sean consistentes, auditables y fácilmente reutilizables por cualquier miembro del equipo BI.

    6. Importación y Modelo en Power BI

    La fase final consiste en construir el modelo semántico para análisis y reporting:

    • Se importan todos los archivos Parquet al proyecto de Power BI.
    • Se define un modelo estrella con relaciones claras entre hechos y dimensiones.
    • Columnas técnicas o auxiliares se ocultan para mejorar la experiencia del usuario.
    • Se crean medidas DAX avanzadas para KPIs clave: ventas, margen, cuotas, inventario, etc.
    • Se aplican optimizaciones de rendimiento: agregaciones, filtrado y segmentación, para mejorar la velocidad y la eficiencia.

    El resultado es un archivo Proyecto_Ventas.pbix completamente funcional y un documento de Modelo de Datos (Modelo de Datos en Power BI.pdf) con capturas de relaciones, medidas y estructura general, que permite navegar, analizar y tomar decisiones basadas en datos de manera rápida y confiable.

  • Space launch optimization with Machine Learning

    Space launch optimization with Machine Learning

    Predicción de Aterrizaje de Cohetes (Capstone IBM Data Science Professional Certificate)

    ¿Es posible predecir si la primera etapa de un Falcon 9 aterrizará con éxito?

    Este proyecto final del certificado profesional de IBM (septiembre 2025) desarrolla un pipeline completo de Ciencia de Datos para determinar la viabilidad del aterrizaje de la primera etapa, factor clave para reducir los costes de lanzamiento de SpaceX.

    Puntos clave del flujo de trabajo:

    • Ingeniería de Datos: Extracción híbrida mediante la API oficial de SpaceX y Web Scraping con BeautifulSoup.
    • Análisis y Visualización: EDA profundo con Pandas, análisis geoespacial de sitios de lanzamiento con Folium y consultas complejas en SQLite.
    • Machine Learning: Optimización de hiperparámetros mediante GridSearchCV para comparar modelos de Regresión Logística, SVM, Árboles de Decisión y KNN.
    • Producto Final: Dashboard interactivo desarrollado en Plotly Dash para la monitorización de métricas de éxito.
    • Stack técnico: Python (Pandas, Scikit-Learn), SQL, Folium, Plotly Dash.

    App del Proyecto:

    La aplicación del proyecto realizada en Flask y Plotly incluye un simulador interactivo que permite predicciones con dos modelos diferentes de Machine Learning. Puedes visitar la aplicacion en mi VPS personal Project Portal en: https://projects.fernandorioseco.es

    Enlace al repositorio del proyecto:

    https://github.com/fer78/Space-Launch-Optimization-with-Machine-Learning.git

    Escenario y visión general del proyecto

    La era espacial comercial ya ha llegado. Las empresas están haciendo que los viajes espaciales sean asequibles para todos:

    • Vingin Galactic está ofreciendo vuelos espaciales suborbitales.
    • Rocket Lab es un proveedor de satélites pequeños.
    • Blue Origin fabrica cohetes reutilizables suborbitales y orbitales.
    • SpaceX es la más exitosa, envía naves tripuladas espaciales a la Estación Espacial Internacional, sus satélites Starlink proporcionan internet satelital en todo el mundo.

    Una razón por la cual SpaceX puede hacer estas operaciones es porque ha logrado que sus lanzamientos sean más económicos. Recientemente, anunció en su sitio web el lanzamiento del nuevo cohete Falcon 9 con un coste de 62 millones de dólares, mientras que otras empresas pueden hacerlo con costes de más de 150 millones.

    Gran parte de este ahorro es debido a que SpaceX puede reutilizar la primera etapa del lanzamiento. Con este dato, si podemos determinar si la primera etapa aterrizará, podemos determinar el coste de un lanzamiento.

    En la infografía se pueden apreciar las diferentes partes del cohete:

    • Carga útil: contiene el elemento que se desea llevar al espacio.
    • Segunda etapa: ayuda a llevar la carga útil a la órbita.
    • Primera etapa: Realiza la mayor parte del trabajo de llevar la carga útil a la órbita, es la parte más grande y más costosa.

    A diferencia de otros proveedores de cohetes, el Falcon 9 puede recuperar la primera etapa. En ocasiones no tiene éxito durante el aterrizaje y se destruye. En otras ocasiones, la propia empresa destruye la primera etapa debido a los parámetros de la misión como la carga útil. La orbita y el cliente.

    En este proyecto asumirás el papel de un científico de datos que trabaja para una nueva empresa de cohetes: SpaceY, que quiere competir con SpaceX.

    SpaceY fue fundada por el empresario industrial Allon Mask.

    Tu trabajo es determinar el éxito de cada lanzamiento, recopilando información sobre la competencia y determinando si se reutilizará la primera etapa.

    En lugar de usar la ciencia de cohetes para determinar si la primera etapa aterrizará con éxito. Entrenarás un modelo de aprendizaje automático y usarás información pública para predecir si SpaceY reutilizará la primera etapa.

    En la primera fase de este proyecto, se construyó un dataset completo y estructurado a partir de datos públicos de todos los lanzamientos históricos de SpaceX, utilizando exclusivamente su API REST oficial (v4).

    Parte 1: Extracción de datos mediante peticiones HTTP a la API de SpaceX

    Se realizó una petición GET al endpoint https://api.spacexdata.com/v4/launches/past para obtener el histórico completo de lanzamientos.

    Dado que la respuesta contiene únicamente identificadores (rocket_id, payload_id, launchpad_id, core_id), se implementó un proceso de data enrichment mediante llamadas secundarias a los endpoints específicos:

    • /v4/rockets/{id} → nombre del booster (Falcon 9, Falcon 1, etc.)
    • /v4/launchpads/{id} → nombre del sitio de lanzamiento, longitud y latitud
    • /v4/payloads/{id} → masa de la carga útil (kg) y órbita destino (LEO, GTO, ISS, etc.)
    • /v4/cores/{id} → información crítica del core: éxito del aterrizaje, tipo de aterrizaje (RTLS, ASDS, océano), uso de grid fins y landing legs, bloque del booster, número de reusos, serial del core, etc.

    Transformación y normalización de datos

    • Se utilizó pd.json_normalize() para aplanar la respuesta JSON anidada en un DataFrame plano.
    • Se filtraron lanzamientos con múltiples cores o payloads (casos excepcionales de Falcon Heavy o misiones con rideshare) para mantener consistencia en el análisis de la primera etapa.

    Construcción del dataset final de entrenamiento

    Se creó un diccionario estructurado con las siguientes variables enriquecidas:

    • FlightNumber, Date, BoosterVersion
    • PayloadMass, Orbit, LaunchSite, Longitude, Latitude
    • Outcome (éxito/fracaso del aterrizaje + tipo), Flights, GridFins, Reused, Legs, LandingPad
    • Block, ReusedCount, Serial

    Este diccionario se convirtió en un DataFrame final (launch_df).

    Limpieza y filtrado específico

    • Se eliminaron todos los lanzamientos de Falcon 1, conservando únicamente Falcon 9.
    • Se reindexó la columna FlightNumber de forma secuencial (1 a n).
    • Se realizó imputación de valores faltantes en PayloadMass utilizando la media global de la columna, manteniendo intencionalmente los valores None en LandingPad (indicando aterrizajes oceánicos sin plataforma).

    El resultado es un dataset limpio, estructurado y enriquecido (dataset_part_1.csv) con 90 lanzamientos de Falcon 9 hasta noviembre de 2020, listo para las siguientes fases de análisis exploratorio, feature engineering y modelado predictivo del éxito del aterrizaje de la primera etapa.

    <class 'pandas.core.frame.DataFrame'>
    RangeIndex: 90 entries, 0 to 89
    Data columns (total 17 columns):
     #   Column          Non-Null Count  Dtype  
    ---  ------          --------------  -----  
     0   FlightNumber    90 non-null     int64  
     1   Date            90 non-null     object 
     2   BoosterVersion  90 non-null     object 
     3   PayloadMass     90 non-null     float64
     4   Orbit           90 non-null     object 
     5   LaunchSite      90 non-null     object 
     6   Outcome         90 non-null     object 
     7   Flights         90 non-null     int64  
     8   GridFins        90 non-null     bool   
     9   Reused          90 non-null     bool   
     10  Legs            90 non-null     bool   
     11  LandingPad      64 non-null     object 
     12  Block           90 non-null     float64
     13  ReusedCount     90 non-null     int64  
     14  Serial          90 non-null     object 
     15  Longitude       90 non-null     float64
     16  Latitude        90 non-null     float64
    dtypes: bool(3), float64(4), int64(3), object(7)
    memory usage: 10.2+ KB
    

    Parte 2: Web Scraping de registros históricos desde Wikipedia

    En esta segunda fase del proyecto se construyó un dataset alternativo y complementario mediante web scraping de la página de Wikipedia “List of Falcon 9 and Falcon Heavy launches”, con el objetivo de obtener una fuente independiente a la API oficial de SpaceX y permitir validación cruzada de los datos.

    Tecnologías y herramientas utilizadas

    • requests con cabecera User-Agent personalizada para evitar bloqueos.
    • BeautifulSoup4 como parser HTML.
    • Funciones auxiliares propias para la extracción robusta de datos en celdas con ruido típico de Wikipedia (referencias, superíndices, enlaces, formato inconsistente).

    Proceso de parsing implementado

    1. Identificación de tablas relevantes
    2. Extracción automática de nombres de columnas
    3. Parsing fila por fila con lógica robusta
    4. Construcción del dataset

    Se obtuvo un DataFrame completo con 121 lanzamientos de Falcon 9 y Falcon Heavy hasta junio de 2021, incluyendo información crítica para el modelo predictivo:
    Booster landing (variable objetivo), Payload mass, Orbit, Launch site, Version Booster, etc.

    El archivo final se exportó como spacex_web_scraped.csv, listo para su uso en análisis exploratorio, fusión con el dataset de la API y entrenamiento de modelos de clasificación.

    Parte 3: Data Wrangling y definición de la variable objetivo

    En esta fase del proyecto se realizó un análisis exploratorio inicial (EDA) y el data wrangling necesario para convertir el dataset crudo (obtenido vía API en la Parte 1) en un conjunto de datos listo para modelado supervisado de clasificación.

    Principales tareas realizadas

    1. Carga y diagnóstico inicial del dataset
    2. Análisis exploratorio univariante
      • Distribución de lanzamientos por sitio de lanzamiento (LaunchSite):
      • Distribución por tipo de órbita (Orbit), destacando la predominancia de LEO, ISS, GTO y SSO, y la presencia de órbitas menos frecuentes (HEO, MEO, ES-L1, etc.).
    3. Análisis profundo de la variable Outcome (resultado del aterrizaje de la primera etapa)
    4. Creación de la variable objetivo binaria (Class)
      • Se definió el conjunto de resultados fallidos: bad_outcomes = {'False ASDS', 'False RTLS', 'False Ocean', 'None ASDS', 'None None'}
      • Se generó la columna Class mediante list comprehension: python landing_class = [0 if outcome in bad_outcomes else 1 for outcome in df['Outcome']] df['Class'] = landing_class
      • Class = 1 → primera etapa recuperada con éxito
      • Class = 0 → no recuperada (fallo o misión expendable)
    5. Cálculo de la tasa de éxito global

    Se exportó el dataset enriquecido como dataset_part_2.csv, que incluye:

    • Todas las variables originales enriquecidas desde la API
    • La nueva variable binaria Class lista para ser usada como target en modelos de clasificación supervisada
    • Ningún valor faltante crítico (solo LandingPad mantiene None intencionadamente)

    Parte 4: Exploratory Data Analysis (EDA)

    En esta fase clave del proyecto se realizó un análisis exploratorio exhaustivo (EDA) y la ingeniería de variables (feature engineering) definitiva para preparar los datos de cara al modelado predictivo supervisado.

    Se crean funciones auxiliares propias para aplicar un estilo visual elegante, consistente y profesional (ejes limpios, rejilla vertical rosa, leyenda personalizada rojo/verde para fallos y éxitos)

    Análisis exploratorio realizado

    FlightNumber vs PayloadMass

    Scatter plot que muestra claramente la curva de aprendizaje de SpaceX: los primeros lanzamientos presentan más fallos, mientras que a partir del vuelo ~20–25 la tasa de éxito se vuelve muy alta, incluso con cargas útiles pesadas.

    FlightNumber vs LaunchSite

    • CCAFS SLC-40 es el sitio dominante en número de lanzamientos.
    • Los fallos están concentrados en los primeros vuelos de cada plataforma.
    • KSC LC-39A y VAFB SLC-4E muestran tasas de éxito cercanas al 100 % en lanzamientos recientes.

    PayloadMass vs LaunchSite

    Observación clave: desde VAFB SLC-4E nunca se han lanzado cargas pesadas (>10 000 kg), lo que explica su tasa de éxito casi perfecta.

    Success Rate by Orbit Type

    Órbitas principales:

    Bar chart revelador:

    • LEO e ISS → tasa de éxito ≈ 100 %
    • GTO → tasa más baja (misión más energética, menor margen para recuperación)
    • SSO y polar → éxito muy alto

    FlightNumber vs Orbit

    • En LEO el éxito crece claramente con el número de vuelo.
    • En GTO la relación no es tan evidente: incluso en vuelos recientes hay tanto éxitos como fallos, debido a la mayor dificultad energética.

    PayloadMass vs Orbit

    • Con cargas útiles pesadas, la tasa de aterrizaje exitoso o positivo es mayor para las órbitas Polar, LEO e ISS.
    • Sin embargo, para GTO, resulta difícil distinguir entre aterrizajes exitosos y fallidos, ya que ambos resultados se presentan de manera equilibrada.”

    Evolución anual de la tasa de éxito (2013–2020)

    Line chart que muestra una mejora sostenida y casi lineal desde ~50 % en 2013 hasta >95 % en 2020, reflejando la madurez tecnológica de la reutilización.

    Feature Engineering

    1. Selección de variables relevantes para el modelo:
    2. One-Hot Encoding aplicado a las variables categóricas:
      • Orbit (11 categorías)
      • LaunchSite (3)
      • LandingPad (5)
      • Serial (53 identificadores únicos de boosters)
    3. Conversión completa del dataset a tipo float64 para compatibilidad con algoritmos de Machine Learning.

    Se generó el dataset definitivo dataset_part_3.csv con 104 columnas numéricas y 90 observaciones, completamente limpio, codificado y listo para entrenamiento de modelos de clasificación.

    Parte 5: Análisis exploratorio con SQL

    Aunque el núcleo del proyecto se basa en Machine Learning con Python, esta fase complementaria demuestra una competencia adicional muy valorada en ciencia de datos: el dominio de consultas SQL para análisis exploratorio y extracción de insights directamente desde bases de datos relacionales.

    Objetivo

    Utilizar SQLite como motor de base de datos en entorno local para cargar el dataset completo de misiones SpaceX y resolver 10 consultas analíticas reales mediante lenguaje SQL puro.

    Infraestructura implementada

    • Creación de base de datos en memoria: my_data1.db
    • Carga del archivo CSV original mediante pandas.to_sql()
    • Limpieza inicial: eliminación de filas con fecha nula
    • Uso de la extensión mágica %sql para ejecutar consultas directamente desde Jupyter

    Consultas SQL realizadas y resultados clave obtenidos

    TaskConsulta realizadaInsight principal
    1DISTINCT Launch_Site4 sitios únicos: CCAFS SLC-40, KSC LC-39A, VAFB SLC-4E, CCAFS LC-40
    2Lanzamientos desde sitios que empiezan por ‘CCA’69 misiones (mayoría histórica)
    3Masa total de carga útil NASA (CRS)45 716 kg transportados en contratos CRS
    4Masa media de carga en versión F9 v1.12 534 kg (versión temprana con menor capacidad)
    5Primera fecha de aterrizaje exitoso en plataforma terrestre2015-12-22 (Flight 20 – hito histórico RTLS)
    6Boosters con éxito en dron ship y carga entre 4000–6000 kg9 casos (todos F9 FT Bxxxx)
    7Conteo total de éxitos y fallos de misión98 éxitos – 1 fallo (CRS-7 explosión)
    8Booster_Version con máxima carga útil13 600 kg → F9 B5 B1048.2 y B1049.2 (misiones Starlink)
    9Fallos en dron ship durante 2015Enero (CRS-7) y Marzo (SES-9) – dos intentos fallidos emblemáticos
    10Ranking de outcomes de aterrizaje (2010-06-04 → 2017-03-20)Success (drone ship): 14, Success (ground pad): 9, Failure: 7, etc.

    Parte 6: Visualización interactiva de sitios de lanzamiento con Folium

    En esta fase del proyecto se implementó un análisis geoespacial interactivo utilizando la librería Folium, con el objetivo de explorar visualmente la ubicación estratégica de los sitios de lanzamiento de SpaceX y su relación con el éxito del aterrizaje de la primera etapa.

    Tecnologías utilizadas

    • folium + plugins: MarkerCluster, MousePosition, DivIcon
    • Cálculo de distancias geodésicas mediante la fórmula del haversine
    • Visualización interactiva en mapa base OpenStreetMap

    Tareas realizadas

    Marcado de los 4 sitios de lanzamiento activos de Falcon 9.

    • CCAFS LC-40
    • CCAFS SLC-40
    • KSC LC-39A (Kennedy Space Center)
    • VAFB SLC-4E (Vandenberg, California)

    Cálculo y representación de distancias a infraestructuras críticas

    Visualización interactiva de éxitos y fallos por lanzamiento

    • Se creó un MarkerCluster que agrupa automáticamente los marcadores según el nivel de zoom.
    • Cada lanzamiento se representa con un marcador cuyo color indica el resultado:
      • Verde → Class = 1 (aterrizaje exitoso)
      • Rojo → Class = 0 (fallo o misión expendable)
    • Popup informativo con: sitio de lanzamiento y resultado.

    Insights geoespaciales obtenidos

    • Todos los sitios de lanzamiento están ubicados en la costa (Atlántico o Pacífico) → minimiza riesgo poblacional.
    • Distancia a ciudades siempre superior a 40–50 km → protocolo de seguridad estándar.
    • Proximidad a autopistas (<1 km) y vías férreas → optimización logística.
    • VAFB SLC-4E (California) presenta 100 % de éxito en aterrizajes, parcialmente explicado por cargas más ligeras y menor densidad de tráfico aéreo.

    Parte 7: Dashboard Interactivo con Plotly Dash

    En la fase final del proyecto se desarrolló un dashboard web interactivo utilizando Plotly Dash, permitiendo a cualquier usuario (técnico o no técnico) explorar de forma dinámica los datos históricos de lanzamientos de SpaceX y los factores que influyen en el éxito del aterrizaje de la primera etapa.

    Tecnologías utilizadas

    • Dash (by Plotly) – Framework Python para aplicaciones web analíticas
    • Plotly Express – Gráficos interactivos de alto nivel
    • Pandas – Manipulación de datos
    • Despliegue local en http://0.0.0.0:8050

    Funcionalidades implementadas

    1. Dropdown de selección de sitio de lanzamiento
    2. Gráfico de tarta dinámico (Pie Chart)
    3. Range Slider de masa de carga útil (0 – 10 000 kg)
    4. Gráfico de dispersión interactivo (Scatter Plot)

    Callbacks implementados

    • @app.callback para el gráfico de tarta → responde al site-dropdown
    • @app.callback doble entrada (site-dropdown + payload-slider) → actualiza el scatter en tiempo real

    Parte Final: Modelado Predictivo y Selección del Mejor Algoritmo

    En la fase culminante del proyecto se entrenaron y evaluaron cuatro algoritmos de clasificación supervisada para predecir si la primera etapa del Falcon 9 aterrizará con éxito (Class = 1) o no (Class = 0), utilizando el dataset completamente preprocesado (104 variables one-hot + numéricas estandarizadas).

    Pipeline de Machine Learning implementado

    1. Estandarización de todas las variables con StandardScaler
    2. División train/test (80 % train – 20 % test, random_state=2)
    3. Búsqueda exhaustiva de hiperparámetros mediante GridSearchCV con 10-fold cross-validation
    4. Evaluación final sobre el conjunto de prueba (18 muestras)

    Modelos entrenados y resultados

    ModeloMejores hiperparámetros (GridSearchCV)Accuracy Validación (CV)Accuracy TestObservaciones
    Logistic RegressionC=0.01, penalty='l2', solver='lbfgs'84.64 %83.33 %Muy estable, pocos falsos positivos
    SVMC=1.0, gamma=0.0316, kernel='sigmoid'84.82 %83.33 %Rendimiento prácticamente idéntico a Regresión Logística
    Decision Treecriterion='gini', max_depth=6, max_features='sqrt', min_samples_leaf=4, splitter='random'88.93 %83.33 %Mejor en validación (posible leve sobreajuste)
    K-Nearest Neighborsn_neighbors=10, algorithm='auto', p=1 (distancia Manhattan)84.82 %83.33 %Robusto y consistente

    Resultado clave: Los cuatro modelos alcanzan 83.33 % de accuracy en el conjunto de prueba (15 aciertos de 18 muestras), lo que representa un rendimiento excelente considerando el reducido tamaño del dataset (90 observaciones totales).

    Análisis de matrices de confusión

    • Todos los modelos cometen 3 falsos positivos (predicen éxito cuando en realidad falló).
    • Solo 0–1 falsos negativos → priorizan correctamente la seguridad (no decir que fallará cuando en realidad aterriza).
    • El Decision Tree es el que mejor generaliza en validación, pero en test empata con los demás.

    Conclusión final del proyecto

    Se ha construido con éxito un sistema predictivo robusto capaz de estimar, con más del 83 % de precisión, si la primera etapa del Falcon 9 será recuperada en una misión futura, basándose únicamente en parámetros públicos conocidos antes del lanzamiento (sitio, órbita, masa de carga, versión del booster, etc.).

    Este modelo tiene aplicaciones reales:

    • Estimación de costes de lanzamiento (reutilizable vs. expendable)
    • Optimización de contratos comerciales
    • Apoyo en la toma de decisiones de clientes frente a competidores

  • PropTech Analytics: Apartamentos España 2019

    PropTech Analytics: Apartamentos España 2019

    El sector inmobiliario global está experimentando una transformación estructural impulsada por el fenómeno PropTech (Property Technology), donde la analítica de datos avanzada y el Big Data sustituyen a los métodos tradicionales de tasación y análisis de mercado. Hoy en día, plataformas líderes como Idealista o Zillow operan como masivos agregadores de información en tiempo real, abriendo una ventana de oportunidad única para la toma de decisiones basada en datos (Data-Driven Decisions). En este contexto, la capacidad de procesar, limpiar y modelar datos extraídos directamente de la web no es solo una ventaja competitiva, sino el estándar operativo para inversores institucionales, desarrolladores urbanos y analistas financieros en mercados altamente dinámicos.

    Data Science Pipeline 

    1. Ingesta de datos tabulares: Ejecutar el pipeline de lectura de fuentes de datos estructuradas en texto plano (raw data) para su inicialización en memoria.
    2. Curación y limpieza de datos (Data Wrangling / Preprocessing): Aplicar transformaciones en el DataFrame (imputación de valores nulos, parsing de tipos de datos, manejo de outliers y deduplicación) para optimizar la calidad de los datos (data quality) y mitigar sesgos en el modelado.
    3. Geocodificación y Enriquecimiento de Features: Implementar el proceso de geocoding mediante la API de Geopy para transmutar variables de texto (direcciones físicas) en vectores geoespaciales (latitud y longitud), permitiendo la representación cartográfica en un mapa interactivo.
    4. Análisis Exploratorio de Datos (EDA): examinar el conjunto de datos para entender sus características, detectar anomalías y descubrir patrones mediante resúmenes estadísticos y gráficos.
    5. Visualización de Analíticas Geoespaciales: Desplegar mapas de calor (heatmaps) o mapas coropléticos para mapear la distribución espacial e identificar sesgos geográficos o gradientes de precio entre regiones.
    6. Ingeniería de Características y Análisis de Correlación: Evaluar la covarianza y el impacto estadístico (feature importance) de las variables independientes del inmueble sobre la variable objetivo (target), que es el precio.
    7. Clustering para Segmentación de Mercado: Implementar algoritmos de aprendizaje no supervisado (como K-Means o DBSCAN) para agrupar patrones ocultos, reduciendo la dimensionalidad para perfilar clústeres del sector inmobiliario.
    8. Inferencia Estadística y Pruebas A/B (A/B Testing): Ejecutar tests estadísticos (como ANOVA, T-Test o pruebas no paramétricas) para validar la significancia estadística de las diferencias de precio e aislar el efecto de features específicas.
    9. Despliegue de un Dashboard de BI en Tableau: Desarrollar un cuadro de mando interactivo para habilitar el drill-down de métricas clave y permitir la exploración dinámica del dataset por parte de los stakeholders.
    10. Data Storytelling y Data-Driven Insights: Comunicar los hallazgos críticos del pipeline analítico mediante narrativas de datos, transformando métricas técnicas en recomendaciones estratégicas e insights accionables para el negocio.

    Página del proyecto en GitHub:

    https://github.com/fer78/Data-Analytics-Final-Portfolio-Project.git

    1. Introducción y Contexto del Negocio (Business Understanding)

    Proyecto Capstone del Curso Data Science: Analytics Specialist, de Codecademy. En este se desarrolla un Pipeline de Ciencia de Datos de extremo a extremo aplicado al sector PropTech (tecnología inmobiliaria). Para este análisis se ha seleccionado el Spanish Housing Dataset, un conjunto de datos reales de código abierto alojado en Kaggle. Los datos fueron recolectados originalmente mediante técnicas de web scraping automatizado sobre la plataforma  Idealista S.A.U., el portal inmobiliario líder en España.

    La investigación se enfoca estratégicamente en el segmento de apartamentos (apartments/condos) dentro del territorio español. Este subsector representa una categoría crítica en los núcleos urbanos y suburbanos de alta densidad, donde la demanda de soluciones habitacionales eficientes, accesibles y con alta liquidez es elevada.

    El propósito central de este análisis es desentrañar las dinámicas subyacentes del mercado inmobiliario español, aislando las características clave (features) que impactan directamente en la tasación y la elasticidad del precio. A través de un riguroso Análisis Exploratorio de Datos (EDA), estadística descriptiva e inferencial, se identifican patrones ocultos, asimetrías de precios y agrupaciones geoespaciales (clusters). Los resultados proveen insights de alto valor estratégico para tomadores de decisiones, inversores institucionales (REITs) y compradores privados internacionales.

    Nota metodológica: Con el fin de garantizar la escalabilidad del proyecto, la fase de curación y preprocesamiento de datos (Data Wrangling) se ejecuta de manera agnóstica sobre el volumen total del dataset. Esto permite estructurar una base de datos limpia, robusta y optimizada para futuros análisis predictivos o modelos de Machine Learning aplicados a otros tipos de activos (como viviendas unifamiliares o locales comerciales).

    2. Objetivos Estratégicos

    El objetivo principal de este proyecto es modelar y analizar el comportamiento estadístico de los apartamentos y viviendas unifamiliares en venta a lo largo de diversas provincias españolas durante el ejercicio fiscal 2019.

    Los objetivos específicos del pipeline analítico incluyen:

    • Ingesta y Curación de Datos: Diseñar un flujo de preprocesamiento robusto en Pandas para mitigar el ruido estadístico (outliers, nulos y duplicados).
    • Enriquecimiento Geoespacial: Implementar algoritmos de geocoding mediante la API de Geopy para transmutar direcciones textuales en vectores tridimensionales (latitud, longitud y altitud) que permitan una cartografía interactiva precisa.
    • Segmentación Avanzada: Aplicar modelos de aprendizaje no supervisado (Clustering) para clasificar el mercado e identificar micronichos de inversión.
    • Business Intelligence (BI): Construir e implementar un dashboard interactivo en Tableau enfocado en la exploración dinámica y el desglose (drill-down) de métricas macroeconómicas locales.
    • Localización Internacional: Adaptar la terminología técnica, métricas superficiales (de metros cuadrados a square feet) y formatos financieros al contexto normativo y cultural de los inversores privados de Estados Unidos (EE. UU.), facilitando la transferencia de conocimiento (Data Storytelling).

    3. Fuente, Arquitectura y Estructura de los Datos

    La fuente de datos de partida consiste en un dataset crudo de texto plano estructurado que consta de 100,000 registros (instancias) y 41 variables (características). La granularidad de la información abarca atributos multidimensionales de los listados inmobiliarios activos en el portal, agrupados de la siguiente forma:

    • Métricas Financieras y de Dimensión: Variable objetivo (target) precio, coste por unidad de superficie, tamaño del inmueble, entre otros.
    • Atributos Estructurales y de Calidad: Estado de conservación (renovado, a reformar), año de construcción, planta/piso.
    • Variables de Confort (Features Binarias): Presencia de sistemas de climatización (A/C), zonas verdes (jardín), terrazas, plazas de garaje y piscinas comunitarias o privadas.
    • Datos de Localización: Direcciones normalizadas, municipios, códigos postales y provincias.

    El conjunto de datos presenta una naturaleza híbrida compuesta por variables cuantitativas (discretas y continuas) y cualitativas (nominales y ordinales), ofreciendo un entorno óptimo para la inferencia estadística robusta y la ingeniería de características.

    4. Inspección Inicial del Dataset (Raw Data Snapshot)

    Para validar la integridad estructural e iniciar el proceso de auditoría de datos (Data Profiling), se presenta a continuación una muestra del primer registro indexado en memoria dentro de nuestro DataFrame original:

    print(raw_data.head(1).T)
                                                                                   0
    ad_description                 Precio chalet individual en la localidad de Ab...
    ad_last_update                                Anuncio actualizado el 27 de marzo
    air_conditioner                                                                0
    balcony                                                                        0
    bath_num                                                                       2
    built_in_wardrobe                                                              0
    chimney                                                                        0
    condition                                               segunda mano/buen estado
    construct_date                                                               NaN
    energetic_certif                                                             NaN
    floor                                                                  2 plantas
    garage                                     plaza de garaje incluida en el precio
    garden                                                                         1
    ground_size                                                                  NaN
    heating                                                                      NaN
    house_id                                                                81717634
    house_type                                           Casa o chalet independiente
    kitchen                                                                      NaN
    lift                                                                         NaN
    loc_city                                                             Urcabustaiz
    loc_district                                                          La iglesia
    loc_full                                 La iglesia , Urcabustaiz , Zuya, Álava 
    loc_neigh                                                                    NaN
    loc_street                                                                   NaN
    loc_zone                                                             Zuya, Álava
    m2_real                                                                     1000
    m2_useful                                                                  172.0
    obtention_date                                                        2019-03-29
    orientation                                              norte, sur, este, oeste
    price                                                                     310000
    reduced_mobility                                                               0
    room_num                                                                       4
    storage_room                                                                   0
    swimming_pool                                                                  0
    terrace                                                                        1
    unfurnished                                                                  NaN
    number_of_companies_prov                                                   19147
    population_prov                                                           328868
    companies_prov_vs_national_%                                                0.57
    population_prov_vs_national_%                                               0.70
    renta_media_prov                                                        19889.00

    5. Pipeline de Procesamiento y Curación de Datos (Data Wrangling)

    El proceso de preparación y adecuación del dataset se estructuró en un pipeline secuencial dividido en tres fases fundamentales, garantizando así la calidad de los datos (Data Quality), la consistencia interna y la reproducibilidad del análisis.

    Fase 1: Preprocesamiento y Depuración Estructural (Initial Transformation)

    El objetivo de esta primera fase fue mitigar el ruido estadístico inicial, descartar redundancias en el flujo de datos y homogeneizar los formatos vectoriales necesarios para las posteriores tareas de enriquecimiento geoespacial. Las operaciones críticas ejecutadas incluyeron:

    • Filtrado de Características (Feature Dropping / Data Filtering): Se realizó un análisis de relevancia para identificar y remover 16 variables que no aportaban valor predictivo ni descriptivo al núcleo del negocio (como identificadores internos del portal web o metadatos de los anuncios). Esta reducción de dimensionalidad optimizó drásticamente el consumo de memoria en el entorno de ejecución.
    • Deduplicación de Instancias (Data Deduplication): Se auditó el DataFrame en busca de registros idénticos que pudieran sesgar las distribuciones de precios (causados habitualmente por la republicación de anuncios). Se identificaron e indexaron 6,071 registros duplicados, los cuales fueron eliminados por completo para asegurar la unicidad de las observaciones.
    • Tratamiento de Valores Omisos (Handling Missing Data): Se evaluó la matriz de densidad de nulos para determinar el mecanismo de pérdida de información (MCAR, MAR o MNAR). Dependiendo de la variable, se aplicaron estrategias diferenciadas:
      • Filtrado por umbral (Drop) en variables críticas de localización imposibles de inferir.
      • Imputación estadística (empleando la mediana del vecindario/provincia) para variables numéricas continuas como la superficie o el precio.
      • Categorización explícita (como “No especificado”) para atributos cualitativos binarios o nominales, evitando así la pérdida de registros valiosos.
    missing_values = raw_data.isnull().sum().sort_values(ascending=False)
    print(missing_values[missing_values > 0])
    ground_size       93928
    kitchen           91902
    loc_street        80147
    heating           69857
    construct_date    63150
    orientation       56789
    garage            56130
    loc_neigh         52086
    m2_useful         44501
    lift              38965
    condition         13295
    dtype: int64
    • Imputación por Ausencia Estructural (Structural Missingness):
      Se identificó que los valores faltantes en ciertas variables cualitativas binarias (como la disponibilidad de garaje o ascensor) no respondían a una pérdida aleatoria de información, sino a una omisión estructural. En el sector PropTech, la ausencia de registro equivale a la inexistencia del atributo. Por lo tanto, se ejecutó una imputación determinista reemplazando estos nulos por el valor binario 0 (Falso).
    • Filtrado por Umbral de Densidad (Sparsity Filtering):
      Se auditó la tasa de completitud de todas las características. Nueve variables que exhibían un índice de valores ausentes superior al 60% fueron descartadas de forma definitiva, mitigando el riesgo de introducir sesgos artificiales mediante técnicas de imputación masiva sobre matrices dispersas.

    Fase 2: Armonización de Variables y Derivación de Características (Feature Engineering)

    Con el fin de estandarizar el dataset e iniciar el proceso de auditoría y perfilado de variables (Data Profiling), se implementaron las siguientes operaciones a nivel de registro:

    • Estandarización de Categorías y Localización de Dominio: Para adaptar el proyecto al mercado objetivo de inversores de EE. UU., se transformó la taxonomía y codificación original hacia la jerga inmobiliaria americana (e.g., convirtiendo tipos de propiedad a Apartment/CondoSingle-Family Home, etc.). Asimismo, se corrigieron inconsistencias sintácticas y tipográficas presentes en el texto libre.
    • Casteo de Tipos de Datos (Type Casting): Se reasignaron los tipos de datos en memoria para optimizar el rendimiento del sistema, forzando variables numéricas mal indexadas a flotantes o enteros (float64/int64), y convirtiendo variables de texto repetitivas en el tipo eficiente category de Pandas.
    • Normalización de Texto para Geocodificación: Se aplicaron expresiones regulares (Regex) para limpiar la variable de dirección física, eliminando ruidos de texto y prefijos redundantes (como “Calle”, “Avenida”, “Av.”) que disminuyen la precisión de los motores de búsqueda geográfica.
    • Derivación de Características de Respaldo (Feature Derivation): Se diseñó una variable sintética denominada city_prov mediante la concatenación de los campos loc_city y loc_zone. Esta variable actúa como una directiva de ubicación secundaria (fallback location) en el pipeline, asegurando que si la dirección específica falla al geocodificarse, el sistema pueda aproximar el registro a nivel municipal.
    • Persistencia Intermedia: El DataFrame limpio y armonizado se exportó a un nuevo archivo serializado, garantizando un punto de restauración óptimo antes de iniciar la fase de cómputo intensivo.

    6. Enriquecimiento Geoespacial y Procesamiento por Lotes (Batch Geocoding)

    Para transformar las direcciones físicas en vectores de coordenadas espaciales (Latitud y Longitud), se integró la librería Geopy utilizando el servicio de geocodificación Nominatim, un motor de código abierto basado en el ecosistema de mapas vectoriales OpenStreetMap.

    Arquitectura del Pipeline de Geocodificación por Bloques (Chunking)

    Debido al volumen masivo del dataset (100,000 registros), realizar peticiones síncronas a una API externa en un solo bloque comprometería la memoria del sistema y provocaría el bloqueo por tiempo de espera (timeout). Para solucionar esta limitación de infraestructura, se diseñó una arquitectura de procesamiento por lotes (batch processing) dividiendo el DataFrame en bloques (chunks) de 10,000 registros.

    El flujo algorítmico se estructuró a través del siguiente pipeline de funciones:

    [Dataset Original] ──> (create_chunks) ──> [Bloques de 10k en Disco]
                                                        
                 ┌──────────────────────────────────────┘
                 
          (process_chunk) ──> Loop Fila por Fila > (geolocate) ──> (split_address)
                 
                 
         [Liberación Memoria] ──> [Fusión Final de Chunks] > [Dataset Geoespacial]
    
    • create_chunks: Segmenta el DataFrame maestro en particiones homogéneas de 10,000 filas y persiste temporalmente cada bloque en disco para minimizar la huella de memoria RAM.
    • geolocate: Invoca el motor de Nominatim fila por fila dentro del bloque para capturar las coordenadas y retornar una cadena de texto con la dirección normalizada completa encontrada por el servidor.
    • split_address: Realiza un proceso de parsing (análisis sintáctico) sobre la dirección completa devuelta por el servidor para extraer y estructurar vectorialmente variables críticas: código postal (ZIP code), municipio y región.
    • process_chunk: Actúa como la función orquestadora del lote. Ejecuta secuencialmente  geolocate y split_address, integra las nuevas características geoespaciales en el bloque actual, escribe el resultado parcial en almacenamiento físico y ejecuta el recolector de basura de Python para liberar la memoria antes de procesar el siguiente lote.

    Finalmente, un script de consolidación unificó todos los bloques procesados en un único dataset maestro enriquecido.

    Optimización Visual mediante Dispersión de Coordenadas (Spatial Jittering)

    Durante la fase de control de calidad y representación cartográfica preliminar, se detectó una alta colisión de registros en coordenadas idénticas. Este fenómeno de superposición espacial responde a tres dinámicas del mercado real:

    1. Unidades Multifamiliares: Propiedades verticales (apartamentos) que coexisten dentro del mismo edificio físico.
    2. Geocodificación por Fallback: Registros cuya dirección original presentaba fallos sintácticos graves, forzando al pipeline a utilizar la variable de respaldo city_prov, ubicando la propiedad en el centroide geográfico de la ciudad.
    3. Anuncios Ciego (Blind Listings): Una práctica comercial extendida en el sector Real Estate donde las agencias omiten deliberadamente la dirección exacta para proteger la privacidad del vendedor, evitar la desintermediación y prevenir que competidores contacten directamente al propietario. Estos anuncios comparten coordenadas genéricas centralizadas.

    Implementación del Algoritmo de Jittering

    Para resolver la superposición visual en los mapas interactivos y permitir un análisis de densidad correcto, se aplicó la técnica estadística de Jittering Spatial, la cual introduce ruido estocástico aleatorio de baja magnitud a las coordenadas duplicadas.

    El sub-pipeline matemático opera mediante dos funciones clave:

    • move_coordinates: Desplaza de forma vectorial las coordenadas originales calculando un nuevo punto a partir de un ángulo de azimut y una distancia radial aleatoria. Estos valores métricos se transmutan a grados de arco geográfico (ajustando la deformación por latitud) y se adicionan a los vectores originales.
      (Nota de limitación del modelo: Al aplicar ruido aleatorio en zonas costeras, existe un margen de error donde algunos registros pueden sufrir un desplazamiento infinitesimal que los posicione visualmente sobre la superficie marina).
    • disperse_coordinates: Actúa como la función de agrupación. Identifica mediante una operación de agregación todas las coordenadas duplicadas en el dataset y aplica de manera aislada la función move_coordinates a cada registro repetido, distribuyendo las propiedades de forma concéntrica en un radio controlado por parámetros de distancia mínima y máxima predefinidos.

    Muestra Visual del Impacto del Algoritmo (Spatial Jittering Demo)

    A continuación, se ilustra el comportamiento del algoritmo donde múltiples instancias colapsadas en un único centroide se transforman en una distribución dispersa y legible para el analista o el usuario final:

    Curación de Datos Avanzada y Acotación del Espacio Muestral (Data Cleaning for Analytics)

    Una vez integrado el algoritmo de jittering, el dataset se exportó como un punto de control intermedio. En esta etapa, el DataFrame maestro consolidó un volumen de 89,948 registros y 19 columnas  (incluyendo las 6 nuevas variables vectoriales derivadas de la fase de geocodificación).

    processed_data.info()
    <class 'pandas.core.frame.DataFrame'>
    RangeIndex: 89948 entries, 0 to 89947
    Data columns (total 19 columns):
     #   Column           Non-Null Count  Dtype  
    ---  ------           --------------  -----  
     0   air_conditioner  89948 non-null  int64  
     1   bath_num         89948 non-null  int64  
     2   chimney          89948 non-null  int64  
     3   condition        89948 non-null  object 
     4   garage           89948 non-null  object 
     5   garden           89948 non-null  int64  
     6   house_type       89948 non-null  object 
     7   m2_real          89948 non-null  int64  
     8   price            89948 non-null  float64
     9   room_num         89948 non-null  int64  
     10  storage_room     89948 non-null  int64  
     11  swimming_pool    89948 non-null  int64  
     12  terrace          89948 non-null  int64  
     13  latitude         89948 non-null  float64
     14  longitude        89948 non-null  float64
     15  address          89948 non-null  object 
     16  p_code           89948 non-null  int64  
     17  region           89948 non-null  object 
     18  municipality     89948 non-null  object 
    dtypes: float64(3), int64(10), object(6)
    memory usage: 13.0+ MB

    A partir de esta estructura, se diseñó un pipeline de depuración quirúrgica para asegurar la validez estadística, eliminando sesgos geográficos y comerciales antes de la fase de modelado analítico:

    • Validación de Límites Geoespaciales (Bounding Box Filtering): Para evitar errores de proyección en la cartografía, se realizó una auditoría de coordenadas aplicando máscaras booleanas basadas en el bounding box oficial del territorio español:
      • Latitud27.6ºN, 43.8ºN (Desde el archipiélago canario hasta el litoral cantábrico).
      • Longitud: -18.2ºW, 4.3ºE  (Desde la isla de El Hierro hasta la costa oriental de Baleares).
      Esta validación identificó 37 anomalías espaciales (outliers geográficos), las cuales fueron removidas del flujo principal para evitar distorsiones en los mapas interactivos.
    • Filtrado por Representatividad Muestral: Con el objetivo de estabilizar la varianza del modelo, se ejecutó una poda estadística en variables categóricas de baja frecuencia:
      • Se removieron regiones administrativas con un volumen de registros estadísticamente insignificante (low-density regions).
      • Se descartaron tipologías de vivienda con nula representatividad en el mercado masivo urbano (tales como castillos, palacios, ranchos, mansiones, casas torres y casas rurales), concentrando el espectro analítico puramente en el segmento residencial estándar.
    Código de la gráfica
    fig, ax = plt.subplots(2,1, figsize=(10, 4))
    
    sns.boxplot(x=processed_data['latitude'], ax=ax[0])
    ax[0].set_title('Latitude Range')
    
    sns.boxplot(x=processed_data['longitude'], ax=ax[1])
    ax[1].set_title('Longitude Range')
    
    fig.suptitle('Coordinate Ranges', fontsize=14)
    plt.tight_layout()
    plt.show()

    • Ingeniería de Características (Feature Binning & Binning Stratification): Se transformaron variables continuas en estructuras categóricas ordinales para facilitar la segmentación de mercado en Tableau:
      • price_segment: Clasificación del inventario según su valor financiero:
        • Affordable
        • Mid-Range
        • Luxury
      • size_category: Clasificación por densidad de superficie construida (mapeada bajo estándares internacionales de la industria):
        • Small ()
        • Medium
        • Large ()
    • Tratamiento de Inconsistencias Lógicas: Se ejecutó un filtro de integridad física eliminando registros con valores imposibles o nulos en variables clave de habitabilidad, tales como propiedades con cero baños o cero habitaciones.
    • Truncamiento del Espectro Inmobiliario (Capping Extremes): Al evaluar la función de densidad de probabilidad (PDF) de la variable objetivo price, se observó una cola pesada hacia la derecha (right-skewed distribution). Para mitigar el efecto de datos atípicos o errores de digitación en el portal inmobiliario, se parametrizó un umbral de corte estricto, aislando el análisis entre un mínimo de €10,000 y un máximo de €2,000,000. Cualquier registro fuera de este intervalo operativo fue removido.

    Algoritmo de Remoción de Outliers Segmentado (Stratified Outlier Treatment)

    Eliminar valores atípicos de forma global sobre un mercado tan heterogéneo como el inmobiliario introduce un sesgo metodológico crítico: un precio “atípico alto” para un apartamento pequeño en una región rural podría ser un precio “atípico bajo” para un inmueble en una zona de lujo urbana.

    Para resolver esto, se desarrolló e implementó un enfoque de remoción adaptativa y estratificada mediante dos funciones customizadas en Python:

    1. remove_outliers: Función atómica que calcula el Rango Intercuartílico () sobre una serie numérica. Define las barreras de aceptación estadística mediante los límites inferior y superior tradicionales:
      Cualquier observación que se posicione fuera de estas fronteras analíticas es clasificada como un outlier estadístico y removida.
    2. clean_outliers_by_segment: Función orquestadora que aplica una estrategia de descomposición jerárquica mediante agrupamientos sucesivos (nested group-by). El algoritmo aísla el cálculo del IQR de forma justa y comparable, subdividiendo el conjunto de datos bajo el siguiente flujo: 
    [Dataset Consolidado]
       
       └──> 1. Estratificación por Segmento de Precio (`price_segment`)
                   
                   └──> 2. Estratificación por Tipología de Vivienda (`property_type`)
                               
                               └──> 3. Estratificación por Región (`region`)
                                           
                                           └──> [Aplicación del IQR local]
    

    Esta normalización multicapa garantiza que los valores considerados atípicos se evalúen respetando el comportamiento de sus pares directos de mercado, preservando la microestructura económica del conjunto de datos.

    Consolidación del Dataset Final para Análisis

    Tras la ejecución completa de este pipeline de ingeniería y curación de datos, la dimensión final del DataFrame maestro se estabilizó en 77,677 registros y 21 columnas. Este volumen de datos limpio, curado, enriquecido y libre de ruido estadístico conforma la base de datos de alta fidelidad (Analytics-Ready Dataset) utilizada para las posteriores fases de analítica inferencial y visualización.

    Para verificar la disposición física de la estructura de datos en memoria lista para su ingesta en Tableau, se presenta un perfil transpuesto del primer registro procesado:

    print(spain_housing.head(1).T)
    air_conditioner                                                  0
    bath_num                                                         2
    chimney                                                          0
    condition                                                   Resale
    garage                                                Not Included
    garden                                                           1
    house_type                                      Single-Family Home
    m2_real                                                        275
    price                                                    242000.00
    room_num                                                         3
    storage_room                                                     1
    swimming_pool                                                    1
    terrace                                                          1
    latitude                                                     38.59
    longitude                                                    -0.14
    address          Urbanizatzación Convent de les Monges / Urbani...
    p_code                                                        3530
    region                                        Comunidad Valenciana
    municipality                                              Alicante
    price_segment                                           Affordable
    size_category                                                Large
    

    Análisis Exploratorio de Datos (EDA) y Modularización Analítica

    Con el conjunto de datos limpio y validado estadísticamente, se procedió a la fase de Análisis Exploratorio de Datos (EDA). En este punto, la investigación se estructuró de manera estratificada por cada price_segment, aislando el comportamiento de las variables continuas y categóricas para identificar dinámicas específicas de oferta y demanda.

    Arquitectura de Software: Modularización mediante functions.py

    Para garantizar la mantenibilidad, escalabilidad y legibilidad del código (siguiendo las mejores prácticas de ingeniería de software para Ciencia de Datos), se evitó saturar el cuaderno principal (Jupyter Notebook) con bloques de código redundantes de generación de gráficos. En su lugar, se encapsuló toda la lógica visual en un script modular independiente denominado functions.py.

    Este fichero actúa como una librería interna que es importada en el entorno de ejecución, permitiendo invocar funciones dinámicas y parametrizables de manera limpia:

    Catálogo de Funciones de Abstracción Analítica

    Las funciones integradas en el pipeline modular se dividen según su propósito específico dentro de la auditoría analítica:

    1. Motores de Transformación e Interrogación de Datos

    • filterdf(df, col1, val1, col2, val2): Retorna un sub-DataFrame ejecutando una máscara booleana bidimensional basada en dos características y sus respectivos umbrales operativos.

    2. Motores de Análisis Univariado y Distribución

    • boxplot_view(dataframe, column): Despliega diagramas de caja para diagnosticar la asimetría y el rango intercuartílico de variables continuas.
    • boxplot_view_wo(dataframe, column): Muestra la misma distribución de cajas, pero truncando los extremos (whiskers) para aislar visualmente los datos atípicos y mejorar el detalle de los cuartiles centrales.
    • distribution_views(dataframe): Inicializa una cuadrícula de gráficos de densidad para contrastar la dispersión en los campos críticos m2_real y price.
    • plot_histogram(df, column, bins=20, kde=True, xlim=None): Genera histogramas avanzados con la estimación de densidad de kernel (KDE) integrada para evaluar la normalidad de la variable.

    3. Motores de Análisis Categórico y Frecuencias

    • binary_categorical_view(dataframe): Evalúa simultáneamente el volumen y tasa de penetración de características booleanas ligadas al confort habitacional (air_conditionerchimneygardenstorage_roomswimming_poolterrace).
    • categorical_features_view(dataframe): Desglosa las variables categóricas ordinales y cardinales del inventario como room_numbath_num y el estado general (condition).
    • plot_rooms_bathrooms_distribution(df): Muestra la densidad de la distribución cruzada de dormitorios y cuartos de baño específicos para un nicho analítico.
    • plot_category_histograms(df, numeric_col, category_col): Superpone histogramas de variables cuantitativas segregados por etiquetas de una dimensión cualitativa.

    4. Motores de Análisis Bivariado, Multivariado y Correlación

    • bivariate_distribution(dataframe, group_col, target_col, show_outliers): Acopla diagramas de caja cruzados junto a una matriz de salida de estadística descriptiva (media, mediana, desviación estándar) para analizar la variabilidad de una métrica frente a factores grupales.
    • plot_binary_categorical_relationships(dataframe, target_variable): Ejecuta un análisis de contraste que mapea el impacto de cada atributo binario sobre una variable continua (como el precio), inyectando una tabla resumen con los deltas de variación.
    • correlation_heatmap_by_size_category(df): Calcula y grafica matrices de correlación de Pearson o Spearman segregadas de forma independiente para cada nivel de size_category.
    • plot_distribution_by_price_segment(df): Ejecuta un cruce multidimensional agrupando por segmento financiero y tipología de activo para proyectar la densidad de la oferta mediante un mapa de calor bidimensional.

    Muestra de implementación: functions.py (Script Snippet)

    A continuación se expone, a modo de ejemplo de ingeniería de código, la arquitectura interna de una de las funciones clave del módulo. Esta estructura destaca por su manejo integrado de visualizaciones con Seaborn/Matplotlib y la inyección automática de resúmenes de datos numéricos en la consola:

    def bivariate_distribution(dataframe, group_col, target_col, show_outliers=True, figsize=(10, 6)):
        """
        Displays a boxplot and a summary table of a variable grouped by another variable's values.
        """
        df_copy = dataframe.copy()
    
        # Boxplot
        plt.figure(figsize=figsize)
        ax = sns.boxplot(data=df_copy, x=group_col, y=target_col, showfliers=show_outliers, palette="pastel")
        plt.title(f'Boxplot of {target_col} by {group_col} with Mean Values')
        plt.xlabel(group_col)
        plt.ylabel(target_col)
        plt.xticks(rotation=45)
        plt.show()
    
        # Summary Statistics table
        summary_stats = df_copy.groupby(group_col)[target_col].agg(
            mean=lambda x: round(x.mean(), 2),
            Q1=lambda x: x.quantile(0.25),
            Q3=lambda x: x.quantile(0.75),
            std_dev=lambda x: round(x.std(), 2)
        ).reset_index()
        summary_stats = summary_stats.sort_values(by='mean', ascending=False).reset_index(drop=True)
        print(f"Summary Table of {target_col} by {group_col} sorted by Mean:")
        print(summary_stats)
    bivariate_distribution(affordable_apartments, 'region', 'price', show_outliers=False)
    Summary Table of price by region sorted by Mean:
                     region      mean        Q1        Q3  std_dev
    0        Islas Baleares 197767.25 155000.00 240000.00 56301.50
    1   Comunidad de Madrid 180755.40 133350.00 229000.00 59592.77
    2            País Vasco 176976.07 133000.00 220794.00 60137.55
    3              Cataluña 133926.13  96000.00 168000.00 50869.32
    4               Galicia 116780.80  77000.00 140000.00 55973.88
    5              Canarias 114996.06  85000.00 136000.00 41459.24
    6       Castilla y León 108825.89  69000.00 140000.00 53845.32
    7             Andalucía 104710.97  61650.00 141650.00 54689.41
    8  Comunidad Valenciana 100787.91  59000.00 126800.00 58180.42
    9    Castilla-La Mancha  94720.85  58555.00 120000.00 50163.13

    Hallazgos Analíticos y Evidencia Empírica (Exploratory Insights)

    A lo largo de cada sección del análisis de datos se documentaron detalladamente las métricas clave descubiertas y las distribuciones de frecuencia de las variables del entorno PropTech. El reporte analítico exhaustivo, junto con los gráficos de dispersión y mapas de calor interactivos generados en esta etapa, se encuentra completamente documentado y disponible para su consulta en el repositorio oficial del proyecto en GitHub.

    Inferencia Estadística y Modelado Predictivo (Advanced Analytics)

    En esta fase del pipeline, se transicionó de la analítica descriptiva a la analítica diagnóstica y predictiva. Se aplicaron metodologías de estadística inferencial y modelos lineales avanzados para validar con rigor matemático las correlaciones y patrones observados durante el EDA, buscando dar respuesta a la pregunta de negocio central: ¿Cuáles son los inductores de valor (value drivers) estadísticamente significativos en la tasación del mercado de apartamentos en España?

    Este bloque de analítica avanzada se articuló bajo dos verticales metodológicas:

    1. Inferencia Estadística (Pruebas de Hipótesis): Diseñada para mitigar el riesgo de sesgo por aleatoriedad y confirmar la significancia de las relaciones.
    2. Modelado Predictivo Supervizado: Orientado a cuantificar el poder explicativo y la elasticidad de los vectores geográficos sobre la variable objetivo (target).

    Validaciones Estadísticas e Inferencia

    1. Análisis de Varianza (ANOVA) para Segmentos de Superficie (size_category)

    Se ejecutó un test ANOVA de una vía (One-Way ANOVA) para contrastar si las discrepancias de precio observadas entre los grupos de tamaño (SmallMediumLarge) eran producto del azar o respondían a dinámicas estructurales de mercado:

    • Hipótesis Nula () (No existen diferencias significativas entre los precios medios de las tres categorías).
    • Hipótesis Alternativa (): Al menos un par de medias poblacionales difiere significativamente entre sí.
    • Resultado: El rechazo de la hipótesis nula () confirmó que la escala métrica de la vivienda fragmenta el mercado en estratos de valoración completamente independientes.

    2. Evaluación del Impacto del Estado de Conservación (condition) en el Precio

    Para determinar si el ciclo de depreciación física o la prima por estreno impactan la valoración de forma homogénea, se estructuró un segundo diseño ANOVA comparando los precios según el estado de preservación indexado en el portal:

    • Grupos de ContrasteNew construction (Nueva), Good condition (Reventa) y To renovate (Necesita reforma).
    • Resultado: La prueba arrojó significancia estadística crítica, validando empíricamente que el coste de oportunidad de la reforma y el valor premium del suelo a estrenar son factores determinantes en la dispersión de precios.

    3. Análisis de Correlación de Pearson para Atributos de Habitabilidad (bath_num)

    Se evaluó la intensidad del vínculo lineal existente entre la densidad de cuartos de baño y el precio final de los apartamentos:

    • Hipótesis Nula () (No existe correlación lineal estadísticamente significativa entre el número de baños y el precio del inmueble).
    • Hipótesis Alternativa () (Existe una correlación lineal significativa entre ambas variables).
    • Resultado: Se evidenció una correlación lineal positiva y robusta, confirmando que la infraestructura interna de fontanería actúa como un proxy de lujo y confort habitacional fuertemente valorado por el mercado.

    Modelado Lineal Predictivo: El Vector Geográfico como Inductor de Valor

    Más allá de la validación de hipótesis aisladas, se construyó y entrenó un modelo de Regresión Lineal Múltiple. El objetivo de este algoritmo supervisado fue aislar el impacto puramente geoespacial, evaluando en qué medida los vectores tridimensionales combinados (latitud, longitud) y las variables categóricas regionales explican estadísticamente la varianza de la variable dependiente price.

    Este modelo base (baseline model) cuantifica el impacto marginal de la ubicación geográfica exacta, sentando los cimientos matemáticos para algoritmos más complejos de tasación automatizada (AVM – Automated Valuation Models).

    Impacto del Proyecto y Aplicación de Negocio (Business Value)

    Al integrar la exploración visual, la inferencia estadística y el modelado predictivo, el proyecto transita con éxito desde la descripción analítica hacia la anticipación del comportamiento del mercado. Este marco de trabajo robusto se traduce en una toma de decisiones informada por datos (Data-Driven Decisions) con aplicaciones críticas para diversos stakeholders de la industria:

    • Agentes y Brókers Inmobiliarios: Optimiza las estrategias de fijación de precios de salida (listing price) basándose en el comportamiento real de las features del entorno.
    • Inversores Corporativos y Compradores Privados: Permite identificar anomalías del mercado, micronichos de inversión de alto rendimiento (yield) y activos infravalorados respecto a su entorno geoespacial.
    • Desarrolladores, Constructores y Arquitectos: Provee métricas claras sobre la configuración óptima de la vivienda (relación de tamaño, habitaciones y baños) más demandada y valorada en cada región.
    • Planificadores Urbanos y Oficinas de Desarrollo Económico: Aporta datos empíricos sobre la densidad de la oferta y la distribución del valor del suelo, esenciales para el diseño de políticas de vivienda y zonificación urbana.

    Visualización Interactiva y Business Intelligence (Tableau Dashboard)

    Para democratizar el acceso a los insights y permitir que los stakeholders no técnicos exploren los resultados de manera autónoma, los datos curados fueron exportados e integrados en un cuadro de mando interactivo desarrollado en Tableau.

    El diseño del dashboard se estructuró bajo los siguientes pilares de Experiencia de Usuario (UX) y Analítica Visual:

    • Exploración Dinámica mediante Filtros en Cascada: Permite al usuario aislar el mercado de forma interactiva seleccionando el price_segment, la región geográfica o la tipología específica de la vivienda.
    • Mapeo de Densidad Geoespacial: Utiliza las capas vectoriales enriquecidas en la fase de geocodificación para proyectar mapas de calor y clústeres visuales, permitiendo identificar zonas calientes (hotspots) de precios en tiempo real.
    • Métricas Macroeconómicas Locales: Cuadros de mando (KPI Cards) que calculan automáticamente el precio medio por metro cuadrado (y su equivalencia a square feet para el mercado de EE. UU.), la mediana de habitaciones y los ratios de disponibilidad por provincia.

    Conclusiones y Recomendaciones del Pipeline Analítico (Data-Driven Insights)

    Tras completar el pipeline analítico, validar las pruebas inferenciales y ajustar el modelo de regresión sobre el segmento de apartamentos en España, se sintetizan las siguientes conclusiones fundamentales para el negocio (p. 1):

    1. Validación de los Inductores de Valor Físicos (Property Features)

    • El impacto crítico de la infraestructura interna: Las pruebas estadísticas rechazaron formalmente la hipótesis nula respecto a la distribución de baños (p-value = 0.0), demostrando una correlación positiva moderada (p=0.49) con el precio de venta. Esto confirma que la densidad de cuartos de baño es un proxy de confort habitacional que pondera más en el precio final que el número de habitaciones independientes, especialmente en los segmentos Medium y Large (p. 1).
    • Preeminencia del área construida: La matriz de correlaciones determinó que la superficie real (m2_real) mantiene el vínculo más fuerte con la variable objetivo precio (p=0.60). Asimismo, se validó mediante el test ANOVA (F-stat = 7878.25, p-value = 0.0) que la segmentación por tamaño (SmallMediumLarge) divide el mercado en estratos de valoración completamente independientes y significativos.

    2. Dinámicas de Conservación y Segmentación del Mercado

    • El paradigma de la Obra Nueva vs. Reventa: El test ANOVA enfocado en el estado de conservación (condition) ratificó la existencia de diferencias significativas en los precios medios. (F-stat = 17.64, p-value < 0.05) Sin embargo, el análisis descriptivo profundo reveló un comportamiento asimétrico según el poder adquisitivo: mientras que en el segmento Affordable la obra nueva lidera el precio premium, en el segmento Luxury las propiedades de reventa (resale) mantienen promedios superiores a €1M, sugiriendo que la ubicación prime de los activos consolidados supera el valor de depreciación física.
    • Asimetría Geográfica de la Oferta: El inventario inmobiliario de apartamentos está masivamente dominado por el segmento Affordable (79% del total de registros) y propiedades Small de hasta 93  (57%). Territorios como el País Vasco lideran el volumen absoluto de este mercado base, mientras que la oferta de los segmentos Mid-Range (16%) y Luxury (4%) está estrictamente polarizada y concentrada en tres núcleos: Islas Baleares, Comunidad de Madrid y País Vasco (p. 1).

    3. Diagnóstico del Modelo Predictivo Geoespacial (Spatial Regression)

    • Poder Explicativo de la Ubicación: El modelo de regresión lineal múltiple (OLS) parametrizado con variables puramente geográficas arrojó un R^2  ajustado de 0.192. Esto demuestra matemáticamente que la localización (coordenadas vectoriales y región) es capaz de explicar de forma aislada el 19.2% de la variabilidad total de los precios de los apartamentos en España.
    • Gradiente de Precios y Sesgo Regional: La regresión confirmó la influencia del eje Norte-Sur del país a través de la variable latitude, la cual posee un coeficiente positivo y altamente significativo. Asimismo, se identificó que la región de Canarias inyecta el mayor impacto positivo marginal en la tasación promedio , contrastando con penalizaciones significativas en la valoración media de regiones como Galicia o Cataluña tras ajustar por el resto de factores espaciales .
    • Limitaciones del Modelo Baseline: El elevado número de condiciones del modelo alerta sobre la existencia de multicolinealidad entre los predictores espaciales. Además, la falta de normalidad en la distribución de los residuos (confirmada por el test de Jarque-Bera) evidencia la necesidad de transicionar en futuras iteraciones hacia arquitecturas no lineales (como Random Forest Regressor o XGBoost) e incorporar las variables estructurales desestimadas (m2_real y bath_num) para elevar la robustez del ajuste predictivo.

    Recomendaciones Estratégicas para Stakeholders

    • Para Inversores Internacionales (EE. UU.): Las regiones de Castilla-La Mancha y Comunidad Valenciana presentan las oportunidades de arbitraje más eficientes en coste por unidad de superficie, ofreciendo apartamentos sustancialmente más amplios a tasas de cotización bajas. Por el contrario, Madrid y Cataluña representan mercados altamente competitivos y compactos con ratios elevados de precio por pie cuadrado.
    • Para Desarrolladores Urbanos: Dada la fuerte correlación de la variable bath_num con el precio de mercado, los proyectos de optimización de activos (house flipping o remodelaciones residenciales) deben priorizar la adición o mejora de un segundo o tercer cuarto de baño por encima de la subdivisión de dormitorios, maximizando el retorno de la inversión (ROI) por metro cuadrado.

    Stack Tecnológico y Entorno de Ejecución (Tech Stack)

    Para garantizar la reproducibilidad de este entorno de análisis, se detallan las tecnologías y librerías de Python utilizadas en el pipeline:

    • Manipulación y Core AnalíticoPython 3.xPandasNumPy.
    • Ingeniería GeoespacialGeopy (Motor OpenStreetMap/Nominatim).
    • Inferencia Estadística y ModeladoSciPy (módulo stats para ANOVA y Pearson), Statsmodels / Scikit-Learn (Regresión Lineal).
    • Visualización de Datos y BIMatplotlibSeabornTableau Desktop / Public.

    https://github.com/fer78/Data-Analytics-Final-Portfolio-Project.git