Actualidad de precios y stock: cómo definir un plazo de confianza

Un precio o un stock solo es fiable si sabes cuándo se generó, cuándo se recogió y si la recogida fue completa. Define plazos de confianza separados por proveedor, tipo de campo y uso: compra automática, alerta manual o simple análisis histórico. No existe una duración universal. El stock puede cambiar más rápido que las características del producto, y un precio antiguo puede seguir siendo válido contractualmente. Superado el plazo elegido, no sustituyas el valor por cero: márcalo como «por confirmar» o «caducado», impide las acciones incompatibles con ese nivel de prueba y solicita una observación reciente antes de pedir.

Tres marcas de tiempo en lugar de una vaga «última actualización»

La actualidad se reduce a menudo a la fecha de ejecución del script. Es insuficiente. Una recogida exitosa a las 10 h puede descargar un archivo generado el día anterior, basado a su vez en un sistema comercial actualizado con una cadencia desconocida. Conserva, en la medida de lo posible, tres momentos distintos:

• source_generated_at: fecha declarada por el proveedor para el dato o el archivo;
• observed_at: momento en que tu sistema recibió la respuesta;
• validated_at: momento en que el contenido superó los controles y se volvió utilizable.

Si el primer dato no existe, no lo sustituyas por la hora de descarga. Anota explícitamente source_generated_at=desconocido. Los validadores HTTP ETag y Last-Modified, descritos por la RFC 9110, pueden ayudar a saber si una representación ha cambiado cuando el servidor los proporciona correctamente. Sin embargo, no demuestran por sí solos cuándo se actualizó el precio o el stock de negocio.

Tratar cada familia de datos por separado

Una ficha de producto reúne elementos cuya velocidad de cambio no es la misma. La marca, el título o el GTIN suelen usarse como datos de identidad; el precio, la disponibilidad, el plazo y el descuento son datos de oferta. Una única fecha global oculta estas diferencias.

El estado InStock merece una atención especial. Schema.org lo define como una indicación de que el artículo está en stock, pero esta convención no proporciona ni cantidad ni marca de tiempo. La antigüedad de la observación sigue siendo, por tanto, esencial. La distinción entre stock booleano y cantidad exacta debe conservarse además de la actualidad.

Construir una política de confianza sin inventar un estándar

Empieza por el riesgo de la acción. Una página de búsqueda consultada por una persona puede mostrar un dato antiguo con una advertencia clara. Un pedido lanzado sin verificación exige una prueba más reciente y garantías contractuales más sólidas. Define después un plazo interno para cada combinación fuente × campo × uso, y documenta quién lo aprobó.

He aquí un ejemplo totalmente hipotético destinado a mostrar la estructura, no duraciones recomendadas. Un equipo podría decidir que un stock observado hace menos de dos horas es «reciente» para una alerta, que entre dos y ocho horas está «por confirmar», y que más allá está «caducado». Para un precio contractual mensual, podría aplicar una regla diferente. Estas cifras no proceden de ninguna norma: deben sustituirse por umbrales derivados de tu cadencia observada, tu contrato y tu tolerancia al riesgo.

El procedimiento de calibración es más importante que la cifra inicial:

1. Registrar cada recogida exitosa, incompleta o fallida. 2. Medir los intervalos entre cambios realmente observados, campo por campo. 3. Anotar los pedidos rechazados, las diferencias de precio y las roturas de stock tras la observación. 4. Elegir un umbral inicial prudente y explícito para el uso estudiado. 5. Mostrar la fecha y el estado al usuario, no solo una puntuación. 6. Revisar el umbral a partir de incidencias y nuevas pruebas.

Una política no debe declarar nunca un valor como reciente solo porque el job se ha iniciado. Depende de una respuesta válida, completa y atribuible a la fuente correcta.

Gestionar las recogidas parciales y los silencios

Un archivo más pequeño de lo habitual puede ser una reducción real del catálogo o una exportación interrumpida. Una API puede responder 200 OK devolviendo, aun así, una página vacía por un cursor mal gestionado. La actualidad debe, por tanto, incorporar un control de completitud: volumen esperado en forma de rango observado, número de páginas, presencia de los campos críticos y estabilidad de los identificadores.

Si el control falla, conserva el último valor validado con su antigua marca de tiempo. No asocies la hora del fallo al dato conservado. Registra por separado last_attempt_at, last_success_at y el motivo exacto. Esto es lo que permite diferenciar una fuente silenciosa de un producto realmente agotado.

La elección del formato de feed CSV, XML, API o FTP influye en la estrategia de reanudación, pero no en la regla fundamental: la marca de tiempo de un dato solo avanza cuando una observación pertinente y validada lo justifica.

Presentar la incertidumbre sin una puntuación engañosa

Una puntuación global puede ayudar a priorizar, siempre que siga siendo explicable. Muestra la antigüedad real, la marca de tiempo disponible, el tipo de stock y las últimas incidencias junto a cualquier color. Un indicador verde sin detalle convierte una elección interna en una promesa implícita.

Prefiere tres estados operativos: utilisable_pour_analyse, confirmation_requise y bloque_pour_action. Las reglas que llevan a estos estados deben ser legibles. El score de fiabilidad de un proveedor puede incorporar la actualidad, pero nunca debe borrar un fallo crítico o un campo ausente.

Checklist de actualidad

• ☐ Las fechas de origen, observación y validación están separadas.
• ☐ Precio y stock tienen sus propios estados.
• ☐ La ausencia de marca de tiempo se marca como desconocida.
• ☐ Un ETag no se presenta como fecha de negocio.
• ☐ Los umbrales son internos, aprobados y revisables.
• ☐ La completitud se controla antes de declarar la recogida como exitosa.
• ☐ Un error no refresca el último valor válido.
• ☐ La antigüedad real sigue siendo visible junto a la puntuación.
• ☐ Se solicita una confirmación reciente antes del pedido.
• ☐ Las incidencias alimentan la revisión de la política.

Lo que ArbitragePro+ puede automatizar / lo que el vendedor debe verificar

La especificación propuesta score-fraicheur podría calcular la antigüedad de las observaciones, aplicar umbrales configurados, señalar las recogidas parciales y bloquear el uso de un valor caducado. Debería exponer siempre las marcas de tiempo y la regla que produjo el estado.

El vendedor debe definir los plazos adecuados a su contrato y su riesgo, confirmar precio y disponibilidad antes de comprar, y arbitrar los casos en los que la fuente no ofrece una marca de tiempo de negocio.

Supervisar el estado de las fuentes

Consultar la salud de las fuentes para examinar la información de recogida y las alertas actualmente disponibles.

Fuentes oficiales

• IETF, RFC 9110, «HTTP Semantics», https://www.rfc-editor.org/rfc/rfc9110.html — consultado el 2026-08-17.
• Schema.org, «ItemAvailability», https://schema.org/ItemAvailability — consultado el 2026-08-17.
• Schema.org, «InStock», https://schema.org/InStock — consultado el 2026-08-17.