Producto que vendemos hoy + sistema analítico montado + visión SaaS. Mapa técnico denso, sin venta. Para dimensionar contigo lo que se puede vender y cómo escalarlo.
Cinco bloques. Cada uno con su porqué. Al final, las 13 preguntas concretas donde tu criterio nos desbloquea.
Catálogo modular, paquetes combinados y full-service. Pricing real (Zoho Books). Reglas duras: umbral cliente, compromiso mínimo, no descuentos.
Arquitectura end-to-end: tracking → Sheet warehouse → CRM sync → dashboards HTML → CAPI offline → IA. Cómo está montado y por qué.
Datos a plataformas · Calidad de leads · Avisos sobre proceso comercial. Y la línea roja: hasta dónde llegamos y dónde paramos.
Los 8 hitos de arquitectura donde elegimos algo y descartamos otro. Con su trade-off. Donde tú puedes decirnos: ahí la cagasteis.
Roadmap 4 fases del producto-vendible. Y 13 preguntas concretas (arquitectura, producto, pricing, riesgo) donde necesito tu criterio técnico.
Tres escenarios de venta. El cliente elige según madurez y presupuesto. Precios reales (Zoho Books como fuente de verdad). Sin descuentos: si el lead no llega, ajustamos alcance, nunca precio.
780 €/mes por canal (Google · Meta · TikTok · LinkedIn) + 10/8/7/6 % sobre inversión (escalado por volumen). Cada gestión incluye Dashboard Nivel 1 + setup analítica básica + 1 landing por servicio.
Pack Creativo 1.200 € (jornada grabación + 10 vídeos + 30 hooks). Estrategia Proceso Comercial 1.200 €. Implementación PC 1.200 €. Orgánico mensual 1.000–1.800 €.
Nivel 1 incluido en cualquier gestión Ads (template + config cliente). Nivel 2 custom desde 1.500 € pago único (paleta + dominio + funcionalidades exclusivas). Cliente puede tener su propio subdominio.
1h 120 € · Pack 5h 500 € (100 €/h) · Pack 10h 850 € (85 €/h) · Pack 20h 1.500 € (75 €/h). Para auditorías puntuales, formación, consultoría técnica analítica.
Meta Full: 3.000 € setup + 1.500 €/mes + % inversión. Google Full: 2.000 € + 1.200 €/mes. Combo Google + Meta: 4.000 € + 2.500 €/mes. Setup integra estrategia + vídeos / extensiones.
5.000–6.000 € kick-off · 5.000 € mes 2 · 1.500 €/mes + % inversión mes 3 en adelante. Incluye todo lo modular + proceso comercial completo. Para clientes >50 k€/mes facturación.
Tres flujos paralelos que convergen en un único Sheet warehouse por cliente. De ahí salen dashboards y análisis de IA. Stack: N8N self-hosted + Claude Cloud + Google Sheets + HTML/JS custom + VPS Hetzner.
Meta Ads y Google Ads sincronizados al Sheet del cliente. Granularidad día × ad. Diario a las 06:00.
campaign_type para split YouTube/Display/Search. Cada cliente tiene su propio par de workflows duplicado del template.Polling cada 15 min al CRM del cliente con COQL. Recibe records completos de Leads y Deals.
select * from Leads where Modified_Time > NOW() - 30min. Si añaden un campo en el CRM mañana, llega solo. Sustituyó al patrón viejo de webhook con Form-Data (que requería enumerar 23+ campos a mano por cliente). Latencia 15 min — aceptable salvo para WhatsApp inmediato, que sigue siendo webhook.El Sheet es el warehouse. Encima, 3 webhooks N8N sirven JSON bruto al dashboard HTML y a la capa de análisis con Claude.
/api-leads, /api-meta, /api-google. Filtros por cliente + rango de fechas. Decisión clave: las métricas calculadas (CPL, CPA, ROAS, ROI, hook_rate, etc.) viven en metrics.js y blends.js del browser, NO en N8N. Menos workflows que mantener, cache navegador, cambiar una fórmula no toca infra.Aquí está el valor del producto. Cada capa resuelve una pregunta distinta. La frontera entre la capa 3 y "consultoría comercial" es la decisión estratégica más importante que hemos tomado.
Capa 1, 2 y 3 escalan como producto. Capa 4 — "te decimos cómo organizar tu equipo de ventas" — exige consultoría customizada por cliente y rompe el modelo SaaS. Mejor mantenernos como agencia de Ads con CRM inteligente que te avisa que pivotar a consultora comercial. Cuando el cliente pregunta "y qué hago", la respuesta es: "esta es la métrica, esta es la tendencia, decisión tuya." Damos consejo si lo pide, no plan de acción operativo.
tracking.js universalReutilizable cliente a cliente con config. Pixel + GA4 + Clarity + CAPI server-side. Cuatro reglas duras aprendidas en campo — cada una nos costó al menos un incidente para fijarla.
event_id compartidoCada conversión emite un event_id único. Browser lo manda al Pixel; servidor lo manda al CAPI con el mismo ID. Meta deduplica.
event_id es un crypto.randomUUID() generado en el momento del submit. Se persiste en sessionStorage y se envía al backend, que lo incluye en el payload CAPI. Verificación en Events Manager: ratio de match-quality. Objetivo EMQ: A o B. Si está en C → hay un campo PII no normalizado (típicamente phone sin SHA-256 limpio).<head>, nunca lazySi cargas gtag.js con defer o desde un componente React montado tarde, pierdes la primera pageview.
Meta requiere phone hasheado pero solo dígitos. Si dejas espacios, "+34" o paréntesis, el hash no matchea.
phone.replace(/\D/g,'') → SHA-256 → toLowerCase() hex. Lo mismo aplica al CRM: si guardas teléfonos formateados, normalizar antes de mandarlos al CAPI. Las primeras 6-8 semanas con un cliente nuevo, vigilar EMQ semanalmente..trim() defensivo en variables de entornoVercel mete \n literales al final de variables de entorno. El Pixel se rompe en mobile sin tirar error visible en consola.
process.env.NEXT_PUBLIC_* que sirva un ID se trim-ea defensivamente: const PIXEL_ID = process.env.NEXT_PUBLIC_PIXEL_ID?.trim(). Antes de tirar deploy nuevo, verificar con console.log(JSON.stringify(PIXEL_ID)) que no haya escape chars. Regla permanente en CLAUDE.md del workspace.Cambiamos el patrón de sincronización CRM cuando vimos que el setup escalaba mal. Latencia 1s vs 15 min — aceptable porque los flujos que requieren inmediatez (WhatsApp al lead nuevo) siguen siendo webhook.
Workflow Rule en el CRM + Custom Function (Deluge) o Webhook Form-Data enumerando 23+ campos a mano. Cada cliente nuevo = 30+ min de clics en su UI.
2 workflows N8N por cliente (Leads + Deals) con COQL select * from Module where Modified_Time > NOW() - 30min. 1 OAuth Self Client. Setup 5 min duplicando template.
HTTP 204 body vacío cuando no hay registros. Hay que tratar el responseFormat como text + parser SAFE_PARSE con fallback {data:[]}. El template ya lo trae.
Para nosotros como agencia, lead y deal son la misma persona en distintos puntos del funnel. Una sola fila por persona durante toda su vida. Esta decisión simplifica radicalmente el modelo de datos del dashboard.
Cuando un lead se convierte en deal ganado, NO creamos una fila nueva — enriquecemos la existente. Cuando vuelve y compra otra cosa, sumamos al LTV de esa misma fila.
venta, importe_venta, fecha_venta se quedan como están. Los 4 nuevos campos LTV son extra, para gráficos opcionales de recurrencia. No rompen métricas existentes.Cuando llega un Deal del CRM, busca la fila del Lead por 3 vías en orden. Solo si las 3 fallan, crea fila nueva.
lead_id custom (si existe Workflow Rule en el CRM que lo escribe al convertir Lead→Deal) es match directo y 100 % fiable. Email es lowercase + trim. Phone normalizado a últimos 9 dígitos (independiente de prefijo). Para clientes nuevos pedimos Workflow Rule desde día 1.Si Lead.venta == 0 → es primera venta: enrich completo (touchea funnel + LTV). Si Lead.venta == 1 → es upsell: solo LTV, no toca el funnel.
enrich-[client].py que corre cada hora vía cron. Lee Deals modificados, hace cascade matching, decide primera/upsell, escribe en el Sheet. Preserva métricas históricas de campañas — si un cliente vuelve por una campaña distinta, la atribución original no se contamina.Aquí está la mayor parte del valor técnico que vendemos. La mayoría de agencias optimiza Meta contra "leads de formulario". Nosotros mandamos a Meta los estados reales del CRM. Cambio de magnitud, no de % marginal.
Cuando un Lead/Deal cambia de stage en el CRM, un webhook dispara un workflow N8N que manda el evento correspondiente al Conversions API de Meta.
Source_Ad_ID capturado en la creación del lead (vía UTMs). Meta recibe la cadena completa: ad X → lead → cualificación → reunión → compra de Y €. Configurado en eventos custom del Events Manager. Verificable en el "Quality" tab del píxel.Cuando le mandas Purchase a Meta en vez de Lead, el algoritmo deja de buscar gente que rellena formularios y empieza a buscar gente que compra.
Google Ads tiene Enhanced Conversions y Offline Conversion Imports. Funcionalidad equivalente, sistematización aún manual cliente a cliente.
Decisión tomada en abril 2026 después de descartar Looker Studio y Grafana. Cada cliente tiene su dashboard en cliente.aceleratucrm.com. Misma app, configs distintas.
Ambos resuelven el problema de visualización, pero rompen el modelo de producto que queremos vender.
Template compartido + config JSON por cliente. Misma app sirve a todos, el JS detecta el subdominio y carga la config correspondiente.
N8N invoca prompts Claude por SSH al VPS, que leen Sheet + CRM y producen JSON estructurado. Pipeline genérico que se aplica a cualquier flujo analítico recurrente. Aquí está el techo de escalabilidad — una de las preguntas para ti.
Cron N8N → SSH al VPS → bash script → claude -p "<prompt>" → parser JSON entre marcadores → notificar.sh → dashboard interno (SSE).
<<<SUMMARY>>>...<<<END>>> que el parser extrae. Si el modelo no encuentra novedades, devuelve <<<SKIP>>>. notificar.sh hace routing per-empleado per-cliente: lee asignaciones, escribe en el dashboard correcto. El dashboard interno tiene SSE para actualización en vivo.El pipeline soporta cualquier prompt que lea datos + escriba conclusión. No es específico de un caso.
(prompt template, schedule, output destino). La capacidad técnica clave es que la lógica de negocio vive en el prompt, no en el código. Iterar = editar markdown. Esto permite que cualquier flujo nuevo (ej. "analiza el ROI por canal de este cliente cada lunes") sea un fichero de texto + una línea en N8N.A nuestro volumen, plan suscripción Claude Pro ≈ 200 €/mes. Estimación API equivalente: 3-5 k$/mes. Diferencia x15-25.
claude -p falla con error. Solución actual: distribuir cargas en franjas horarias distintas (briefing 6:00, análisis semanal lunes 10:00, etc.). Esto es probablemente lo que más limita la escalabilidad lineal y donde tu opinión técnica es oro puro.Cada una de estas elecciones tiene un coste. Las hicimos con el conocimiento que teníamos. Dime cuáles te parecen erróneas.
Razón: coste predecible (CPX32 ~13 €/mes vs Zapier 200+ € a este volumen) + Code nodes + integración Postgres/SSH. Precio: single-instance, sin HA. Backups diarios.
Razón: velocidad iteración, cliente puede abrir, suficiente <50 k filas, cero coste. Precio: rendimiento. A 10 k filas el dashboard tarda. Migrar en Fase 2.
Razón: setup pasa de 30 min UI a 5 min duplicar workflow. Sin mantener campos. Precio: latencia 15 min. Webhook se mantiene solo para WhatsApp inmediato.
Razón: simplicidad del modelo de datos para dashboards. ROAS coherente sin doble-conteo. Precio: complejidad del script enrichment, encapsulada en 1 Python por cliente.
Razón: control paleta + embebible subdominio + PWA mobile + features exclusivas. Precio: mantener template. 1 cambio = redeploy global.
Razón: menos workflows que mantener, cacheable, cambiar fórmula no toca infra. Precio: rendimiento browser (mitigado con cache 5 min).
Razón: coste fijo ≈ 200 €/mes vs API estimada 3-5 k$/mes. Precio: rate limits del plan, pausas 1-2 h cuando se alcanzan.
Razón: capas 1-3 escalan como producto. Capa 4 ("qué hacer") rompe modelo SaaS y nos pivota a consultora. Precio: renunciamos a un trozo de fee enterprise.
De producto-agencia custom (hoy) a producto vendible standalone (12-24 meses). Cada fase tiene un trigger distinto. Fase 1 ya tiene equipo asignado.
Para que esta sesión no se quede en "qué chulo" y produzca decisiones que pueda accionar la semana que viene.
claude -p por SSH → ¿FastAPI + cola Redis delante? ¿O servicio HTTP propio con worker pool?(1) Recomendación de arquitectura para Fase 1-2 — qué priorizar primero. (2) Validar / refutar los 20 campos del schema universal. (3) Decidir si entras en Fase 1 con Domingo o solo nos das criterio puntual.