Match reasons: why an alert passed your filters

Marketplace deal alerts are useful only when you can explain why they fired. Crawlbench evaluates each filter dimension when a listing is ingested. When every required check passes, it stores those reasons with the match, so the alert can tell you what cleared the gate instead of asking you to reverse-engineer the search.

That record matters when a listing looks odd at first glance. Maybe the title omits a model year. Maybe the price sits exactly at your cap. Maybe a word you meant to exclude appears in the description but not the title. The match reasons give you a starting point for checking the filter instead of treating the alert as a black box.

A match reason is a receipt, not a score

Crawlbench uses a pass or fail gate. It does not assign a vague confidence number and hope the highest-scoring listings are close enough.

When Crawlbench ingests a listing, it evaluates the listing against the monitor's current filters. Each filter dimension produces a plain-language result. Every required dimension must pass before a match is created. The reasons from that evaluation are then stored with the match.

For a vehicle monitor, the dimensions can include:

• Make and model: Did the listing text contain the selected make and, when constrained, the selected model?
• Price: Was the listing price inside the configured minimum and maximum?
• Year: Was a model year found, and did it sit inside the selected range?
• Recency: Was the Facebook post time inside the monitor's recency window?
• Excluded terms: Did the listing avoid words such as "parts," "wanted," or "down payment" that you told the monitor to reject?

Other categories use dimensions suited to their own filters. The useful part stays the same: the alert carries the checks that admitted it. The features overview shows how that gate fits into the wider monitoring flow.

What each reason can tell you

The make and model reason answers an identity question. If you selected Toyota Camry, the matcher looks for that identity in the listing text. A broad make-only monitor can pass without a model constraint, while a model-specific monitor must find both.

The price reason checks the stored listing price against your bounds. A $9,500 listing passes a $7,000 to $10,000 range. A listing at $10,500 fails. This is a strict gate, not a suggestion to include nearby prices.

The year reason needs a little more judgment. Vehicle sellers often put the year in the title, but not always. If Crawlbench can parse a year, it checks the configured floor and ceiling. If no year can be parsed from the available listing text, the vehicle matcher records that the year bounds could not be applied. That reason tells you why a listing without an obvious year may still reach the queue.

The excluded-terms reason checks the available title and location text for the phrases you configured. A clean pass means none of those terms appeared there. It does not mean Facebook supplied every detail from the seller's description in the first search result. Open the listing before messaging and read the full copy.

Why recency gets a stricter hold

Post time is different from make, price, or a title keyword. If Facebook's search result does not include a usable posted_at value, Crawlbench cannot honestly say that the listing falls inside your recency window.

Instead of substituting the time Crawlbench first saw the listing, the match is held. Crawlbench attempts to enrich the listing with more detail and then evaluates it again if the Facebook post time becomes available. If the time is recovered and falls inside the window, the match can be created with a recency reason. If the time cannot be recovered, the strict recency gate does not create an alert.

This prevents an old listing first seen today from being presented as newly posted today. In the match queue, listings with a known Facebook time can show when they were posted. Elsewhere, a listing may show when it was first seen until more detail arrives, but first seen is not used as a substitute for the recency decision.

Why yesterday's reason does not change after a filter edit

Match reasons describe the evaluation that produced the stored match. They are not a live report that rewrites every time you edit a monitor.

Suppose a listing passed when your maximum price was $12,000. Tomorrow you lower the cap to $10,000. Crawlbench does not run an offline bulk job that rewrites the old alert or changes its original price reason. Historical reasons remain tied to the ingest evaluation that created or last updated that match.

New listings use the new $10,000 cap. Listings seen again are evaluated against the monitor's current filters. If a re-seen listing passes, its stored reasons can reflect that newer evaluation. The key point is that editing a monitor changes future evaluations. It does not retroactively turn the existing queue into a newly calculated report.

That distinction keeps the current record understandable. Its reasons stay tied to the stored evaluation until the listing is re-seen, passes again, and those reasons are updated.

Use reasons to tune the monitor

Reviewing a few alerts usually exposes which rule needs work:

1. If wrong models pass, tighten the model choice or add a precise excluded term.
2. If parts listings pass, add the language those sellers repeatedly use.
3. If prices feel wrong, check whether you set both a floor and a ceiling.
4. If yearless listings create too much review work, treat the missing-year reason as a cue to inspect the seller's full listing before contacting them.
5. If an older listing never creates an alert, remember that recency uses Facebook's post time, not the day Crawlbench happened to discover it.

The goal is not to produce more alerts. It is to make every alert defensible enough that you can decide quickly whether to open Facebook and message the seller yourself.

If you are comparing explainable, Facebook-focused monitoring with a broader multi-platform alert app, read Crawlbench vs Swoopa before choosing your setup.