Camino de la señal a la acción

Ruta de la señal a la acción

La «señal» por sí sola no cambia nada. El valor aparece cuando la señal es estandarizada, interpretada, priorizada, convertida en solución y acción, y luego el resultado vuelve al sistema como retroalimentación. A continuación, un transportador práctico y un conjunto mínimo de artefactos para que esta ruta sea rápida, repetible y segura.

1) Señales: fuentes y estándares

Fuentes: eventos de productos, telemetría/lógica, pagos/CUS, indicadores RG/Frod, APM/SLA, feeds externos (FX, registros).
Esquema de eventos (canónico): 'signal _ id', 'type', 'entity _ id', 'ts _ event', 'ts _ ingest', 'severity', 'payload', 'source', 'confidence'.
Requisitos cualitativos: idempotencia ('signal _ id'), tiempo exacto, UTC + local, máscaras PII, versión del circuito.

Anti-patrones: campos «flotantes», formatos de tiempo local, ausencia de 'source '/' versión'.

2) Sense: normalización, dedoup, enriquecimiento

Normalización: referencias únicas, monedas/zonas de tiempo, esquemas de nombres.
Deduplicación: clave '(entity_id, tipo, ventana)' + hash de carga útil; almacene la «razón de la unión».
Enriquecimiento (feature-join): RFM, geo/dispositivo, evaluaciones de riesgo, cohortes, contexto de campañas.
Calidad: filtros de ruido, confianza 'confidence', verificación de invariantes (por ejemplo, 'amount ≥ 0').

3) Validate: «¿Es importante y es nuestro caso?»

Correlación vs causalidad: marque las señales que requieren verificación causal (DiD/experimentos) → no confunda con desencadenantes de incidentes.
Tomas de efectos: conexión con acciones ya activas (para no «penalizar» dos veces).
Políticas de admisibilidad: RLS/CLS, reglas RG/cumplimiento, límites de frecuencia de contacto.
Histéresis: umbral de entrada ≠ salida; «refrigeración» (cool-off) para señales flash.

4) Prioritize: cómo elegir qué hacer primero

[
\textbf{Priority} = \text{Severity}\cdot w_s;+; \text{Propensity}\cdot w_p;+; \text{Value}\cdot w_v; -; \text{Risk}\cdot w_r; -; \text{Cost}\cdot w_c
]

Severity: fuerza de desviación de la norma/umbrales.
Propensity/Probability of success: probabilidad de un resultado exitoso (modelo/uplift).
Valor: efecto económico esperado (LTV uplift, daños prevenidos).
Risk/Costo: quirófanos, RG/cumplimiento, probabilidad de daño al usuario.
SLA: deduplines por tipo de señal (P1/P2...).

Cola de acciones = ordenar por 'Priority', teniendo en cuenta las cuotas y el límite de tasa por tipo de intervención.

5) Decide: cómo tomar una decisión

1. Reglas (policy-as-code): transparente, rápido, casos básicos.

2. Modelos (score-based): probabilidades/rangos + umbral/histéresis.

3. Políticas de adaptación (bandits, RL): formación en línea, personalización.

Árbol de soluciones (tabla de decisión, mini plantilla)

6) Acto: orquestación y ejecución

Canales: en-app, correo electrónico, inserción, SMS, llamada, límites/restricciones, tickets.
Orquestador: entrega garantizada (retry/backoff), idempotencia de las acciones ('action _ id'), transaccionalidad.
Conflictos: prioridades y excepciones recíprocas (por ejemplo, promoción ≠ intervención RG).
Cargas: rate-limit por canal/user/segmento, cola con DLQ.
Auditoría: registro de «señal → solución → acción → resultado» («correlation _ id» de extremo a extremo).

7) Aprender: efecto y retroalimentación

Métricas de acción: coverage, take-rate, éxito (conversión/reducción de riesgo), latency, NPS/quejas.
Evaluación causal: A/B, DiD, control sintético; uplift @ k, Qini/AUUC para orientación.
Configuración automática: actualización de umbrales/políticas; bandidos (ε -greedy/TS) dentro de los guardrails.
Cierre de ciclo: nuevos fichajes/señales de los resultados; archivo de reglas/versiones.

8) Guardrails y seguridad

Calidad de datos: freshness, completeness, PSI de deriva; caída de calidad = «stop-grúa» de automatización.
Operativo: solución de tiempo p95, disponibilidad del orquestador, presupuesto de error (error budget).
Ética/RG/cumplimiento: prohibición de offers agresivos en riesgo, explicación de decisiones, razones transparentes para actuar para el usuario.
Histéresis y cooldown: previenen el parpadeo de las medidas y el «cansancio» del público.

9) Observabilidad y SLO

SLO del transportador: "Signal→Decision p95 ≤ 2 segundos; Decision→Action p95 ≤ 5 segundos; frescura de los datos ≤ 15 minutos".
Dashboards: embudo «signaly→deystviya», mapa de prioridades, guardrails-alertas.
Registros y rastreo: 'trace _ id/correlation _ id', métricas de fallos, retraídas, porcentaje de escalaciones manuales.
Runibuki: escenarios de degradación (drop feed, picos de señales, retardos de canales).

10) Esquemas de datos y contratos (mínimo)

Evento de señal (JSON)

json
{
"signal_id": "sig_...uuid",
"type": "churn_risk",
"entity_id": "user_123",
"ts_event": "2025-10-31T22:15:00Z",
"ts_ingest": "2025-10-31T22:15:05Z",
"severity": 0. 82,
"confidence": 0. 93,
"source": "model:v4",
"payload": {"rfm":"H1","country":"EE","platform":"ios"},
"version": "1. 2"
}

Decisión/acción (tabular)

`action_id`, `correlation_id`, `entity_id`, `policy_version`, `decision` (enum), `channel`, `queued_at`, `sent_at`, `status`, `guardrail_flags[]`.

11) La economía de las decisiones: cuando la acción es rentable

[
\mathbb{E}[EV] = p_{\text{успех}} \cdot \text{Value} - p_{\text{вред}} \cdot \text{Harm} - \text{Cost}
]

Umbral: ejecute la acción si 'EV ≥ 0' y guardrails están normales.
Presupuestos: capas por segmentos/canales, alocación por marginalidad.
Multi-objetivos: cascada - primero seguridad (RG/frod), luego economía, luego UX.

12) Niveles de madurez (matriz)

1. Ad-hoc: reacciones manuales, sin registros.
2. Repeatable: plantillas de reglas, auditoría básica, métricas limitadas.
3. Managed: un solo orquestador, priorización, evaluación A/B.
4. Optimizado: políticas adaptativas, bandidos, rápidos auto-tuning, control causal de extremo a extremo.
5. Autonomia segura: acciones autónomas dentro de guardrails rígidos, verificaciones formales.

13) Patrones de artefactos

A. Pasaporte de señal

Código/versión, definición, fuente, esquema, frescura SLO, reglas de dedup, enriquecimiento, propietarios, calidad (tolerancias), riesgos.

B. Política de pasaporte/reglas

Identificador, condiciones, datos/fichas, acción, histéresis/couldown, guardrails, explicación para el usuario, versión/changelog.

C. Runbook del incidente

Síntoma (alerta), treising, cheque de calidad de datos, desconexión/descenso de auto-nivel, personas de contacto, criterio de «retorno a la zona verde».

14) Lista de verificación antes del lanzamiento del esquema

• Las señales están estandarizadas; hay dedoup y enriquecimiento
• Priorización y colas implementadas; cuotas y rate-limit configurados
• Políticas/umbrales documentados; histéresis y cooldown están activos
• El orquestador de acción es idempotente; auditoría «de extremo a extremo»
• Guardrails y SLO se establecen; alertas y runibooks listos
• La evaluación causal del efecto está configurada (A/B/DiD o bandidos en la caja de arena)
• Dashboards «Signal→Action→Outcome» y métricas de calidad en venta
• El proceso de versionamiento y retroalimentación (learn) está cerrado

Resultado

Un camino fiable «de señal a acción» es la canalización, no un conjunto de scripts: eventos estandarizados → priorización significativa → soluciones guiadas (con reglas/modelos) → orquestación segura de acciones → evaluación causal → bucle automático de aprendizaje. Tal esquema hace que los datos sean operables, que las medidas sean precisas y que el efecto sea medible y reproducible.