Datos de ventas en todos los canales
Reporting multicanal sin Excel-Frankenstein. Una source of truth en vez de stitching manual.
Contexto
¿Qué palancas hacen consolidables los datos de ventas multicanal?
Por qué los datos están fragmentados en primer lugar
Cada canal de venta entrega datos en su propio formato: Shopify tiene un schema, Amazon otro, el sistema TPV el suyo, el equipo comercial de campo reporta por Excel. Aunque los contenidos sean similares (producto, cantidad, precio, fecha), difieren los nombres de columnas, las zonas horarias, las monedas y la lógica fiscal. Sin un modelo de datos unificado, cada informe se convierte en su propia verdad — y las diferencias ya no se pueden explicar.
Qué define un modelo de datos central
Un buen modelo de datos multicanal tiene una tabla para todos los eventos de venta — sin importar la fuente. Cada registro tiene los mismos campos: canal, ubicación, marca de tiempo (en una zona horaria unificada), ID de producto, cantidad, ingreso bruto y neto, importe de impuestos. Las peculiaridades específicas de cada plataforma se normalizan en la pipeline, no en el dashboard. Así, después se puede hacer cualquier pregunta sin tener que construir lógica de informe por canal.
Los informes de marketplaces y sus peculiaridades
Los marketplaces como Amazon, Otto o Zalando suelen entregar informes con retraso y con su propia lógica de agregación: las devoluciones se contabilizan a veces hasta 30 días más tarde, los costes de publicidad se entregan en un informe separado con otra granularidad, la entrada de pago con otro desfase distinto. Quien no modela estas peculiaridades sí ve cifras en el dashboard — pero no el margen de contribución real por canal.
Por qué la consolidación manual casi siempre produce errores
Los estudios sobre calidad de datos en informes basados en Excel (Panko 1998, KPMG, PwC) muestran: en el 88 % de todas las hojas de cálculo con complejidad no trivial se encuentran errores materiales. Con una consolidación multicanal manual a lo largo de un año — con actualizaciones diarias de más de 5 fuentes — la probabilidad de que a final de año exista al menos un error con más del 1 % de desviación de ingresos es de hecho del 100 %.
Las causas principales no son la incompetencia, sino estructurales: deriva de schema ante actualizaciones de API, confusión de zonas horarias, errores manuales de copy-paste, contabilizaciones de devoluciones olvidadas, distinta lógica fiscal por marketplace.
Una arquitectura de datos central destierra el riesgo no mediante un mejor Excel — sino mediante validación automatizada: tests de schema en cada importación, chequeos de reconciliación entre fuentes, alertas ante desviaciones por encima de umbrales definidos.
Preguntas frecuentes
Preguntas frecuentes sobre datos de ventas multicanal
¿Cuántas fuentes de datos se pueden integrar con sentido?
Técnicamente no hay un límite duro — pero en la práctica merece la pena un enfoque escalonado.
Fase 1 (típicamente 3–5 fuentes): los canales de venta más importantes más una fuente de CRM. Con eso normalmente cubres el 80–90 % de los ingresos y puedes basar en ello las mayores decisiones. Esfuerzo de setup: 6–10 semanas.
Fase 2 (ampliación a 8–15 fuentes): datos de marketing (Meta, Google Ads), plataformas de email, sistemas de almacén y logística. Aquí el foco se desplaza de «medir ventas» a «dirigir el negocio». Por fuente, 1–2 semanas de esfuerzo de setup.
Qué determina el límite: no la elección de herramientas, sino el mantenimiento de datos. Más de 20 fuentes activas rara vez tienen sentido sin un equipo de datos dedicado.
¿Tiempo real o agregación diaria — qué basta?
La respuesta depende de qué decisiones tomas sobre los datos — el tiempo real es más caro y complejo y no tiene sentido para cada caso de uso.
Diferencia de coste: las pipelines en tiempo real cuestan típicamente 3–5× más que los batches diarios — tanto infraestructura como setup.
Consejo práctico: empieza con agregación diaria. Si tras 6 meses aparecen casos de uso concretos de tiempo real, reconvierte streams individuales de forma selectiva — no todo a la vez.
- La agregación diaria basta: informes operativos (CFO, marketing, responsables de tienda), reviews de ventas semanales, rutinas de reporte mensuales, análisis de cohortes estratégicos
- El tiempo real merece la pena: avisos operativos de rotura de stock, pricing de marketplace en tiempo real, dashboards en vivo para promociones, monitorización de fraude
¿Cuánto cuesta BigQuery al mes de forma realista?
BigQuery tiene una lógica pay-per-use con dos principales generadores de coste: almacenamiento y costes de consulta.
Comparación con alternativas: una herramienta BI SaaS clásica para una funcionalidad comparable cuesta a menudo 500–2.000 € al mes por seat — con 5 usuarios eso son rápidamente 2.500–10.000 €. BigQuery es casi siempre más barato en coste total de propiedad.
- Pequeño (1–5 M de eventos de venta/mes, 3–5 fuentes): típicamente 30–80 € de almacenamiento + consulta
- Medio (5–30 M de eventos/mes, 5–10 fuentes): típicamente 80–250 €
- Grande (más de 50 M de eventos/mes, más de 10 fuentes, muchos dashboards): 300–800 €
- Enterprise (tiempo real + muchos usuarios concurrentes): desde 1.000 € — aquí merecen la pena los contratos de capacidad reservada
¿Herramientas cloud o desarrollo propio — qué encaja conmigo?
Una de las decisiones más importantes — y depende más de tu equipo que del volumen de datos.
El híbrido suele ser la mejor solución: fuentes estándar vía herramientas cloud (p. ej. Airbyte para Shopify, Stripe), fuentes custom vía desarrollo propio (p. ej. API de Lightspeed, informes de marketplace). dbt como capa de transformación es el mismo en ambos casos.
Regla general para la compensación de costes: las herramientas cloud cuestan a menudo 100–500 € al mes por fuente — con 10 fuentes son 1.000–5.000 € al mes. El desarrollo propio tiene costes de setup de 4–8 horas por fuente, luego costes recurrentes de 0 €. A partir de 6 fuentes, el break-even se alcanza normalmente tras 12 meses.
- Las herramientas cloud merecen la pena: sin data engineers internos, APIs mayormente estándar, un time-to-value rápido más importante que costes optimizados
- El desarrollo propio merece la pena: fuentes propietarias, volumen de datos exponencial para SaaS, lógica de transformación especial, el cumplimiento exige control total
¿Necesito dashboards distintos para CFO y marketing?
Sí — y es uno de los insights más importantes que se interiorizan tras los primeros proyectos multicanal. Construir una única vista para todos los stakeholders es casi siempre un error.
Importante: todas las vistas se basan en los mismos datos en bruto del data warehouse. Solo la capa de agregación y visualización se hace a medida por público. De lo contrario surgen de nuevo los conflictos de datos entre áreas que en realidad queríamos evitar.
- Vista CFO: ingreso bruto, ingreso neto, impuestos por canal y ubicación, cifras ajustadas por devoluciones, comparación con el forecast, margen/contribución
- Vista marketing: rendimiento por campaña/canal/creatividad, análisis de cohortes, CLV, tasa de repetición, atribución de canal, tiempo real durante promociones
- Vista tienda/ventas: ingreso diario por ubicación y empleado, productos top/flop, comparación con el periodo anterior y con otras tiendas
¿Puedo también reconstruir datos históricos a posteriori?
Sí, en la mayoría de los casos los datos históricos se pueden construir a posteriori — con algunas limitaciones concretas por fuente.
Enfoque típico: un backfill inicial de los últimos 12–24 meses durante el setup, tras lo cual la pipeline continúa con los datos en curso. Con volúmenes de datos mayores, el backfill se hace en chunks semanales.
Importante: la reconstrucción es una inversión única con un esfuerzo claramente estimable. La calidad de datos continua es más importante a largo plazo que la profundidad histórica — si tuvieras que elegir entre 5 años hacia atrás y una pipeline limpia para el futuro, elige la pipeline.
- Bien reconstruible: Shopify (2 años hacia atrás vía API), marketplaces como Amazon/Otto/Zalando (1–2 años), sistemas TPV (mayormente disponibles localmente), datos de CRM (completos)
- No, o solo parcialmente, reconstruible: datos de fuentes apagadas, correcciones manuales de Excel sin audit trail, informes agregados de herramientas sin exportación de datos en bruto
¿Cómo transcurre típicamente una primera consulta para un proyecto así?
Una primera consulta típica para datos de ventas multicanal dura unos 30–45 minutos y está concebida deliberadamente para clasificar tu caso — no para vender un paquete cerrado.
Lo que no es: una llamada de venta con presión. Si tu caso es demasiado pequeño, demasiado grande o temáticamente inadecuado para mí, lo digo abiertamente — y te menciono alternativas adecuadas si hace falta.
- Lo que hablamos: qué fuentes de venta existen hoy y cuáles faltan, dónde está el mayor dolor de datos, qué conocimiento de datos hay en el equipo, qué herramientas se usan ya
- Lo que tienes después: una valoración de si tiene más sentido una auditoría de tracking o un proyecto de arquitectura de datos, un orden de magnitud aproximado (esfuerzo, duración, coste), recomendaciones de acción concretas incluso sin más colaboración
Para quién es relevante
¿Te reconoces en alguno de estos puntos?
Si aunque sea uno solo de estos te aplica, deberías revisar tu arquitectura de datos de ventas.
Cuando vendes por varios canales y no tienes una vista consolidada
Tienda, Amazon, marketplaces, ventas de campo, TPV — cada fuente entrega sus propias cifras, pero nadie conoce la suma. Las decisiones estratégicas se toman con base en la corazonada, no en datos.
Cuando cada marketplace tiene su propio reporting
Amazon, Otto, Zalando, Shopify — cada uno con su propia lógica de reporting, sus propias contabilizaciones de devoluciones y sus propios informes de costes publicitarios. Los datos no se concilian por sí solos durante semanas, sin un modelo central.
Cuando tu equipo de campo envía archivos Excel que nadie mantiene de forma central
Los informes creados manualmente llegan tarde, en formatos distintos y sin estándares de datos claros. La consolidación ocurre por copy-paste — y queda obsoleta de inmediato otra vez.
Cuando no puedes comparar la tasa de conversión por ubicación
Tienda A en Múnich, tienda B en Hamburgo, tienda online, marketplaces — todas con condiciones de conversión distintas, pero sin un modelo de datos de comparación unificado. Los mejores y peores performers permanecen invisibles.
Cuando tu CFO da cifras distintas a las de tu marketing
Ese es el síntoma clásico de datos de venta fragmentados: cada área usa sus propias fuentes con su propia lógica. Las discusiones giran entonces en torno a definiciones de cifras, no a decisiones estratégicas.
Mi enfoque
5 fases que consolidan tus datos de ventas
Mi respuesta a los datos multicanal fragmentados: un framework de 5 fases que convierte 5 informes en una vista clara de los ingresos — del inventario al reporting continuo.
PHASE 01
Inventario de datos
Captura completa de todas las fuentes de venta: tienda, TPV, marketplaces, Excel de ventas de campo, CRM. Schemas, zonas horarias, lógica fiscal documentados.
PHASE 02
Diseño del modelo de datos
Un schema unificado para todos los eventos de venta. Lógica de normalización por fuente. Zonas horarias, monedas, devoluciones claramente definidas.
PHASE 03
Construcción de la pipeline
Conectores de fuente, capa de transformación dbt, BigQuery como data warehouse central. Actualización diaria u horaria.
PHASE 04
Dashboards
Looker Studio o Metabase. Una capa de vista propia por público: CFO, marketing, ubicaciones de venta.
PHASE 05
Rutinas de reporting
Informes diarios y semanales automatizados a los stakeholders. Chequeos de calidad de datos en segundo plano. Alerta ante desviaciones.
Mi stack
Con qué herramientas trabajo
Fuentes de datos
Shopify · Lightspeed · marketplaces
APIs de tienda, TPV y marketplace juntas.
Conectores
Airbyte · Fivetran
Conectores cloud para fuentes estándar.
Data warehouse
BigQuery · Snowflake
Un data warehouse central con lógica pay-per-use.
Transformación
dbt · GitHub Actions
Schema versionado con tests automatizados.
Dashboards
Looker Studio · Metabase
Capas de vista específicas por stakeholder.
Calidad y alertas
Great Expectations · Slack
Tests de calidad de datos + alerta ante deriva.
Timeline
Vía exprés: setup priorizado con los 2 canales más importantes en 3 semanas — los demás siguen de forma iterativa.
Primera consulta gratuita
Hablemos
Los datos de ventas multicanal rara vez son un proyecto estándar. Antes de venderte una auditoría o un proyecto de arquitectura, quiero entender dónde está tu verdadero cuello de botella — y si para ti tiene sentido una auditoría de tracking dirigida, un workshop de arquitectura de datos o un proyecto de pipeline completo.
Incluido
- ✓Una valoración de tu situación de datos de ventas en 30–45 minutos
- ✓Recomendaciones de acción concretas — incluso sin más colaboración
- ✓Una estimación de orden de magnitud (esfuerzo, duración, coste)
- ✓Una recomendación de alternativas adecuadas si tu caso es temáticamente inadecuado
Contenido relacionado
Contenido relacionado

GEO vs. SEO — qué viene después de Google
Generative Engine Optimization: Cómo los LLMs como ChatGPT y Perplexity seleccionan contenido, y qué cambia para las marcas.
Leer
Atribución tras la muerte de las cookies
El primer clic y el último clic asignan mal los presupuestos — un framework para la atribución basada en datos con señales de servidor, datos propios y medición incremental.
Leer
La Matriz de Velocidad de Conversión
Cómo la arquitectura de tu martech stack determina la rapidez con la que los prospectos se convierten en clientes — un marco estratégico para decisores B2B.
Leer