Skip to main content

Granularity

Applies toSurface-agnostic

EDITED tracks options daily. When you request weekly (W) or monthly (M) granularity, each option's days are collapsed into one record per period. That record is a summary of the period, not a raw reading — and how each field collapses depends on the field. Reading a weekly value as if it were a daily one is the most common way to misread this data.

How a field collapses to a week or month​

Field typeExamplesHow the period value is chosen
"It happened" flagsdiscounted, has_had_discount, price_increasedOR'd — true if it was true on any day in the period
Change-eventsactionsThe union of every day's change-events across the period
Everything elsein_stock, price_usd, discount_percentage, …The most representative day — the most typical daily value across the period

The important one is the last row: a weekly or monthly price_usd is the most typical day's price, not an average — and not the price on the last day of the period. The same holds for every other non-flag field.

Why it matters​

  • A weekly/monthly price is not an average. Treating it as a mean, a median, or a period-end snapshot will be wrong. It is the most typical daily value in that period.
  • The OR'd flags overstate how long something lasted. At weekly granularity, discounted: true means "discounted on at least one day that week" — not "discounted all week." It's easy to misread a one-day markdown as a sustained state.
  • It compounds with inferred data. Forward-filled (inferred) days still count toward the representative-day choice, so a period value can reflect imputed days, not only freshly observed ones. See the inferred field in the data dictionary.
Checking a window's coverage

Relying on a long weekly or monthly window? get_retailer_coverage — a tool in EDITED MCP — reports how complete and fresh a retailer's data is over a date range, flagging stretches that are thin (low_volume) or lagging (high_staleness). That tells you whether a period rests on freshly observed days or forward-filled ones. It's an MCP tool, but you're welcome to use it to check coverage even when you're querying over REST.

A worked example​

Suppose an option sits at €19.95 for most of a week, then takes a one-day 40% markdown to €11.97 on Black Friday and sells out that day. EDITED's weeks run Sunday–Saturday.

For that week:

  • discounted → true. It was discounted on one day, so the OR'd flag is true for the whole week.
  • price_usd → €19.95. Five of the seven days were at the full €19.95 and two were at the markdown, so the most typical day — and the period's price — is the full price, not the markdown.

So the same weekly record reads discounted: true and a full-price price_usd. That isn't a contradiction — it's the two collapse rules working as designed. If you need the markdown itself, query at daily granularity.

Picking a granularity​

  • Use daily (D) when you need exact day-level prices, stock, or the precise timing of a change.
  • Use weekly (W) or monthly (M) for trends over longer windows, where one representative value per period is what you want — as long as you read it as a summary, not a daily reading.
Daily history window

Daily (D) data is retained for roughly the last two years; weekly (W) and monthly (M) are kept for the full history. For windows older than two years, query at W or M.

  • Data dictionary — every field, with the per-field notes on how it behaves.
  • The data — what EDITED's data covers and how it is structured.