Automating a Price Alert Without Losing Traceability

A useful price alert must let you reconstruct exactly what changed, when, on which source, and under which rule. Keep the product and source identifier, the old and new values, the currency, the tax base, both timestamps, the rule version, and the collection evidence. Trigger the alert on a validated event, not a raw difference. Also distinguish the time declared by the source from the time your system observed it. Finally, log the notification attempt and its outcome. Automation speeds up monitoring; it turns neither stale data nor a misread page into a reliable price.

An alert is a miniature evidence file

The message "price down" is not enough to decide on a purchase. It's missing the reference concerned, the comparison value, the currency, the stock status, the date of the measurement, and the rule that produced the notification. Without these elements, a team can neither confirm the opportunity nor explain afterward why it acted.

The trail must link three distinct objects: the raw observation, the normalized value, and the trigger decision. The first preserves what was received. The second documents the transformations, for example converting text into a number. The third states the rule and its version. If the normalization is corrected later, the original observation lets you replay the check without reinventing the data.

Price and stock freshness remains a separate check. A newly imported price may have been published by the supplier long ago; conversely, a temporarily unavailable source does not prove its last price is wrong. The alert must expose this state instead of hiding it.

The minimum fields to keep

RFC 3339 defines a timestamp representation usable in Internet protocols, with an offset from UTC. OpenTelemetry's log model distinguishes Timestamp, the time the event occurred at the source, from ObservedTimestamp, the time the system observed it. This separation is especially useful when a feed arrives late.

HTTP also provides validators. Last-Modified represents the origin server's estimate of when the representation was last modified; ETag provides an opaque version identifier. They help determine whether a representation has changed, but they prove neither the price's business date nor its contractual validity.

Reproducible triggering procedure

1. Collect without overwriting. Store the useful response and request metadata before any transformation. 2. Identify the offer. Link the measurement to a source, a product, and, if needed, a specific variant. 3. Validate the format. Check that price, currency, tax, and availability are present, or flag missing fields. 4. Normalize explicitly. Keep every rule applied to the raw value and its version. 5. Compare compatible bases. Reject a variation if currency, unit, packaging, or tax base do not match. 6. Check freshness. Add the event time and the observation time; do not invent the former if the source doesn't provide it. 7. Evaluate the rule. Compute the result with a named, versioned rule, then keep its inputs. 8. Emit and log. Record the message, the channel, the result, and the correlation identifier. 9. Plan for replay. Allow an event to be re-evaluated after a rule correction without altering the original evidence. 10. Close the loop. Document the human decision: verified, ignored, expired, or turned into an analysis.

The source health dashboard complements this procedure: it shows whether the collection itself is working. A single alert is not a diagnosis of the whole source.

Fully hypothetical worked example

Assume a fictional product whose normalized price drops from 28.00 to 25.00 in the same currency and on the same excl.-tax base. The illustrative difference is 3.00, or about 10.7% of the old value. These numbers are invented and describe no supplier or recommended threshold.

The hypothetical rule R-7 might require a drop strictly greater than 2.00 and an observation less than a duration chosen by the seller. If both documented conditions are met, the event becomes a notification candidate. If the currency of the new measurement is missing, the variation is flagged as an anomaly rather than notified. If the source states a per-lot price while the old measurement was per unit, the comparison is likewise blocked.

This example shows why the percentage alone is not enough. The log must keep 28.00, 25.00, the formula, R-7, the timestamps, the price bases, and the reason for the decision. The team can then recompute the result and dispute a false alert.

This screenshot is a redacted public view of the stated route. It contains no account data and does not prove the existence of the authenticated feature proposed in this article.

Handling duplicates, delays, and failed notifications

Two identical collections should not produce two independent decisions if they represent the same event. Define an idempotency key from stable, documented identifiers, then keep the prior result. A new notification attempt should not recreate the variation; it should attach to the existing event.

A late-arriving event calls for a different precaution. Sort the history by event time when it is reliable, but keep the observation time to explain the delay. If only the observation time exists, say so. Do not reconstruct an assumed source time.

Finally, a channel failure does not mean the rule failed. Separate the event's state, the decision's state, and each notification's state. This distinction makes retries and audits easier without sending the same information multiple times.

What ArbitragePro+ could automate / what the seller must still verify

The specification:alertes-prix feature is a proposal, not a confirmed feature of the application.

The proposed automation would organize the evidence and distribute the signal. It would guarantee neither stock, nor a stable price, nor final profitability.

Checklist before enabling a rule

• ☐ The source, product, and variant have stable identifiers.
• ☐ The raw value remains available after normalization.
• ☐ Currency, tax, unit, and packaging are comparable.
• ☐ Event time and observation time are distinguished.
• ☐ The rule has a name and a version.
• ☐ HTTP validators are not presented as business dates.
• ☐ Duplicates and retries are idempotent.
• ☐ The notification result is separated from the rule's result.
• ☐ A human validation precedes any order.
• ☐ The export of opportunities with their evidence keeps the useful identifiers.

Official sources

Sources consulted on August 17, 2026:

• IETF — RFC 3339, date and time representation on the Internet
• IETF — RFC 9110, HTTP semantics and validators
• OpenTelemetry — official logs data model

Manage alerts with their evidence

Open the ArbitragePro+ monitoring console