Skip to main content

Inferred data & out-of-stock

Applies toSurface-agnostic

EDITED's data is crawl-based — it reflects what EDITED observed on a retailer's site. When an option isn't freshly observed on a given day, EDITED may infer that day's record by carrying the most recent observation forward. This keeps a daily series stable rather than flickering as retailers delist and re-list products. The trade-off is that some values — most importantly in_stock — can be inferred rather than freshly observed, so EDITED flags them and lets you filter them out.

The inferred flag​

An option document that contains inferred data carries an inferred field set to true. Documents that aren't inferred simply don't have the field. That one flag is how you tell a freshly observed record from a carried-forward one.

What it means for reading stock​

in_stock reports whether at least one linked SKU is in stock. On an inferred day, that value is carried forward from the last time EDITED actually saw the option — not a fresh reading. So:

  • A freshly observed in_stock is a real, dated observation.
  • An inferred in_stock is EDITED's best estimate for a day it didn't observe the option directly.

Reading in_stock without checking inferred can therefore overstate how current a stock state is. If freshness matters for your analysis, account for it.

Choosing what you get​

  • Exclude inferred data with the not_inferred: true filter, to restrict a query to freshly observed records. See Filters.
  • Check freshness over a window with MCP's get_retailer_coverage, which flags stretches that are lagging (high_staleness) — a quick way to see whether a period rests on fresh observations or carried-forward ones. It's an MCP tool, but you can use it to sanity-check a window even when you're querying over REST.
  • Data dictionary — the inferred and in_stock field definitions.
  • Filters — the not_inferred filter.
  • Granularity — inferred days also feed into weekly/monthly roll-ups.