El modelo de datos en eCommerce: la base invisible que decide si tus KPIs dicen la verdad
En muchos proyectos de analítica para eCommerce ocurre algo curioso.
La conversación suele empezar así:
— Queremos un dashboard.
— Necesitamos ver ventas por canal.
— Queremos analizar clientes, conversión y margen.
Y rápidamente el foco se pone en la herramienta:
Power BI.
Looker.
Tableau.
Metabase.
O incluso dashboards dentro del propio CMS del eCommerce.
Pero hay una realidad incómoda que pocos mencionan:
Si el modelo de datos está mal construido, todo el análisis posterior está contaminado.
Los gráficos pueden ser espectaculares.
Los KPIs pueden parecer coherentes.
Y aun así, estar contando una historia equivocada.
En eCommerce esto es especialmente crítico, porque muchas decisiones del negocio dependen directamente de esos números.
El gran error en analítica de eCommerce
La mayoría de proyectos de analítica siguen este orden:
-
Exportar datos desde el eCommerce
-
Conectar tablas del ERP o CRM
-
Relacionar todo rápidamente
-
Crear visualizaciones
El problema es que ese enfoque suele generar modelos de datos con defectos estructurales.
Entre los más habituales encontramos:
-
relaciones ambiguas entre tablas
-
cardinalidades incorrectas
-
granularidades mezcladas
-
columnas calculadas donde deberían existir medidas
-
tablas duplicadas para resolver problemas de visualización
Al principio todo parece funcionar.
Hasta que aparece una pregunta nueva del negocio.
Por ejemplo:
-
¿Cuál es el margen real por canal de adquisición?
-
¿Cuánto aporta cada cliente recurrente en los últimos 12 meses?
-
¿Qué productos generan realmente rentabilidad y cuáles solo facturación?
En ese momento el modelo empieza a romperse.
Y el equipo descubre que los datos no estaban preparados para responder esas preguntas.
El modelo de datos en eCommerce no es técnico, es estratégico
El modelo de datos es la representación estructurada del negocio.
En eCommerce significa traducir operaciones reales a una arquitectura analítica clara.
Pedidos
Clientes
Productos
Promociones
Canales
Logística
Devoluciones
Todo debe poder analizarse sin ambigüedad.
Para lograrlo, el enfoque más robusto sigue siendo el esquema en estrella (star schema).
Este modelo separa claramente dos tipos de tablas:
Tablas de hechos
Representan eventos del negocio.
En eCommerce suelen ser:
-
pedidos
-
líneas de pedido
-
movimientos de inventario
-
sesiones de usuario
-
eventos de conversión
Cada fila debe representar un evento concreto y medible.
Por ejemplo:
una línea de pedido con producto, precio, descuento y cantidad.
Si mezclamos varias granularidades en una misma tabla, el análisis se vuelve inconsistente.
Tablas de dimensiones
Aportan contexto a los hechos.
Ejemplos típicos en eCommerce:
-
clientes
-
productos
-
categorías
-
fechas
-
canales de marketing
-
regiones
Las dimensiones permiten segmentar el negocio.
Por ejemplo:
ventas por categoría
ventas por canal
ventas por cliente
Sin dimensiones bien diseñadas, el análisis pierde significado.
La importancia de la granularidad
Uno de los errores más comunes en analítica de eCommerce es mezclar granularidades sin control.
Ejemplo típico:
Tabla pedidos → nivel pedido
Tabla líneas de pedido → nivel producto
Si no se modela correctamente la relación entre ambas, los KPIs pueden duplicarse.
Esto afecta directamente a métricas clave como:
-
facturación
-
unidades vendidas
-
margen
-
ticket medio
Un simple error en la granularidad puede inflar o reducir métricas sin que nadie lo detecte.
Y ese es el tipo de error más peligroso.
Cardinalidades: el detalle que rompe dashboards
Otro aspecto crítico en modelos analíticos es la cardinalidad de las relaciones.
Uno a muchos
Muchos a uno
Muchos a muchos
En eCommerce, una relación mal definida puede provocar efectos inesperados en el contexto de filtros.
Ejemplo:
Un cliente con múltiples pedidos.
Si la relación entre clientes y pedidos no está bien definida, los análisis por cliente pueden generar duplicaciones.
Esto impacta directamente en métricas como:
-
Customer Lifetime Value
-
número de pedidos por cliente
-
recurrencia
El problema de las columnas calculadas
Muchos analistas intentan resolver problemas creando columnas calculadas.
Esto suele ser una mala práctica.
Las columnas calculadas fijan resultados estáticos.
Pero los KPIs en eCommerce deben responder al contexto de análisis.
Por ejemplo:
-
margen por categoría
-
conversión por canal
-
ticket medio por campaña
Estos cálculos deben implementarse como medidas dinámicas, no como columnas.
Cuando se mezclan ambos conceptos, los dashboards empiezan a generar inconsistencias.
El error invisible en analítica de eCommerce
Hay algo especialmente peligroso en los modelos mal diseñados.
A menudo no generan errores visibles.
Los dashboards funcionan.
Los filtros responden.
Los números parecen cuadrar.
Pero el análisis puede estar respondiendo a preguntas equivocadas.
Por ejemplo:
un informe puede mostrar ventas por canal aparentemente correctas…
pero estar asignando pedidos al canal incorrecto debido a una mala relación.
En ese momento el equipo toma decisiones estratégicas basadas en información distorsionada.
Qué debería incluir un buen modelo analítico para eCommerce
Un modelo de datos sólido para eCommerce suele incluir al menos:
Tablas de hechos
-
pedidos
-
líneas de pedido
-
devoluciones
-
eventos de usuario
-
movimientos logísticos
Dimensiones
-
clientes
-
productos
-
categorías
-
canales de adquisición
-
campañas
-
fechas
Métricas clave
-
facturación neta
-
margen real
-
ticket medio
-
tasa de conversión
-
recurrencia de clientes
-
coste de adquisición
Y todo ello conectado con reglas claras de granularidad y cardinalidad.
Analítica en eCommerce: antes de dashboards, arquitectura
En muchos proyectos de transformación digital el dashboard se considera el final del proceso.
En realidad es solo la superficie visible.
Debajo existe algo mucho más importante:
la arquitectura analítica del negocio.
Si esa arquitectura está bien diseñada:
-
los dashboards son fiables
-
los KPIs responden correctamente
-
las decisiones se basan en datos reales
Si está mal diseñada:
los gráficos pueden ser impresionantes…
pero el análisis no tiene base.
Conclusión
El modelo de datos no es una fase técnica previa al análisis.
Es el propio análisis convertido en arquitectura.
Por eso, antes de diseñar dashboards en un proyecto de eCommerce, merece la pena invertir tiempo en algo que no se ve.
Pensar.
Diseñar.
Y construir un modelo que represente realmente cómo funciona el negocio.
Porque en analítica hay una regla simple:
los dashboards se pueden rehacer.
los modelos de datos mal diseñados hay que reconstruirlos.
Si estás trabajando en analítica para eCommerce y quieres evitar estos problemas desde el inicio, en eComm360 ayudamos a diseñar arquitecturas de datos orientadas a negocio, integrando eCommerce, ERP y sistemas de marketing en modelos analíticos robustos.