En e-commerce rara vez faltan datos; falta una imagen coherente de ellos. El escaparate sabe una cosa, la plataforma publicitaria otra, el almacén y el ERP otra distinta, y el CRM una versión más. El resultado es que las decisiones más importantes sobre surtido, margen y gasto de captación se toman a menudo a ojo y no con números. Para un responsable de datos, de e-commerce o de crecimiento, la conclusión es simple: la analítica de e-commerce tiene que ser un producto mantenido por derecho propio, no un montón de informes a la deriva.
Por nuestra experiencia, lo difícil no es dibujar un gráfico, sino llevar los datos a un estado en el que ese gráfico se pueda creer. Eso requiere gente que entienda a la vez los eventos del escaparate, el modelado de datos y la realidad de un negocio online. Aunque no tengamos un caso de éxito en tu nicho exacto, aportamos las competencias para construir esa analítica de principio a fin, del evento crudo a la previsión, como refuerzo de equipo o equipo dedicado.
¿Por qué están tan repartidos los datos de e-commerce?
Porque cada sistema se construyó para operar, no para reportar. La plataforma de e-commerce registra pedidos pero no sabe nada del coste publicitario. La plataforma de anuncios conoce el coste por clic pero no si el cliente devolvió el artículo. El almacén conoce el stock pero no lo ata al margen. Así, las mismas ventas aparecen de forma distinta en cuatro sitios.
Encima se superpone una capa técnica: definiciones distintas de «sesión», «conversión» y «usuario», eventos perdidos por bloqueadores y cambios de navegador, e identificadores de cliente que no se unen entre dispositivos. Mientras no haya una definición acordada de las métricas y una fuente de verdad, cada equipo defiende su propia versión de las cifras. Nuestro primer trabajo suele ser exactamente esa limpieza, antes de que exista ningún cuadro de mando bonito.
¿Qué informes y cuadros de mando construimos más a menudo?
Empezamos por la capa que de verdad cambia las decisiones diarias del equipo, no por pantallas impresionantes pero muertas:
- un cuadro de mando de ventas y margen en el tiempo, desglosado por canal, categoría y dispositivo,
- una vista de captación (coste, ROAS, CAC) contrastada con el valor real del cliente, no solo con los clics,
- un informe de devoluciones y reclamaciones, porque en muchas tiendas es lo que se come el margen,
- alertas y anomalías que señalan una caída de conversión o un pico de coste antes de que lo vea una persona.
La clave es que cada cuadro de mando calcule sus métricas con una definición compartida. Por eso mantenemos la lógica de negocio en la capa de modelado de datos, y no incrustada en una única herramienta de BI donde nadie salvo el autor puede reproducirla.
¿Cómo es el pipeline de eventos y la telemetría de la tienda?
Un buen informe empieza mucho antes del gráfico, en el punto donde se recogen los eventos. Diseñamos una capa de telemetría que captura lo que el cliente hace de verdad: ver un producto, añadir al carrito, iniciar el checkout, comprar, devolver. Ese flujo de eventos es la base de todo lo demás.
Técnicamente lo conectamos a un pipeline que recoge eventos del front y del backend, los valida contra un esquema acordado, los carga en un almacén o un lago y solo allí los convierte en modelos listos para analizar. Preferimos un enfoque por eventos, del lado del servidor siempre que sea posible, porque hoy la recogida solo desde el navegador no es fiable. Todo el conjunto va bajo CI/CD y monitorización, para que una etiqueta rota o un cambio en el escaparate no estropee en silencio semanas de datos.
¿Cómo hacer un análisis de embudo y de cohortes que lleve a algún sitio?
El análisis de embudo solo se gana su sitio cuando muestra dónde exactamente pierdes dinero, y no solo que «la conversión bajó». Construimos embudos que se pueden desmontar y comparar entre segmentos:
- paso a paso desde la llegada, pasando por la ficha de producto y el carrito, hasta el pago,
- desglosados por fuente de tráfico, dispositivo y segmento de cliente, porque un embudo móvil desde un anuncio no se parece en nada a uno de escritorio desde un boletín,
- con análisis de cohortes que muestra cómo se comportan en las semanas siguientes los clientes captados en un mes dado,
- con retención y recompra, no solo con la primera conversión.
Son las cohortes y la retención las que responden a si creces de forma sana o solo viertes presupuesto publicitario en un cubo agujereado. Son las vistas que más a menudo cambian las decisiones sobre dónde merece la pena invertir.
¿Cómo reportar sobre surtido y margen, no solo sobre ingresos?
Los ingresos pueden subir mientras el beneficio baja, y sin buenos informes nadie lo detecta a tiempo. Por eso construimos la analítica de surtido alrededor del margen, la rotación y la rentabilidad por referencia, no del número de unidades vendidas. Unimos los datos de venta con el coste de compra, el coste logístico y las tasas de devolución para mostrar el resultado real por producto y categoría.
Esa imagen responde a las preguntas que mueven el resultado de verdad: qué productos ganan dinero y cuáles solo traen tráfico; qué está parado en el almacén inmovilizando capital; dónde una promoción levantó las ventas y dónde simplemente regaló margen. Un informe de surtido es bueno cuando compras y finanzas miran las mismas cifras y sacan de ellas las mismas conclusiones.
¿Cómo prever la demanda y el stock con ML?
Cuando la capa de datos está en orden, se puede subir a la previsión de demanda. Los modelos aprenden del histórico de ventas, la estacionalidad, las promociones y las tendencias para predecir la demanda a nivel de producto y de ubicación. Una buena previsión se traduce directo en dinero: menos roturas de stock en los superventas y menos capital congelado en mercancía que no se moverá.
Nuestra competencia en IA y datos abarca construir esos modelos y, más importante, conectarlos a un proceso real de compras e inventario. Vigilamos las cosas que deciden si un modelo llega a adoptarse:
- ajustar el horizonte y la granularidad de la previsión a cómo haces realmente los pedidos,
- backtesting honesto sobre datos históricos, en vez de métricas impresionantes sin nada detrás,
- comunicación clara de la incertidumbre, para que un planificador sepa cuándo fiarse del modelo y cuándo no,
- monitorización continua de la calidad de la previsión, porque el mercado y el surtido cambian sin parar.
Tratamos un modelo como parte de un producto que hay que mantener, no como un experimento puntual en un cuaderno.
¿Cómo conciliar la analítica con la privacidad y el consentimiento?
La analítica de e-commerce tiene que funcionar hoy en un mundo de consentimiento real del usuario y cookies de terceros en retirada. Por nuestra experiencia eso no es un bloqueo, sino una cuestión de buena arquitectura. Nos apoyamos en datos first-party y recogida del lado del servidor, más resistente a los bloqueadores y con una imagen más completa que las etiquetas de navegador solas. A la vez respetamos las decisiones del usuario, llevando el consentimiento por todo el pipeline para que los eventos sin consentimiento no acaben donde no deben.
En la práctica eso significa diseñar la capa de recogida pensando en la privacidad desde el primer día: minimizar los datos personales, seudonimizar los identificadores y fijar reglas claras de retención. Una analítica bien diseñada es a la vez conforme y útil, y esa es la base de la que partimos, no algo pegado al final.
¿Qué competencias aportamos a un proyecto de analítica?
Formamos el equipo alrededor de la fase concreta y de las particularidades de la tienda, no «por si acaso». Lo más habitual es que nuestros especialistas entren en roles como:
- un ingeniero de datos que construye el pipeline de eventos, el almacén y los modelos de datos,
- un analista / ingeniero de BI que diseña los cuadros de mando y acuerda las definiciones de métricas con el negocio,
- un data scientist / ingeniero de ML para previsiones de demanda, segmentación y recomendaciones,
- un arquitecto de datos que lo ata todo y vela por la calidad y el cumplimiento.
Detrás de esto está nuestra experiencia real en proyectos de Big Data e IA/datos, incluidas soluciones construidas sobre LLM y modelos predictivos. Eso nos permite cubrir no «pares de manos para SQL», sino roles que asumen toda la cadena, del evento a la decisión.
¿Cómo lo hacemos en RITS?
Lo hacemos como partner nearshore desde Polonia que añade competencias donde faltan, en vez de vender un producto cerrado y prefabricado:
- diseñamos la capa de datos desde el evento crudo hasta un modelo listo para el negocio, no solo enchufamos otra herramienta,
- acordamos las definiciones de métricas entre marketing, ventas y finanzas, para acabar con las discusiones sobre las cifras,
- verificamos las competencias antes de empezar y formamos el equipo según la fase del proyecto y el stack del cliente,
- trabajamos en una zona horaria cercana, así que entramos en tus reuniones, revisiones y publicaciones sin una larga puesta en marcha.
Lo más frecuente es entregarlo como software a medida construido por nuestro equipo y, cuando hay que completar efectivos rápido, como refuerzo de equipo.
¿Por dónde empezar a construir analítica de e-commerce?
Empieza por una decisión que hoy se toma a ojo (por ejemplo, cuánto pedir de un superventas, o dónde recortar gasto publicitario) y por la pregunta de qué datos necesitas de verdad para ella. Eso define qué eventos recoger, cómo modelarlos y qué informe tiene que cambiar un comportamiento. Es mejor poner en marcha una vista fiable que el equipo use de verdad que diez cuadros de mando preciosos en los que nadie cree. Las diferencias entre modelos de colaboración las describimos en nuestro artículo sobre modelos de colaboración en TI.
¿Vas a construir analítica de ventas y comportamiento en e-commerce? Hablemos - ajustaremos el equipo y la arquitectura a tus datos y a tus decisiones.