InsightLeap AI Platform — EXPLAINER

Concepto

InsightLeap AI es una plataforma SaaS B2B de analítica de comportamiento impulsada por IA. Recopila eventos de uso de aplicaciones cliente, los transforma en vectores de características y predice la probabilidad de abandono (churn) de cada usuario en los próximos 30 días. Equipos de Customer Success pueden actuar proactivamente antes de perder un cliente.

---

Arquitectura

┌──────────────────────────────────────────────────────────────┐
│  Client Applications (SaaS tenants)                          │
│  POST /api/v1/events  ──────────────────────────────────┐   │
└─────────────────────────────────────────────────────────│───┘
                                                          │
┌─────────────────────── Spring Boot 4.0.4 ───────────────▼───┐
│                                                              │
│  EventIngestionController  ←─ Virtual Threads (Java 25)     │
│         │                                                    │
│  EventIngestionService  ──→  CustomerService                 │
│         │                         │                          │
│         └────────────────→  PostgreSQL  ←────────────────┐  │
│                                                           │  │
│  PredictionService (@Scheduled, 5 min)                    │  │
│         │                                                 │  │
│         ├─→  BehavioralEventRepository  (aggregate feats) │  │
│         │                                                 │  │
│         ├─→  MlPredictionClient (Feign)                   │  │
│         │       └─→  Python ML Micro-service :8090        │  │
│         │           (fallback: rule-based scorer)         │  │
│         │                                                 │  │
│         └─→  PredictionScoreRepository  ──────────────────┘  │
│                                                              │
│  AlertService (@Scheduled, 10 min)                           │
│         └─→  log simulated email (wire SMTP/SendGrid)        │
│                                                              │
│  SecurityConfig  ←─ JWT (JJWT 0.12.6, HS256)               │
└──────────────────────────────────────────────────────────────┘

Capas

Capa	Paquete	Responsabilidad
Controller	controller/	REST endpoints, validación de entrada
Service	service/	Lógica de negocio, integración ML, alertas
Repository	repository/	JPA/PostgreSQL, queries optimizadas
Client	client/	Feign → servicio Python externo
Model	model/	Entidades JPA + enums de dominio
DTO	dto/	Records inmutables para API
Config	config/	Security, Feign, Scheduling, Virtual Threads

---

Endpoints

Autenticación

Método	Path	Descripción
%%INLINE7%%	%%INLINE8%%	Obtiene JWT Bearer token

Body:

{ "username": "admin", "password": "admin123" }

Response:

{ "accessToken": "eyJ...", "tokenType": "Bearer", "expiresIn": 86400 }

Credenciales MVP: %%INLINE9%% (ADMIN), %%INLINE10%% (USER).

---

Ingesta de Eventos

Todos los endpoints requieren Authorization: Bearer <token>.

Método	Path	Descripción
%%INLINE12%%	%%INLINE13%%	Ingesta un evento individual
%%INLINE14%%	%%INLINE15%%	Ingesta hasta 500 eventos

Body (single):

{
  "customerId": "usr_123",
  "customerEmail": "alice@acme.com",
  "customerName": "Alice Smith",
  "company": "Acme Corp",
  "tier": "enterprise",
  "eventType": "FEATURE_USED",
  "sessionId": "sess_abc",
  "source": "web",
  "occurredAt": "2026-05-15T10:30:00Z",
  "properties": { "featureName": "export", "fileFormat": "csv" }
}

Response 202:

{
  "eventId": "3fa85f64-5717-4562-b3fc-2c963f66afa6",
  "customerId": "usr_123",
  "status": "ACCEPTED",
  "processedAt": "2026-05-15T10:30:01Z"
}

Tipos de evento disponibles: %%INLINE16%%, %%INLINE17%%, %%INLINE18%%, %%INLINE19%%, %%INLINE20%%, %%INLINE21%%, EXPORT, %%INLINE23%%, %%INLINE24%%, %%INLINE25%%, %%INLINE26%%, %%INLINE27%%, %%INLINE28%%, %%INLINE29%%, %%INLINE30%%, %%INLINE31%%, %%INLINE32%%, CUSTOM

---

Predicciones de Churn

Método	Path	Descripción
%%INLINE34%%	%%INLINE35%%	Lista paginada de predicciones
%%INLINE36%%	%%INLINE37%%	Clientes pro/enterprise en riesgo

Query params /predictions/churn:

• page (default 0)
• size (default 20, max 100)
• %%INLINE41%% = %%INLINE42%% \| %%INLINE43%% \| %%INLINE44%% \| CRITICAL
• minScore = float 0.0–1.0

Response:

{
  "content": [
    {
      "customerId": "...",
      "externalId": "usr_123",
      "email": "alice@acme.com",
      "company": "Acme Corp",
      "tier": "enterprise",
      "churnScore": 0.82,
      "riskLevel": "CRITICAL",
      "confidence": 0.91,
      "riskFactors": ["No activity in last 22 days", "2 payment failures"],
      "computedAt": "2026-05-15T10:00:00Z"
    }
  ],
  "totalElements": 42,
  "totalPages": 3
}

---

Segmentos Dinámicos

Método	Path	Descripción
%%INLINE47%%	%%INLINE48%%	Lista todos los segmentos con conteos
%%INLINE49%%	%%INLINE50%%	Clientes en un segmento específico

Segmentos predefinidos:

segmentId	Criterio
critical-churn-risk	churnScore ≥ 0.80
high-churn-risk	churnScore 0.60–0.79
medium-churn-risk	churnScore 0.40–0.59
low-churn-risk	churnScore < 0.40
high-value-at-risk	tier=pro/enterprise AND churnScore ≥ 0.60

---

Motor de Predicción

Flujo ML (cada 5 minutos)

1. Recupera todos los clientes de PostgreSQL.
2. Por cada cliente, agrega eventos de los últimos 30 días:

- Total de eventos, tipos únicos, días desde el último evento - Media de eventos/día, tickets de soporte, fallos de pago, logins, uso de features

1. Envía el vector de características al servicio Python vía Feign (POST /predict/churn).
2. Fallback rule-based si el servicio ML no responde:

- Basado en actividad reciente, fallos de pago, tickets de soporte y tier.

1. Upserts PredictionScore con score, nivel de riesgo, confianza y factores.

Niveles de riesgo

RiskLevel	Rango de churnScore
LOW	< 0.40
MEDIUM	0.40–0.59
HIGH	0.60–0.79
CRITICAL	≥ 0.80

---

Sistema de Alertas

• Ejecuta cada 10 minutos (AlertService).
• Busca scores con %%INLINE63%% y %%INLINE64%%.
• Despacha alerta (simulada vía log en MVP — conectar SMTP/SendGrid en producción).
• Marca alertSent = true para evitar duplicados.
• Threshold configurable: insightleap.alerts.churn-threshold (default 0.7).

---

Configuración

# En application.yml (añadir estas claves):
insightleap:
  jwt:
    secret: <base64-encoded-256bit-secret>   # cambiar en producción
    expiration-seconds: 86400                 # 24 horas
  ml:
    service-url: http://ml-service:8090       # URL del micro-servicio Python
  alerts:
    email-enabled: true
    churn-threshold: 0.7

spring:
  datasource:
    url: jdbc:postgresql://localhost:5432/insightleap
    username: insightleap
    password: <password>
  jpa:
    hibernate:
      ddl-auto: update
    show-sql: false

---

Cómo ejecutar

Prerequisitos

• Java 25+
• Maven 3.9+
• PostgreSQL 16+

Pasos

# 1. Crear base de datos
psql -c "CREATE DATABASE insightleap;"

# 2. Configurar datasource (application.yml o variables de entorno)
export SPRING_DATASOURCE_URL=jdbc:postgresql://localhost:5432/insightleap
export SPRING_DATASOURCE_USERNAME=postgres
export SPRING_DATASOURCE_PASSWORD=postgres
export SPRING_JPA_HIBERNATE_DDL_AUTO=update

# 3. Compilar y arrancar
mvn clean package -DskipTests
java -jar target/insightleap-ai-platform-0.0.1-SNAPSHOT.jar

# 4. Obtener token JWT
curl -X POST http://localhost:8080/api/v1/auth/token \
  -H "Content-Type: application/json" \
  -d '{"username":"admin","password":"admin123"}'

# 5. Ingestar un evento
curl -X POST http://localhost:8080/api/v1/events \
  -H "Authorization: Bearer <token>" \
  -H "Content-Type: application/json" \
  -d '{
    "customerId": "usr_001",
    "customerEmail": "bob@startup.io",
    "tier": "pro",
    "eventType": "LOGIN",
    "occurredAt": "2026-05-15T09:00:00Z"
  }'

# 6. Consultar predicciones de churn
curl http://localhost:8080/api/v1/predictions/churn?riskLevel=HIGH \
  -H "Authorization: Bearer <token>"

# 7. Ver segmentos
curl http://localhost:8080/api/v1/segments \
  -H "Authorization: Bearer <token>"

---

Análisis de Negocio

Problema resuelto

Las empresas pierden clientes porque reaccionan después del churn. InsightLeap detecta la señal 30 días antes, cuando aún hay tiempo para intervenir.

Propuesta de valor cuantificada

• Reducir el churn del 5% al 4% en una base de 10k clientes a $500/mes = +$60k ARR.
• Tiempo de detección: de semanas a minutos (predicción batch cada 5 min).

Modelo de monetización (tiered SaaS)

Plan	MAUs incluidos	Precio/mes
Starter	hasta 1.000	$99
Growth	hasta 10.000	$499
Enterprise	ilimitado	custom

Go-to-market

• Target inicial: SaaS B2B con 500–50k usuarios activos.
• Canal: integración SDK en 1 línea → tiempo de valor < 24h.
• Expansion revenue: upsell predicción de upgrade + recommendation engine.

---

Referencias

• Top SaaS Trends 2026 — InfoLoop
• Spring Boot 4 Reference
• Spring Cloud OpenFeign 4.2.x
• JJWT 0.12.x Guide
• Java 25 Virtual Threads

---

FinOps Analysis para InsightLeap AI

Resumen de Costos y Rentabilidad

InsightLeap AI, en su fase de MVP, demuestra una estructura de costos operativa muy lean, lo que permite un margen de beneficio saludable incluso con una base de clientes inicial modesta. Los costos principales se dividen entre la infraestructura cloud para la aplicación Spring Boot y el microservicio de ML en Python, la base de datos PostgreSQL y el consumo de tokens de LLM para funcionalidades de interpretación o generación de insights.

• Ingresos Mensuales Estimados: $500 (basado en 5 clientes pagando $100/mes por el nivel inicial).
• Costos Operativos Mensuales Estimados: $75

* LLM (OpenAI gpt-4o-mini): $15/mes (para ~500K tokens, considerando un uso para la generación de resúmenes de alertas, insights de segmentos o interpretación de datos). * Infraestructura Cloud (AWS): $60/mes * Compute (Spring Boot): $20/mes (Ej. AWS EC2 t3.small, incluyendo networking y logs básicos). * Base de Datos (PostgreSQL): $20/mes (Ej. AWS RDS t3.micro, con 20GB de almacenamiento). * Compute (Microservicio ML Python): $20/mes (Ej. AWS EC2 t3.small para el servicio de predicción).

Margen de Beneficio Estimado: 85% (($500 - $75) / $500) 100

Estrategias de Optimización de Costos (FinOps)

Para mantener y mejorar este margen a medida que InsightLeap AI escala, se recomiendan las siguientes estrategias FinOps:

1. Optimización del Consumo de LLM:

* Caching Inteligente: Implementar un sistema de caché para las respuestas de LLM a consultas o resúmenes frecuentes. Si un segmento de usuarios o una interpretación de riesgo se solicita múltiples veces, la respuesta generada por el LLM puede ser almacenada y reutilizada. * Prompt Engineering Avanzado: Refinar continuamente los prompts para ser lo más concisos y eficientes posible, minimizando el número de tokens de entrada y salida sin comprometer la calidad de la respuesta. * Selección de Modelo Dinámica: Evaluar si tareas menos críticas pueden ser manejadas por modelos de LLM más económicos (ej. gpt-3.5-turbo o modelos open-source auto-alojados si la calidad es suficiente).

1. Eficiencia de Infraestructura Cloud:

* Instancias Spot para ML: Para el microservicio de ML en Python, que probablemente ejecuta tareas programadas de predicción, explorar el uso de AWS Spot Instances. Estas ofrecen ahorros significativos (hasta 70-90%) a cambio de tolerancia a interrupciones, ideal para cargas de trabajo batch que pueden reiniciarse. * Consolidación de Recursos: Si el uso de CPU y RAM de las instancias EC2 para Spring Boot y el servicio de ML es consistentemente bajo, considerar consolidar ambos en una única instancia ligeramente más potente (ej. un t3.medium). Esto puede reducir la sobrecarga de gestión y los costos base asociados a tener dos instancias separadas. * Serverless para Cargas Irregulares: Evaluar la migración del microservicio de ML (o incluso la API de ingesta de eventos de Spring Boot si la latencia de 'cold start' es aceptable) a plataformas serverless como AWS Lambda o GCP Cloud Run. Esto permite pagar solo por el tiempo de cómputo consumido, escalando automáticamente a cero cuando no hay tráfico. * Monitoreo y Alertas Granulares: Configurar CloudWatch (AWS) o Stackdriver (GCP) con alarmas para identificar recursos subutilizados (ej. CPU < 10% durante largos períodos) y automatizar su apagado o redimensionamiento, especialmente en entornos de desarrollo y staging fuera del horario laboral.

1. Gestión de Base de Datos:

* Optimización de Consultas e Índices: Asegurar que las consultas a PostgreSQL estén bien optimizadas y que los índices adecuados existan. Esto reduce la carga en la base de datos, lo que podría permitir el uso de una instancia RDS más pequeña o reducir los costos de IOPS a medida que crece el volumen de datos. * Ciclo de Vida de Datos: Implementar políticas de retención de datos para eventos históricos que no son necesarios para predicciones a corto plazo, moviéndolos a almacenamiento más económico (ej. S3) o archivándolos, para evitar el crecimiento innecesario del almacenamiento de RDS.