Convea AI

Los equipos de eCommerce viven ahogados en dashboards. Shopify dice una cosa, Google Ads dice otra. Marketing cree que el ROAS sube, Finanzas dice que los ingresos están planos. Cada uno mira números distintos.

Los fundadores venían del mundo eCommerce. En todas las empresas, la misma historia: conectar datos de ads con Shopify para averiguar qué campañas funcionaban de verdad. Montaban pipelines a medida una y otra vez. Decidieron convertirlo en producto. Me sumé para montar la infraestructura de datos.

Convea centralizaba todo y dejaba que la IA respondiese preguntas en vez de obligar a la gente a rebuscar entre gráficos. Funcionaba. Lo construimos. Pero no conseguimos venderlo. El proyecto cerró a los ocho meses.

Mi rol

Llevé la arquitectura de datos de punta a punta. Diseñar cómo fluían los datos desde más de 50 fuentes hasta ClickHouse, construir los modelos de DBT que convertían eventos en bruto en métricas de negocio, y crear la capa semántica que hacía útil a la IA en vez de dejarla soltar respuestas equivocadas con total seguridad.

Como el equipo era pequeño, también me encargué de infraestructura, monitorización y algún arreglo puntual de frontend cuando algo petaba. La mayor parte de mi tiempo se fue en la capa de modelado. Clavar las abstracciones ahí marcaba la diferencia entre una IA capaz de responder de verdad y una que alucinaba tonterías con pinta de plausibles.

Ingesta

Montamos conectores nativos para Shopify, Klaviyo, Google Ads, Meta Ads, TikTok y un par de cientos de plataformas más. Cada una es un mundo. Webhooks por aquí, pulls en batch por allá. Rate limits que varían sin ton ni son. Esquemas que cambian sin avisar. Los conectores gestionaban backfills, syncs incrementales y recuperación automática cuando las APIs fallaban.

El grueso del trabajo ingrato eran edge cases. Fallos parciales a mitad de sync. Eventos duplicados por lógica de reintentos. Inconsistencias de timezone entre plataformas. Migraciones de versión de API que lo revientan todo. Ese tipo de cosas que nunca aparecen en los diagramas de arquitectura pero se comen la mayor parte del tiempo de debugging.

Modelado de datos

ClickHouse ejecutaba las queries analíticas. Ajustamos el particionado por rangos de fechas alineados con cómo los equipos de eCommerce consultan datos en la práctica (cohortes diarias, semanales, mensuales). Sorting keys optimizadas para rollups de series temporales, desgloses por cohorte y ventanas de atribución. Las vistas materializadas pre-computaban los joins costosos para que los dashboards cargasen al instante. Objetivo: p99 por debajo de 200ms. Lo cumplimos.

DBT transformaba los eventos en bruto con modelado dimensional. Tablas de staging para sanear el desorden de cada fuente. Dimensiones para clientes, productos, campañas. Tablas de hechos para pedidos y gasto en ads. Kimball de libro: cada métrica trazable a una única fuente de verdad. Podías pinchar en cualquier número y ver exactamente de dónde salía. Los modelos incrementales mantenían los costes a raya cuando procesábamos más de 100M de eventos al día.

Capa semántica

Aquí es donde la mayoría de plataformas de analytics se caen a pedazos, y la verdad es que le dedicamos más tiempo del que esperaba. "Ingresos" significa algo distinto en Shopify (bruto), Stripe (neto) y cualquier procesador de pagos que uses. Montamos una capa semántica que definía cada métrica una sola vez, con lógica explícita que cualquiera podía leer.

Los modelos de atribución eran configurables: first touch, last touch, lineal, time decay. Las taxonomías de campañas se estandarizaron entre Google, Meta y TikTok para poder compararlas de verdad. La capa también vigilaba la calidad de datos: frescura, anomalías en conteo de filas, schema drift. Si algo pintaba raro, te enterabas antes de que llegase a un dashboard.

Capa de IA

La IA operaba sobre el modelo semántico con contexto del negocio. Historial de campañas, patrones estacionales, benchmarks habituales, experimentos en curso. Cuando alguien preguntaba "por qué bajó el ROAS la semana pasada", el modelo podía investigar de verdad: comprobar si cambió el gasto, ver si una campaña se pausó, detectar picos de CPM o caídas en conversión. Sin ese contexto estructurado de base, lo que tienes es un modelo de lenguaje adivinando con total aplomo.

Las queries en lenguaje natural respondían en menos de 3 segundos. El frontend mostraba también el razonamiento, no solo la respuesta: qué métricas revisó, qué descartó, dónde apareció la anomalía. Los marketers no se fían de las cajas negras, así que lo hicimos explicable.

Lo que construimos

La infraestructura funcionó. p99 por debajo de 200ms en queries analíticas. Más de 50 conectores procesando +100M de eventos diarios. Insights de IA en menos de 3 segundos. Definiciones de métricas en las que Marketing y Finanzas por fin coincidían. Orquestación de pipelines con alertas cuando los SLOs se incumplían. Monitorización de todo el stack.

Teníamos un producto. Simplemente no teníamos suficientes clientes para hacerlo rentable.

Lo que aprendí

Puedes construir algo que funcione y aun así fracasar. Resolvimos un problema real, pero eso no basta. Necesitas compradores con dolor urgente, que puedan firmar un cheque y a quienes puedas llegar sin quemar tu runway. Teníamos lo primero.

En analytics, la consistencia pesa más que la velocidad. Hacer queries rápidas es lo fácil. Que "ingresos" signifique lo mismo en Shopify, Stripe y tu procesador de pagos, eso sí es difícil. Dedicamos más tiempo a la capa semántica que a afinar ClickHouse.

La IA sin estructura no sirve de nada. Apunta un modelo de lenguaje a datos en bruto y se inventa cosas. La capa semántica era lo que lo hacía funcionar: el modelo sabía qué métricas existían, qué valores eran normales, qué contexto importaba. Lo de basura entra, basura sale aplica igual a los LLMs.

Incremental o muerte. Los full refreshes dejan de funcionar a partir de cierta escala. Cada modelo, cada materialización, cada sync tenía que ser incremental; de lo contrario, todo el presupuesto de cómputo se iba en pelear contra el volumen de datos en vez de añadir features.

Este no salió adelante. Ocho meses construyendo infraestructura real, descubriendo qué hace que analytics sea realmente útil, aprendiendo por qué la distribución importa tanto como el producto. Prefiero lanzar algo que falle a no lanzar nada.