/ Proyectos / Negocios / Análisis de delivery de comida
Análisis exploratorio de datos de un negocio de delivery de comida
Convertir 1,898 pedidos crudos en recomendaciones de negocio verificables, traduciendo reglas ambiguas a código exacto y validando cada hallazgo antes de convertirlo en recomendación.
El objetivo era convertir los datos de pedidos de una app de delivery en recomendaciones de negocio accionables, sin ningún modelo predictivo de por medio. El problema real no era técnico, era de criterio: cualquiera puede correr `.describe()` sobre un dataset, pero convertir esos números en una recomendación defendible requiere validar que el hallazgo realmente sostiene la conclusión.
El hallazgo que mejor resume el nivel de este análisis no aparece en ningún resumen estadístico obvio. Al graficar la distribución de calificaciones, **no existe ninguna calificación de 1 o 2 estrellas** en los 1,898 pedidos. Solo aparecen "sin calificar", 3, 4 y 5. Eso cambia por completo cómo se debe leer el 39% de pedidos sin calificación: no es un dato faltante al azar, es probablemente insatisfacción que el cliente eligió no expresar como calificación baja.
Mapa del casoContenido
- Diagrama de la solución. El flujo de datos crudos a recomendaciones validadas
- Construcción de la solución. Cómo la ambigüedad de las reglas de negocio dirigió cada decisión
- Condiciones del proyecto. Restricciones reales y opciones descartadas antes de construir
- Pasos. Qué se dejó al agente y qué criterio se aplicó en cada uno
- Proceso de iteración. El hallazgo inesperado en la distribución de calificaciones
- Descargables. Notebook, diagrama y repositorio del proyecto
- Lecciones importantes. La lección concreta que deja este caso
Estructura de alto nivelDiagrama de la solución
Pasa el cursor sobre cada bloque para ver que hace ese paso.
No hay bloque de "modelo" en este pipeline a propósito — la traducción de reglas de negocio a código exacto ocupa ese lugar, porque es ahí donde vive el criterio de ingeniería en un proyecto que no requiere predicción.
De la teoría a la prácticaConstrucción de la solución
Condiciones del proyecto
| Restricción | Dato |
|---|---|
| Tamaño del dataset | 1,898 pedidos, 9 columnas, sin valores nulos declarados |
| Codificación de la calificación | Mezcla texto ("Not given") y números en la misma columna |
| Reglas de negocio recibidas | En texto, con casos límite no explícitos (ej. comisión exactamente en $20) |
| Salida requerida | Recomendaciones de negocio, no un modelo ni una API |
| Opción | Por qué se descartó |
|---|---|
| Convertir la columna de calificación a número directamente | Falla o genera valores nulos silenciosos por el texto "Not given" mezclado |
| Asumir los límites de la comisión sin decidirlos explícitamente | El revenue reportado cambiaría según cómo cada quien interprete el límite de $20 o $5 |
| Filtrar antes de convertir tipos + decidir explícitamente cada límite de las reglas de negocio | Hace el resultado reproducible, sin depender de un supuesto no documentado |
Pasos
Chequeo de calidad de datos
Agente: reportó "cero valores nulos" y dio por cerrada la validación de calidad.
Criterio aplicado: revisar los valores únicos de cada columna categórica, no solo los nulos — así se encontró que "Not given" en `rating` es un valor faltante disfrazado de string, no un `NaN`.
Cálculo de revenue por comisión
Agente: implementó la regla usando `>=` para ambos límites sin verificar contra el texto original.
Criterio aplicado: decidir explícitamente que $20.00 cae en el tramo de 15%, no en el de 25%, y documentar esa decisión en vez de dejarla implícita en el código.
Conversión de tipo en la columna de calificación
Agente: propuso usar `pd.to_numeric(errors='coerce')` para forzar la conversión.
Criterio aplicado: filtrar explícitamente los pedidos con "Not given" antes de convertir, para que quede claro en el código cuántos registros se excluyen y por qué, en vez de que se conviertan en `NaN` silenciosos.
Redacción de las recomendaciones finales
Agente: redactó "enfocarse en comida americana" como recomendación aislada.
Criterio aplicado: incluir la cercanía real entre el primer y segundo lugar (americana vs. japonesa) en la recomendación, para no simplificar una diferencia que en los datos no es tan grande.
Proceso de iteración
Ajuste documentado, no forzado
El plan original era simplemente reportar "39% de pedidos sin calificar" como una cifra de calidad de datos. Al graficar la distribución completa de calificaciones para verificar ese número, apareció algo que no estaba en el plan: no hay ninguna calificación de 1 ni 2 estrellas en todo el dataset. Solo existen "Not given", 3, 4 y 5. Esto no se puede explicar solo con "a la gente no le gusta calificar" — sugiere que el silencio del cliente está funcionando como la calificación negativa que el sistema no está capturando explícitamente. El hallazgo cambió la recomendación final: no se trata solo de "pedir más calificaciones", se trata de investigar por qué la insatisfacción no se refleja en el sistema de calificación actual.
CierreLecciones importantes
Un análisis exploratorio no necesita un modelo predictivo para generar valor real: necesita que cada hallazgo se valide contra los datos antes de convertirse en recomendación. La ausencia total de calificaciones bajas fue más informativa que el porcentaje de pedidos sin calificar por sí solo, y solo apareció porque se graficó la distribución completa en vez de confiar en un resumen estadístico. Las reglas de negocio en texto siempre tienen casos límite sin decidir, y quien traduce esas reglas a código es quien termina decidiéndolos, con o sin intención.
Si quieres ver un enfoque publicado con una idea similar, análisis de datos de pedidos y comportamiento de clientes en plataformas de delivery, este artículo es una buena referencia del nivel de la contribución: Understanding food delivery app user behavior: a data-driven perspective.
Termina ya tu proyecto
¿Tienes un proyecto similar y no sabes por dónde empezar? Yo te ayudo a diseñarlo.
El 92% de los profesionales de datos desbloquea sus proyectos al ver ejemplos completos resueltos.
Sin registro. Acceso inmediato