Analítica de Ingresos

Reportes de valor de vida del suscriptor (LTV), retención por cohorte, atribución de qué disparó cada conversión pagada, y un job de reconciliación diaria que detecta inconsistencias entre cobros y suscripciones antes de que se conviertan en un problema de facturación.

Disponibilidad: las cuatro capacidades se activan por tenant desde el panel de super admin (checkbox por plan, con posibilidad de override individual por tenant). No están incluidas en todos los planes por defecto — consulta con tu equipo de cuenta si tu plan las incluye.

Valor de Vida del Suscriptor (LTV)

Agrega todos los pagos aprobados de cada suscriptor para calcular cuánto ha generado en total, sin depender de ningún proceso batch aparte — se calcula al vuelo sobre subscription_payments cada vez que se pide el reporte.

Campo	Descripción
`currency`	Moneda predominante entre los pagos aprobados del tenant
`subscriber_count`	Cantidad de suscriptores únicos con al menos un pago aprobado
`total_ltv_cents`	Suma de todos los pagos aprobados, en centavos
`average_ltv_cents`	Promedio de LTV por suscriptor
`median_ltv_cents`	Mediana de LTV — menos sensible a outliers que el promedio
`top_subscribers`	Los 10 suscriptores de mayor LTV (`user_id` + `ltv_cents`)
`distribution`	Histograma de suscriptores agrupados por rango de LTV, listo para graficar

Endpoint

GET https://engine.paywl.io/reports/ltv
Authorization: Bearer $ADMIN_TOKEN

{
  "currency": "COP",
  "subscriber_count": 842,
  "total_ltv_cents": 412300000,
  "average_ltv_cents": 489667,
  "median_ltv_cents": 350000,
  "top_subscribers": [
    { "user_id": "8f2c...", "ltv_cents": 4200000 }
  ],
  "distribution": [
    { "range_label": "0-100", "count": 120 },
    { "range_label": "100-500", "count": 410 },
    { "range_label": "500+", "count": 312 }
  ]
}

Análisis de Cohortes

Agrupa a los suscriptores por el mes de su primera suscripción (si un usuario se ha suscrito varias veces a lo largo del tiempo, cuenta en el mes de la más antigua, no en cada una por separado) y calcula qué porcentaje de cada cohorte seguía siendo suscriptor activo en cada mes posterior — la vista clásica de retención en forma de tabla escalonada.

Cómo se mide "activo" mes a mes: en lugar de depender de un historial de estados (que el esquema no guarda), el reporte usa el rango de cobertura real de cada suscripción (created_at → current_period_end) como proxy: si ese rango cubre un mes calendario dado, el suscriptor cuenta como retenido ese mes. En la práctica equivale al mismo resultado que "tenía una suscripción activa ese mes".

Acotado a los últimos 12 meses de cohortes y 12 meses de retención por cohorte, para que la tabla se mantenga legible.

Endpoint

GET https://engine.paywl.io/reports/cohorts
Authorization: Bearer $ADMIN_TOKEN

{
  "cohorts": [
    {
      "cohort_month": "2026-03",
      "cohort_size": 96,
      "retention": [
        { "month_offset": 0, "retained": 96, "percent": 100 },
        { "month_offset": 1, "retained": 81, "percent": 84.4 },
        { "month_offset": 2, "retained": 74, "percent": 77.1 }
      ]
    }
  ]
}

Atribución de Conversiones (Wompi)

Para cada suscripción pagada vía Wompi, clasifica automáticamente qué la disparó: una campaña de marketing (UTM), una landing externa, un contenido/artículo específico, o compra directa. El edge worker captura UTM y referrer del lado del servidor (sin tocar el script del cliente) la primera vez que llega un visitante con esos parámetros, y los conserva durante todo su recorrido hasta la conversión.

Fuente	Cuándo se asigna
`campaign`	La conversión tiene `utm_campaign` asociado — gana sobre cualquier otra señal, una campaña más reciente reemplaza a una anterior
`external_landing`	Sin UTM, pero llegó por un `referrer` externo (otro dominio)
`content`	Sin UTM ni referrer externo, pero hubo una vista de muro previa del mismo visitante antes de convertir
`direct`	Ninguna de las anteriores

Endpoint

GET https://engine.paywl.io/reports/conversion-by-source
Authorization: Bearer $ADMIN_TOKEN

[
  { "source": "campaign", "conversions": 34, "percentage": 42.5 },
  { "source": "content", "conversions": 22, "percentage": 27.5 },
  { "source": "direct", "conversions": 18, "percentage": 22.5 },
  { "source": "external_landing", "conversions": 6, "percentage": 7.5 }
]

Atribución por contenido, separada: este reporte agrupa por fuente de tráfico. Para saber qué artículo/categoría/autor específico convirtió más, existe además GET /reports/conversion-attribution (last-touch por slug/category/author).

Reconciliación Diaria (Confiabilidad de Datos)

Un job que corre todos los días y revisa el estado real de las suscripciones contra los pagos y facturas registrados, buscando tres tipos de inconsistencia que — sin detección temprana — suelen aparecer semanas después como un reclamo de facturación:

Tipo de inconsistencia	Qué detecta
`duplicate_active_subscription`	El mismo usuario tiene más de una suscripción activa al mismo tiempo
`payment_without_active_subscription`	Existe un pago aprobado cuya suscripción asociada no está activa
`subscription_without_invoice`	Una suscripción facturable no tiene una factura Siigo asociada (solo para tenants con integración Siigo activa)

Solo detección: el job nunca reembolsa, cancela ni modifica nada automáticamente — únicamente registra el hallazgo y notifica a los administradores del tenant. La resolución siempre queda en manos de un humano, revisando el caso desde el dashboard.

Los hallazgos abiertos se pueden consultar desde el dashboard (sección de administración) y quedan registrados con toda la información necesaria para investigarlos: usuario, suscripciones involucradas, monto y referencia del pago cuando aplica.

Gestión vía Dashboard

Las tres vistas viven en la sección Reportes del panel de administración del tenant. LTV y Cohortes se calculan al momento de abrir la página; los hallazgos de reconciliación se acumulan día a día y se pueden marcar como resueltos una vez investigados.