Automatizar una alerta de precio sin perder la trazabilidad

Una alerta de precio útil debe permitir reconstruir exactamente qué cambió, cuándo, en qué fuente y según qué regla. Conserva el identificador del producto y de la fuente, el valor anterior y el nuevo, la divisa, la base fiscal, ambas marcas de tiempo, la versión de la regla y la prueba de recogida. Activa la alerta ante un evento validado, no ante una simple diferencia bruta. Distingue también la hora declarada por la fuente de la hora de observación de tu sistema. Por último, registra el intento de notificación y su resultado. La automatización acelera el monitoreo; no convierte un dato caducado ni una página mal interpretada en un precio fiable.

Una alerta es un expediente de prueba en miniatura

El mensaje «precio en bajada» no basta para decidir una compra. Falta la referencia concernida, el valor de comparación, la divisa, el estado del stock, la fecha de la medición y la regla que produjo la notificación. Sin estos elementos, un equipo no puede ni confirmar la oportunidad ni explicar después por qué actuó.

El rastro debe vincular tres objetos distintos: la observación bruta, el valor normalizado y la decisión de activar. El primero conserva lo que se recibió. El segundo documenta las transformaciones, por ejemplo una conversión de un texto a un número. El tercero indica la regla y su versión. Si la normalización se corrige más tarde, la observación original permite repetir el control sin reinventar los datos.

La frescura de los precios y del stock sigue siendo un control aparte. Un precio recién importado puede haber sido publicado hace tiempo por el proveedor; a la inversa, una fuente momentáneamente no disponible no demuestra que su último precio sea falso. La alerta debe exponer este estado en lugar de ocultarlo.

Los campos mínimos que conservar

RFC 3339 define una representación de marca de tiempo utilizable en protocolos de Internet, con desfase respecto a UTC. El modelo de registros de OpenTelemetry distingue el Timestamp, hora en que el evento ocurrió en la fuente, del ObservedTimestamp, hora en que el sistema lo observó. Esta separación es especialmente útil cuando un flujo llega con retraso.

HTTP también prevé validadores. Last-Modified representa la estimación del servidor de origen sobre la fecha de modificación de la representación; ETag proporciona un identificador opaco de versión. Ayudan a saber si una representación ha cambiado, pero no prueban ni la fecha comercial del precio ni su validez contractual.

Procedimiento reproducible de activación

1. Recopilar sin sobrescribir. Almacena la respuesta útil y los metadatos de la solicitud antes de cualquier transformación. 2. Identificar la oferta. Vincula la medición a una fuente, un producto y, si es necesario, una variante precisa. 3. Validar el formato. Verifica que precio, divisa, impuesto y disponibilidad estén presentes o marca los campos faltantes. 4. Normalizar explícitamente. Conserva cada regla aplicada al valor bruto y su versión. 5. Comparar bases compatibles. Rechaza una variación si la divisa, la unidad, el envasado o la base fiscal no coinciden. 6. Controlar la frescura. Añade la hora del evento y la de observación; no inventes la primera si la fuente no la proporciona. 7. Evaluar la regla. Calcula el resultado con una regla nombrada e historizada, y conserva sus entradas. 8. Emitir y registrar. Registra el mensaje, el canal, el resultado y el identificador de correlación. 9. Prever la repetición. Permite reevaluar un evento tras corregir una regla sin modificar la prueba original. 10. Cerrar el ciclo. Documenta la decisión humana: verificado, ignorado, caducado o convertido en análisis.

El panel de salud de las fuentes completa este procedimiento: indica si la recogida en sí funciona. Una alerta aislada no es un diagnóstico de toda la fuente.

Ejemplo numérico totalmente hipotético

Supongamos un producto ficticio cuyo precio normalizado pasa de 28,00 a 25,00 en la misma divisa y sobre la misma base sin impuestos. La diferencia pedagógica es de 3,00, es decir, aproximadamente el 10,7 % del valor anterior. Estas cifras son inventadas y no describen ningún proveedor ni umbral recomendado.

La regla hipotética R-7 podría exigir una bajada estrictamente superior a 2,00 y una observación de una antigüedad inferior a un periodo elegido por el vendedor. Si ambas condiciones documentadas se cumplen, el evento se convierte en candidato a notificación. Si falta la divisa de la nueva medición, la variación se coloca como anomalía en lugar de notificarse. Si la fuente declara un precio por lote mientras que la medición anterior era unitaria, la comparación también se bloquea.

Este ejemplo muestra por qué el porcentaje solo no es suficiente. El registro debe conservar 28,00, 25,00, la fórmula, R-7, las marcas de tiempo, las bases de precio y el motivo de la decisión. El equipo puede entonces recalcular el resultado e impugnar una falsa alerta.

Esta captura es una vista pública depurada de la ruta indicada. No contiene ningún dato de cuenta y no demuestra la existencia de la función autenticada propuesta en este artículo.

Tratar duplicados, retrasos y notificaciones fallidas

Dos recogidas idénticas no deben producir dos decisiones independientes si representan el mismo evento. Define una clave de idempotencia a partir de identificadores estables y documentados, y conserva el resultado anterior. Un nuevo intento de notificación no debe recrear la variación; debe vincularse al evento existente.

Un evento recibido con retraso exige otra precaución. Ordena el historial según la hora del evento cuando sea fiable, pero conserva la hora de observación para explicar la llegada. Si solo existe la hora de observación, dilo. No reconstruyas una hora de fuente supuesta.

Por último, el fallo de un canal no significa que la regla haya fallado. Separa el estado del evento, el estado de la decisión y el estado de cada notificación. Esta distinción facilita las reanudaciones y las auditorías sin enviar varias veces la misma información.

Qué puede automatizar ArbitragePro+ / qué debe verificar el vendedor

La función specification:alertas-precio es una propuesta, no una función confirmada de la aplicación.

La automatización propuesta organizaría las pruebas y la distribución de la señal. No garantizaría ni el stock, ni el mantenimiento del precio, ni la rentabilidad final.

Checklist antes de activar una regla

• ☐ La fuente, el producto y la variante tienen identificadores estables.
• ☐ El valor bruto sigue disponible tras la normalización.
• ☐ Divisa, impuesto, unidad y envasado son comparables.
• ☐ La hora del evento y la hora de observación están diferenciadas.
• ☐ La regla tiene un nombre y una versión.
• ☐ Los validadores HTTP no se presentan como fechas comerciales.
• ☐ Los duplicados y los nuevos intentos son idempotentes.
• ☐ El resultado de la notificación está separado del resultado de la regla.
• ☐ Una validación humana precede a cualquier pedido.
• ☐ La exportación de oportunidades con sus pruebas conserva los identificadores útiles.

Fuentes oficiales

Fuentes consultadas el 17 de agosto de 2026:

• IETF — RFC 3339, representación de fechas y horas en Internet
• IETF — RFC 9110, semántica HTTP y validadores
• OpenTelemetry — modelo oficial de registros

Gestionar las alertas con sus pruebas

Abrir la consola de seguimiento de ArbitragePro+