From our observation history

When a listing disappears, you still do not know it sold.

A missing row can mean a sale, a withdrawal, broken pagination, temporary blocking, or a parser failure. We store accepted snapshots first and derive events only after checking observation continuity, so the event says exactly what the evidence supports.

How we derive changes

From accepted snapshot to replay-safe event.

01

Accepted snapshot

Source identity · observed time · completeness

02

Versioned comparison

Previous and current observations under one rule set

03

Observed event

Old value · new value · event meaning

04

Safe delivery

Stable event ID · cursor · idempotent replay

01

Keep immutable observations before deriving events

For every accepted collection, we persist the source identity, canonical identity, observed time, comparable fields, and collection completeness. Events are comparisons between two accepted observations under a versioned rule set; we never create them by overwriting the previous row.

That history lets us replay the comparison and distinguish a source edit from a parser correction. It also prevents a newly deployed rule from silently rewriting the meaning of older events.

02

Name only what the observations prove

Our event envelope identifies the affected offer or property, source, previous value, new value, observation time, and rule version. Useful names include first observed, price changed, status changed, material facts changed, removed from source, and reactivated.

Removed means the offer passed a documented absence policy—not that a transaction closed. We first rule out incomplete pagination, source unavailability, acquisition failures, and parser regressions. A broken observation window is its own operational state, never a zero-inventory event.

03

Make every change safe to retry and replay

We give each event a stable ID and make delivery idempotent so a retry cannot apply the same price change twice. Consumers persist a cursor or receipt and can replay a bounded window after interruption without guessing where continuity broke.

Periodic exports carry a snapshot timestamp and completeness marker. Webhook envelopes are signed and duplicates are expected by contract. Exactly-once side effects come from the consumer storing event IDs, not from pretending a network delivery can never repeat.

04

Measure the gaps behind the event feed

We monitor collection gaps, stale records, event lag, duplicate IDs, reactivation spikes, removal spikes, and unexplained identity-cluster churn. These measures expose feeds that look active while their underlying observations are incomplete.

The most useful denominator is expected observation opportunity, not only delivered event count. A quiet market and a broken collector can both produce zero changes; continuity data is what tells them apart.

  • Persist the accepted observations used for every event.
  • Separate source unavailability from listing removal.
  • Reconcile consumer cursors after interruption.
  • Alert on unusual removal, reactivation, and cluster-churn rates.

Event semantics

What each event proves—and what it cannot prove.

EventIt meansIt does not prove
first_observedThe listing entered accepted coverageThe property was newly listed that day
price_changedThe source assertion changedA negotiated or completed transaction
removedThe offer passed the removal policyA sale or permanent withdrawal
reactivatedA removed offer was observed againA new physical property
source_unavailableObservation continuity is brokenZero inventory

Continuity dashboard

The continuity measures behind a trustworthy event feed.

01

Collection gaps

Missing intervals that weaken event confidence

02

Event lag

Time from accepted observation to downstream delivery

03

Duplicate events

Repeated IDs or non-idempotent consumer effects

04

Cluster churn

Unexpected identity movement between observations