Generar forecast con datos de ecommerce

Con eso, el resto del trabajo pasa por ordenar el histórico para que cada período tenga un solo valor, una sola lógica y contexto suficiente para proyectar sin mezclar ventas con errores de dato.

How To Forecast Ecommerce Revenue - Use This Simple 3 Metric Framework

This framework helps you understand your data, but you can also use an autonomous AI that runs your e‑commerce to handle these operations automatically.

Extraé y validá los campos de ecommerce

Con la métrica y la frecuencia ya definidas, extraé solo los campos que van a alimentar la serie temporal.

Quedate solo con las columnas que realmente necesitás

Trabajá con dos tablas: pedidos y líneas.

En la tabla de pedidos, quedate con estos campos: order_id, created_at, order_status, financial_status, cancelled_at y currency.

En la tabla de líneas, necesitás: order_line_id, order_id, sku, variant_id, quantity, unit_price y line_discount.

Para calcular ventas netas, sumá también las columnas de ajuste:

• refund_quantity
• refund_amount
• return_quantity
• return_amount

Si el negocio vende por varios canales o en distintas regiones, campos como channel, country o province son opcionales. Igual conviene traerlos desde el principio, porque te ahorran una segunda extracción más adelante. Si operás con más de un canal, centralizá esos campos antes de exportar.

Conservá el SKU, el precio y la descripción tal como estaban en el momento de la compra. Si después cambiaron en el catálogo, el histórico queda torcido.

Usá código ISO 4217, como ARS, y cargá los importes como valores numéricos, sin separadores.

Corré controles básicos de calidad antes de agregar

Antes de sumar cualquier número por día o por semana, revisá cuatro puntos:

• que order_id sea único en la tabla de pedidos
• que la combinación order_id + order_line_id sea única en la tabla de líneas
• que todos los timestamps estén normalizados a America/Argentina/Buenos_Aires
• que no haya importes vacíos o negativos por fuera de devoluciones

La zona horaria cambia el día al que pertenece cada pedido. Primero convertí a America/Argentina/Buenos_Aires y después asigná la fecha. Un pedido registrado a 00:30 UTC, por ejemplo, puede caer en el día anterior en Argentina. Guardá siempre el timestamp original en UTC como columna de auditoría.

Para filtrar estados, dejá la regla escrita antes de aplicarla. Por ejemplo: incluir pedidos con transacción confirmada o paga, y excluir tests, pedidos totalmente cancelados y registros inválidos. A los casos excluidos asignales exclusion_reason para mantener la trazabilidad.

Por último, reconciliá el total reconstruido desde las líneas contra el subtotal que informa la plataforma para ese mismo período. Si aparece alguna diferencia, documentala antes de pasar a la agregación.

Con los campos limpios y validados, ya podés agrupar por día o por semana.

Separar ventas brutas de ventas netas

Antes de agrupar por día o por semana, definí qué querés medir. Ventas brutas y ventas netas no son lo mismo. Si las mezclás en una sola serie, terminás combinando ingreso de producto con ajustes, y eso te ensucia la lectura.

Con esa base clara, ya podés separar la serie de ingreso sin cruzarla con descuentos, devoluciones o reembolsos.

Usá fórmulas fijas para cada campo de ingresos

Mantené la misma fórmula en todo el histórico. Si cambiás la lógica entre períodos, podés generar saltos que no vienen del negocio, sino del armado de los datos.

Las fórmulas base son estas:

• Ventas brutas: precio_unitario × cantidad_vendida
• Ventas netas: ventas_brutas − descuentos − devoluciones y reembolsos

Los impuestos y los cargos de envío no entran en ninguna de las dos. Conviene dejarlos en columnas separadas, fuera de la serie de forecast.

Con esta separación, la tabla ya queda lista para agrupar por día o por semana.

Aplicá una sola regla para devoluciones y reembolsos

Después, definí una sola regla para toda la serie. El punto clave es este: decidir en qué fecha vas a imputar cada ajuste. Puede ser en la fecha original de la venta o en la fecha del reembolso. Las dos opciones sirven, pero no conviene ir cambiando de criterio.

¿Por qué importa tanto? Porque el patrón diario cambia según la regla que uses. Y eso pega directo en la estacionalidad y en las metas del modelo.

Dejá esa decisión escrita en los metadatos del dataset. Por ejemplo: refund_policy = refund_date.

Con las métricas separadas y la regla de imputación ya definida, el paso siguiente es agrupar por período y armar la tabla final.

Agrupar por día o semana y armar la tabla final de forecast

Primero, normalizá fecha y agrupá por período. La idea es simple: convertí cada timestamp a la zona horaria de la tienda y, desde ahí, derivá fecha. Recién con esa base conviene sumar por día o por semana. Si no hacés este paso bien, los totales pueden correrse y el forecast arranca torcido.

Si el forecast es semanal, tomá siempre el lunes como inicio. En ese caso, asigná fecha al lunes de esa semana. Además, dejá la regla escrita de forma explícita como semana_inicio = lunes, zona_horaria = America/Argentina/Buenos_Aires y mantenela igual en todo el histórico. Nada de cambiar el criterio a mitad de camino.

Sumar las métricas clave y conservar los días sin ventas

Después, agrupá por fecha y sumá estas métricas:

• ventas_brutas_ars
• descuentos_ars
• devoluciones_reembolsos_ars
• ventas_netas_ars
• unidades
• pedidos

Para pedidos, contá order_id distintos.

Hay otro punto que suele pasarse por alto: conservá todos los días del rango. Los períodos sin ventas también tienen que estar en la tabla, con valor 0. Eso evita huecos raros en la serie y le da al modelo una señal más limpia.

Ahora bien, no todo cero significa lo mismo. Si ese 0 apareció por un stockout o por un fallo en la extracción, marcá ese caso en una columna aparte. Por ejemplo:

• stockout = 1
• dato_incompleto = 1

Ese contexto tiene que viajar separado. No conviene esconderlo dentro de las métricas porque después nadie entiende qué pasó en ese período.

Definir la tabla de salida para el modelo

Con los totales ya consolidados, armá una fila por período:

Los valores monetarios tienen que guardarse como números, sin símbolo ni separadores dentro del dataset. Para mostrar en Argentina, sí podés formatearlos como ARS 1.234.567,89. Pero el valor almacenado debe ser 1234567.89.

También usá stockout, feriado, promo_activa o cambio_precio como columnas de contexto, no metidas dentro de la venta neta. Con esta tabla armada, el paso siguiente ya es validar el dataset antes de mandarlo al modelo.

Conclusión: verificaciones finales antes de enviar los datos al modelo de forecast

Antes de exportar, revisá la tabla agregada de punta a punta. Este paso parece simple, pero te puede ahorrar un montón de problemas después. Si la base sale desordenada, el modelo aprende mal. Y cuando eso pasa, el forecast arranca torcido desde el minuto cero.

Checklist para una tabla lista para forecast

Además, adjuntá un diccionario de datos. Tiene que dejar claro el campo, la unidad, la moneda, la zona horaria, la frecuencia, el inicio de semana, la fórmula y cómo se tratan los nulos.

En otras palabras: no alcanza con que la tabla “se vea bien”. Tiene que quedar clara para vos, para otra persona del equipo y para el modelo. Recién ahí conviene exportarla y cargarla al forecast.

FAQs

¿Qué métrica conviene forecastar primero?

Para empezar, conviene proyectar las ventas históricas, porque son la base de cualquier modelo de demanda.

Después, sumá variables causales con buena cobertura y buena calidad, como clics, búsquedas, productos agregados al carrito y promociones o campañas activas. También asegurate de mantener consistentes las fechas (DD/MM/AAAA), el huso horario local (ART, UTC-3) y los precios en pesos argentinos ($).

¿Cuándo usar frecuencia diaria o semanal?

Usá frecuencia diaria cuando necesitás mover rápido la reposición o el inventario y ver cambios a nivel SKU–canal. Sirve mucho en situaciones donde el impacto aparece en cuestión de días, como pasa con el clima o los feriados.

Usá frecuencia semanal cuando te alcanza con una mirada más macro, por ejemplo para presupuestos o decisiones por categoría o mercado. También ayuda a bajar el ruido cuando la demanda cambia mucho de un día para otro.

En los dos casos, mantené una frecuencia consistente y completá los intervalos faltantes.

¿Cómo trato devoluciones y reembolsos?

Para meter devoluciones y reembolsos en tu forecast, sumá el historial de pedidos con los eventos de devoluciones y cancelaciones para armar una serie de demanda limpia.

Separá venta bruta de venta neta. La cuenta es simple: GMV neto = GMV × (1 − tasa de devolución). Después, registrá esos eventos por fecha y agregalos por día o por semana, pero siempre con la misma frecuencia, para que el efecto caiga en el período que corresponde.