Antes de comparar los precios de dos casas de apuestas, establece que ambas observaciones describen el mismo mercado y un estado aceptable de ese mercado. Un número decimal mayor es una señal pobre cuando pertenece a una línea distinta, incluye la prórroga o se conservó tras una suspensión.
Este artículo es para desarrolladores que construyen archivos de cuotas, visualizaciones comparativas y alertas de calidad de datos a partir de feeds que están autorizados a usar. El resultado práctico es un contrato de comparación: un registro normalizado, motivos de rechazo explícitos y un pequeño verificador offline. Valida la evidencia que suministras; no establece que una oferta sea ejecutable en este momento.
Define el mercado antes de comparar el número
Considera dos registros ficticios: Más de 2.5 goles a 1.91 y Más de 3.5 goles a 2.05. Tratar el segundo como una mejora compara dos resultados distintos. Ambos números pueden ser válidos mientras la comparación es inválida.
Usa una clave de identidad explícita. Lo siguiente es un modelo interno propuesto, no una afirmación de que todos los proveedores devuelvan estos nombres de campo:
| Campo | Qué establecer | Ejemplo de error que evita |
|---|---|---|
| Espacio de nombres e ID del evento | El mismo evento en un espacio de nombres de proveedor, o una correspondencia revisada entre proveedores | Unir dos partidos solo porque coinciden los nombres de los equipos |
| Periodo | Primera parte, tiempo reglamentario u otro periodo definido | Mezclar un mercado de descanso con un mercado del partido completo |
| Mercado y línea | Proposición y umbral exactos, con una unidad consistente | Mezclar totales de 2.5 y 3.5 |
| Conjunto de selecciones | El mismo conjunto completo de identificadores de resultado | Tratar un resultado ausente como una desaparición de precio |
| Reglas de liquidación | Un grupo de equivalencia revisado para las reglas que afectan al resultado | Mezclar resultados de solo tiempo reglamentario con resultados que incluyen prórroga |
| Fase del evento | Un estado conocido de pre-partido o en vivo | Comparar una instantánea pre-partido conservada con una observación en vivo |
Un indicador de en vivo coincidente no establece que el marcador, el cronómetro o el estado del juego sean iguales. Este ejemplo no valida esos campos; un flujo de trabajo que requiera un estado de juego sincronizado necesita evidencia y puertas adicionales.
Conserva los identificadores del proveedor y de la casa de apuestas junto a esa clave. Dos IDs sin procesar idénticos de espacios de nombres distintos no son una correspondencia entre proveedores. Una etiqueta settlement_rules es tan fiable como la comparación de reglas que hay detrás; copiar la misma etiqueta en ambas filas no puede establecer equivalencia.
Estas distinciones se corresponden con estructuras reales de feeds. La Odds API v4 documenta objetos de casa de apuestas y de mercado, precios de resultados y valores point para resultados de hándicap y totales. Su respuesta de cuotas por evento también incluye marcas de tiempo de actualización a nivel de mercado. Normaliza el endpoint que usas realmente en lugar de copiar una muestra de una operación distinta. The Odds API v4
Reconstruye el estado antes de juzgar la completitud
Una actualización de stream no es necesariamente una instantánea completa. La documentación del Unified Odds Feed de Sportradar indica que un odds_change puede cubrir solo algunos mercados; los mercados omitidos en ese mensaje permanecen sin cambios. Vaciar toda tu caché de mercados con cada mensaje fabricaría precios que desaparecen. Semántica de odds-change de Sportradar
Separa dos tareas:
- Un adaptador del proveedor aplica a una caché las reglas documentadas de instantánea, delta, recuperación y estado.
- Una puerta de comparación evalúa el estado normalizado resultante.
El verificador enlazado más abajo realiza la segunda tarea. Debe recibir una observación normalizada completa. Poner complete_snapshot: true en un delta sin procesar elude precisamente la pregunta que el adaptador debe responder.
Para un ejemplo de totales, exige tanto OVER como UNDER en el conjunto de selecciones normalizado. Un mercado distinto necesita su propia definición de completitud. Conserva los estados explícitos de suspensión, cierre y desconocido; no rellenes un estado ausente con OPEN a menos que el contrato de la fuente establezca realmente ese estado. Algunos protocolos definen valores por defecto, pero un valor por defecto de un protocolo no es una regla para otro.
Cuando se pierde una conexión, conserva la última observación para tu archivo y márcala como no elegible para la comparación actual hasta que el adaptador vuelva a establecer un estado utilizable. La visibilidad histórica y la elegibilidad actual son propiedades separadas.
Mantén la hora de recogida separada de la hora del precio
Registra cuándo recibió tu recolector la observación y qué significa la marca de tiempo de la fuente. Una respuesta HTTP reciente puede contener un precio antiguo, mientras que un precio sin cambios puede seguir siendo válido durante mucho tiempo. Un umbral de antigüedad es una política de admisión, no una prueba de que un precio sea incorrecto.
No reescribas la marca de tiempo de un precio cuando la conexión emita un heartbeat. Betfair distingue los mensajes de heartbeat de los cambios de mercado; su pt del stream es la hora de publicación del mensaje. La actividad de la conexión por sí sola no establece que se haya actualizado cada selección en caché. Betfair Exchange Stream API
Para una tarea de monitorización, define y registra estos límites antes de admitir un par:
- Antigüedad máxima de la fuente en la hora de evaluación declarada.
- Diferencia máxima entre las dos marcas de tiempo de recogida.
- Cómo se gestionan las marcas de tiempo ausentes, ambiguas, futuras o sin zona horaria.
- Qué campo de la fuente respalda la hora normalizada de actualización del precio.
Nuestra política ficticia del fixture usa un límite de antigüedad de 30 segundos y un desfase de recogida de dos segundos. Esos valores hacen reproducible el ejemplo; no son requisitos de las casas de apuestas ni valores por defecto adecuados para todos los feeds en vivo. Una política de producción debe ajustarse a la semántica de marcas de tiempo documentada del feed y al plazo de decisión del lector. Una marca de tiempo de actualización a nivel de mercado debe seguir identificada como evidencia a nivel de mercado; no establece el último cambio de precio de cada resultado.
Evalúa los registros almacenados contra la hora de evaluación histórica prevista al reproducir un archivo. Comparar los partidos de ayer con tu reloj actual responde a una pregunta diferente.
Usa los motivos de rechazo para localizar el problema
Estas son ramas de diagnóstico ilustrativas, no tasas de fallo medidas de casas de apuestas:
| Observación | Decisión de comparación | Qué investigar a continuación |
|---|---|---|
| Mismo contrato, estado abierto completo, precios válidos y marcas de tiempo aceptables | Elegible para esta comparación | Compara las observaciones conservando sus marcas de tiempo |
| Misma etiqueta, línea o reglas de liquidación distintas | Rechaza este emparejamiento | Corrige la correspondencia de mercados |
| Un lado suspendido o cerrado | Retén la comparación actual | Procesa la transición de estado; conserva el historial |
| Resultado ausente en una instantánea supuestamente completa | Retener | Comprueba la completitud y la recuperación del adaptador |
| Hora de precio antigua con hora de recogida reciente | Retener si queda fuera de tu política de antigüedad declarada | Inspecciona la semántica de actualización upstream y el estado de la caché |
| Heartbeat sano pero sin estado de mercado utilizable establecido | Retener | Diagnostica el estado del stream y la recuperación |
| Precio decimal ausente, no finito o de como máximo uno | Rechaza la entrada normalizada | Comprueba el parseo y la conversión de formato de cuotas |
La última rama importa al ingerir varios formatos de cuotas. Convierte usando un adaptador definido y valida la representación decimal resultante; no trates silenciosamente un entero de cuotas americanas como cuotas decimales. La Odds API expone una elección explícita del formato de cuotas. Opciones de formato de la Odds API
Ejecuta la puerta de comparación offline
Guarda el verificador en Python y los casos de entrada ficticios en el mismo directorio y ejecuta:
python3 odds_compare.py fixtures.jsonEl verificador suministrado acepta deliberadamente solo su contrato de fixture: total de goles en tiempo reglamentario a 2.5 con el ID de regla ficticio documentado. Otros mercados requieren una extensión revisada del contrato y de las pruebas, no solo precios de reemplazo. Mantén la procedencia de casa de apuestas/fuente en tu registro de observaciones circundante.
En el fixture local ejecutado, uno de los 14 pares fue elegible y 13 se retuvieron; 21 métodos de prueba se superaron. Son resultados sintéticos del validador, no tasas de éxito o fallo de casas de apuestas.
El archivo de entrada declara una hora de evaluación fija bajo now y la política ilustrativa de antigüedad/desfase, de modo que la reproducción no depende de cuándo lo ejecutes. Cada caso contiene dos registros normalizados candidatos, incluidos registros deliberadamente incompletos o inválidos que deben retenerse. El contrato de ejemplo es total de goles en tiempo reglamentario a 2.5, con selecciones OVER y UNDER y un ID ficticio de regla de liquidación.
El verificador devuelve eligible_for_comparison más los motivos de los pares retenidos. La elegibilidad permite una comparación de datos bajo el contrato suministrado; no dice nada sobre apuestas, rendimientos, liquidez o ejecución. No se exige que los precios sean iguales.
El método y el esquema explican cómo suministrar tus propios registros normalizados. Las pruebas ejercitan comparaciones válidas y evidencia malformada o ambigua. El verificador no realiza peticiones de red y no incluye ningún adaptador de API. Su campo de marca de tiempo, price_updated_at, lo suministra tu adaptador; el verificador no puede demostrar que el campo upstream tenga el significado que le asignaste.
Convierte el contrato en una comprobación operativa
Un contador de éxitos HTTP pertenece a la monitorización del transporte. Mantén un denominador separado para las comparaciones admitidas por la puerta de datos. Registra los pares intentados, los pares admitidos y los motivos de rechazo, incluidas las observaciones que no pudiste normalizar. De lo contrario, un gráfico aparentemente limpio puede estar simplemente ocultando las entradas difíciles.
Guarda con cada decisión la versión de la correspondencia, los identificadores de la fuente, la hora de recogida, las marcas de tiempo de la fuente, el estado y los motivos. Cuando una alerta parezca incorrecta, ese registro te permite distinguir un defecto de correspondencia de mercados de una caché obsoleta o de un fallo de transporte. No reemplaces un estado desconocido con cuotas a cero ni borres la observación válida anterior.
Un proxy puede cambiar la ruta de transporte que usa un recolector autorizado. No puede establecer la equivalencia de mercados, rellenar selecciones ausentes ni demostrar que un precio es actual. Si la evidencia es incompleta, corrige el contrato de datos antes de aumentar el volumen de peticiones. Para el diagnóstico de la capa de red, consulta variables de entorno de proxy y resolución de problemas de tiempo de espera.
Método: esta es una síntesis asistida por IA de la documentación de proveedores enlazada y un ejercicio de validación local explícitamente sintético. No informa de ninguna recopilación real de casas de apuestas, rendimiento de proveedores, resultado de apuestas ni prueba del servicio ipvolt.
Únete a la lista de espera de ipvolt. El acceso al servicio todavía no está abierto. Un correo cuando se abra el acceso. Nada más.