Pruebas A/B, Predicción de Churn y Propensión de Conversión

Tres capacidades de nivel Performance BI / Enterprise: experimentos A/B con un bandit bayesiano real, y dos modelos de machine learning entrenados con tus propios datos — uno para anticipar qué suscriptores están en riesgo de cancelar, y otro (el inverso) para identificar qué usuarios sin convertir todavía tienen alta probabilidad de hacerlo.

Disponibilidad: las tres features se activan por tenant desde el panel de super admin (overrides de plan). No están incluidas en el plan Performance base — consulta con tu equipo de cuenta si tu plan las incluye.

Pruebas A/B — Thompson Sampling

A diferencia de un test A/B clásico que reparte el tráfico 50/50 hasta el final, PayWL usa Thompson Sampling: un bandit bayesiano que mantiene una distribución de probabilidad de conversión por variante y, en cada visita, redirige automáticamente más tráfico hacia la que mejor está funcionando. Menos tráfico "desperdiciado" en la variante perdedora, resultados más rápidos.

1 Una regla de acceso ya decidió mostrar el muro
2 Se resuelve el experimento activo para esa regla
3 Se asigna (o recuerda) la variante del visitante
4 Se aplican los overrides al muro
5 Conversión se atribuye a la variante
Importante: un experimento nunca cambia si el visitante ve el muro o no — eso lo sigue decidiendo la regla de acceso normalmente. El experimento solo cambia qué versión del muro ve, una vez que ya se decidió mostrarlo.

Qué se puede probar por variante

OverrideDescripción
price_centsPrecio mostrado en el muro para esa variante
cta_copyTexto del botón de suscripción
trial_daysDuración del trial ofrecido
wall_htmlReemplaza por completo el HTML del muro para esa variante

Cada variante puede sobreescribir uno, varios, o ninguno de estos valores — lo que se deja vacío hereda el valor por defecto de la regla.

Asignación pegajosa (sticky)

Un mismo visitante siempre ve la misma variante mientras el experimento sigue corriendo — se identifica por usuario autenticado si está logueado, o por su fingerprint anónimo si no. La asignación se guarda desde la primera vista.

Ciclo de vida

  • Borrador: el experimento existe pero no asigna tráfico todavía.
  • Corriendo: asigna variantes en tiempo real y cuenta impresiones/conversiones.
  • Pausado: deja de asignar tráfico nuevo, conserva los datos.
  • Completado: cerrado, listo para analizar el ganador.

Predicción de Churn

Un modelo de regresión logística entrenado con el historial real de cada tenant — no un score calculado con pesos fijos definidos a mano. El modelo aprende de tus propias cancelaciones pasadas qué combinación de señales predice mejor una cancelación futura.

Señales que usa el modelo

SeñalQué mide
Recencia de accesoDías desde la última vez que el suscriptor leyó contenido
Ratio de pagos fallidosProporción de cobros fallidos en los últimos 90 días
Tendencia de lecturaSi la frecuencia de acceso está subiendo o bajando
Reintentos de cobroCuántas veces se ha reintentado el cobro actual

Cadencia de actualización

El modelo se reentrena y recalculan los scores automáticamente el día 1 de cada mes. Además:

  • Recálculo bajo demanda: desde el dashboard se puede forzar un recálculo inmediato sin esperar al ciclo mensual — útil justo después de activar la feature para un tenant.
  • Tiempo real (tenants con cupo ilimitado): si un cobro falla, el score de ese suscriptor específico se recalcula al instante usando el modelo ya entrenado, sin esperar ningún ciclo.

Niveles de riesgo

ScoreNivel
0 – 39Bajo
40 – 69Medio
70 – 100Alto

El reporte de riesgo se puede exportar a CSV directamente desde el dashboard.

Honestidad de datos: con poco volumen histórico de cancelaciones, los primeros scores del modelo van a ser menos confiables. La precisión mejora con el tiempo a medida que se acumulan más cancelaciones reales — no se debe interpretar el score inicial como una predicción definitiva.

Modelo de Propensión de Conversión (Churn Inverso)

El mismo enfoque que la Predicción de Churn, pero al revés: en vez de anticipar qué suscriptor pagado va a cancelar, identifica qué usuario con cuenta que todavía no se suscribió (trial en curso o registro gratuito) tiene alta probabilidad de convertirse en pago — para que puedas targetearlo proactivamente (email, oferta personalizada, etc.). Reusa la misma implementación de regresión logística que el modelo de churn, entrenada por separado con datos propios de conversión.

Señales que usa el modelo

SeñalQué mide
Días desde primera vistaAntigüedad del visitante desde que se le vio por primera vez
SesionesCantidad de sesiones distintas de navegación
Vistas de muroCuántas veces se topó con el paywall
Clicks en el muroCuántas veces interactuó con el CTA del muro
Contenido distinto vistoCantidad de artículos distintos que visitó
Categorías distintas vistasDiversidad de temas que consume
A quién se scorea: solo a usuarios identificables (con cuenta — trial o registro) y con actividad reciente (últimos 90 días) que nunca llegaron a tener una suscripción. Un visitante 100% anónimo no es accionable para el cliente, aunque sí se usa (junto con los identificables) para entrenar el modelo.

Cadencia de actualización

El modelo se reentrena y recalculan los scores automáticamente cada domingo. Igual que en churn, hay recálculo bajo demanda desde el dashboard para no esperar al ciclo semanal justo después de activar la feature.

Requiere conversiones reales para entrenar: si un tenant todavía no tiene ninguna suscripción paga registrada, el modelo simplemente no entrena esa semana (no es un error) — se activa solo en cuanto haya al menos un puñado de conversiones reales de las que aprender.

Gestión vía Dashboard

Las tres features se administran desde el panel de administración del tenant: creación de experimentos con su asistente paso a paso (regla objetivo → variantes → revisión), y las secciones de riesgo de churn y de propensión de conversión dentro de Reportes, con generación explícita del reporte (para no consumir el cupo mensual solo por abrir la página).

Endpoints de administración

Estos endpoints requieren sesión de administrador (token Bearer del login del dashboard), a diferencia del resto de esta documentación que usa X-API-Key para integraciones externas.

EndpointDescripción
POST /experimentsCrea un experimento en estado borrador
PATCH /experiments/:id/startInicia la asignación de tráfico
PATCH /experiments/:id/pausePausa el experimento
GET /reports/churn-riskDevuelve los scores vigentes de riesgo de churn
POST /reports/churn-risk/recomputeFuerza un recálculo inmediato (con cooldown de 10 min)
GET /reports/propensityDevuelve los scores vigentes de propensión de conversión
POST /reports/propensity/recomputeFuerza un recálculo inmediato (con cooldown de 10 min)

Ejemplo: crear un experimento

curl -X POST https://engine.paywl.io/experiments \
  -H "Authorization: Bearer $ADMIN_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{
    "name": "Precio de suscripción — muro metered",
    "target_rule_id": "rule_abc123",
    "variants": [
      { "name": "Control", "is_control": true, "overrides": {} },
      { "name": "Precio alto", "overrides": { "price_cents": 990000, "trial_days": 7 } }
    ]
  }'