CÓMO FUNCIONAN LAS ALERTAS
Cómo una caída de cuotas de la API de Pinnacle se convierte en alerta.
Un precio de Pinnacle cae en la API de cuotas, y una regla decide si te enteras. Umbral porcentual, ventana de tiempo, filtro por deporte, entrega: esto es lo que ocurre entre el movimiento y la alerta que recibe tu aplicación.
Qué cuenta como caída en la API de cuotas de Pinnacle
Una caída es un descenso porcentual dentro de una ventana de tiempo móvil. Dos precios definen cada movimiento: el precio antiguo, al que se negociaba la selección al inicio de la ventana, y el precio nuevo, al que se negocia ahora.
Caída = (antiguo − nuevo) ÷ antiguo × 100. Una victoria local que pasa de 2.10 a 1.95 ha caído un 7,1%. La forma porcentual mantiene la regla honesta en todo el tablero: la misma caída de 0.15 es un 10% en un favorito a 1.50 y solo un 1,4% en un outsider a 11.00. Los ticks absolutos tratarían esos movimientos como iguales; tu regla no debería.
El motor del feed ejecuta esta prueba dentro de su propia ventana de detección y envía cada caída igual o superior a tu umbral min_drop, desde el 1%. La ventana del motor la fija el servicio; una ventana más larga, como las de abajo, es una regla que aplicas sobre las alertas que recibes.
Una ventana propia debería desplazarse, no reiniciarse. No hay velas ni intervalos fijos: con una ventana de diez minutos, cada precio entrante se compara con el precio de diez minutos antes, no con el inicio de la hora.
Elegir umbrales y ventanas
Ejemplo práctico: una regla del 5% en 10 minutos. Una selección se desliza de 2.40 a 2.28 en nueve minutos, lo que da (2.40 − 2.28) ÷ 2.40 = 5,0%, y la alerta se dispara. Reparte el mismo movimiento en 25 minutos y no se dispara nada: la ventana es tan parte de la regla como el porcentaje.
El compromiso es sensibilidad frente a ruido. Umbrales más bajos y ventanas más cortas se disparan con más frecuencia: detectas los movimientos pronto, y también detectas la oscilación de un solo tick en mercados poco líquidos. Umbrales más altos y ventanas más largas muestran menos revalorizaciones, más deliberadas. Ambos son válidos; responden a preguntas distintas.
Un punto de partida práctico es más amplio de lo que sugiere el instinto. Empieza con un 5% en 10 minutos en mercados prepartido, registra cada posible alerta durante una semana y luego ajusta la regla donde el registro muestre ruido. Tu mezcla de deportes decide qué es ruidoso y qué es silencioso.
Filtrar por deporte y fase
Los umbrales por sí solos no bastan, porque los deportes no se mueven igual. Un partido de tenis en juego cambia de precio en cada punto, mientras que un mercado a largo plazo de fútbol se desliza durante días. Filtra antes de que la regla se ejecute: deporte, liga y fase son los primeros cortes habituales, y mantienen el volumen irrelevante lejos de tu lógica de umbrales. El stream no tiene parámetro de deporte, así que ese filtro vive en tu código, sobre el sport o el sport_id de cada alerta. La fase ya viene separada: las caídas en vivo y prepartido llegan en streams distintos.
La fase es lo que más importa. La mayoría de las aplicaciones ejecutan en vivo y prepartido como reglas separadas, con umbrales separados, porque el tamaño y la cadencia de los movimientos difieren mucho entre ambos. Consulta caídas en vivo vs prepartido para ver qué cambia entre los ritmos.
Para ver qué significa un umbral en probabilidad y no en precio, la calculadora de cuotas a la baja en pnclDATA convierte dos precios cualesquiera en el cambio que hizo el mercado.
Qué lleva un evento de alerta
Cada alerta es autosuficiente. Identifica la línea con sport, league, sect (el mercado, como Moneyline), outcome y period, lleva el precio antes y después de la caída como from_price y to_price, añade nvp, el precio justo sin margen tras el movimiento, y marca la hora de la alerta en segundos Unix como alerted. Construye tu clave de deduplicación con id, sect, outcome, period y alerted juntos.
Eso basta para enrutar, deduplicar y mostrar una alerta sin una segunda solicitud. Cuando una decisión necesite el tablero completo, combina el stream con snapshots REST. El formato de los frames, las reconexiones y el parseo se tratan en la guía de configuración SSE.
De la alerta a la acción
La alerta es una entrada, no una señal de apuesta. Dirigirla a una notificación, un disparador de modelo o una pantalla de monitoreo es trabajo de tu código; el trabajo del stream termina al entregar eventos limpios.
Antes de conectar nada, prueba tu regla sobre el papel con movimientos de precio recientes y observa cómo una señal recorre recibir, filtrar, actuar. Cuando la regla se sostenga sobre el papel, el stream de caídas entrega los eventos sobre los que se ejecuta.