Date Ranges and Retention

One date picker governs every analytics surface in Leed: the Know dashboard, the Page Analytics panel in the editor, and the analytics section on a video or audio asset. Wherever you see a range, it is the same control with the same presets and the same rules.

Two independent limits govern what you can ask for. One is about width — how much time a single query may cover. The other is about reach — how far into the past your plan lets you look. They are enforced in different places, they fail differently, and confusing them is the most common source of “my analytics are broken” reports.

The presets

Fourteen presets sit in a two-column grid at the top of the picker, plus a calendar for a custom range. Previous 30 days is the default and the one you get on a first visit.

The Range checkbox under the grid switches between a range and a single day. Unchecked, the calendar selects one day and the picker collapses the range onto it; checked, you pick a start and an end. Choosing a single-day preset unchecks it for you.

In the calendar, once you have chosen a start date, any day more than 365 days away from it is grayed out — so a custom range physically cannot exceed the span cap. Pick an end date beyond it anyway (by selecting a fresh start first) and the end is pulled back to the cap rather than rejected.

The 365-day rule

Any single analytics query is capped at 365 days, on every plan — including Enterprise, whose retention is unlimited.

This is a query-span guard, not a plan limit. It exists because the analytics queries scan raw event rows, and it applies identically whatever you pay.

This is also why an unlimited-retention workspace sees the picker footer read Max 365 days rather than a number: there is no retention figure to print, and the span cap is the only limit left.

The 365-day cap sits with the other product-wide guards in limits that are not plan limits.

How far back your plan reaches

Retention is a quota, and it is the second of the two limits.

The figures above are the tier defaults. The value stored on your workspace record is what actually applies, so a negotiated Enterprise or Growth workspace can carry a number that appears in none of these rows. The picker reads that stored value, so its footer is always the truth for your workspace.

Analytics history is one of exactly three quotas in Leed, alongside contacts and marketing email volume — all three are set out in usage and limits.

What the picker does at the edge

The picker mirrors the server’s rules so you meet them before a request goes out rather than after.

Presets whose range would start before your cutoff render locked, with a padlock icon, grayed text, and the tooltip “Not available on your plan — upgrade for longer analytics history”. The test is on the preset’s start date alone, so which presets lock depends on today’s date as well as on your plan: on Free, Previous 90 days and Previous 365 days are always locked, while Year to date, Last quarter and Last month lock or unlock as the calendar moves.

Clicking a locked preset does not select it. It opens an upgrade panel inside the popover, headed “Longer analytics history is available on higher plans”.

Days older than your cutoff are not selectable in the calendar at all, so you cannot construct a fully out-of-window custom range by hand.

Whether the Upgrade plan link is something you can act on yourself depends on the billing override — see billing and developer access.

What the server does at the edge

The picker is convenience; the server is the guarantee. Every analytics endpoint runs the same three checks in the same order, so the API, the assistant and MCP all behave identically.

flowchart TD
  A["Requested start and end"] --> B{"end after start?"}
  B -- "no" --> E400A["400 — end must be after start"]
  B -- "yes" --> C{"span at most 365 days?"}
  C -- "no" --> E400B["400 — Range cannot exceed 365 days"]
  C -- "yes" --> D{"start before the retention cutoff?"}
  D -- "no" --> RUN["Run the query on the range you asked for"]
  D -- "yes" --> F{"end also before the cutoff?"}
  F -- "yes" --> E402["402 — quota_exceeded, feature analyticsRetention"]
  F -- "no" --> CLAMP["Move start up to the cutoff"]
  CLAMP --> CLAMP2["Clamp the prior-period window to the cutoff too"]
  CLAMP2 --> RUN

The three outcomes are genuinely different, and it is worth being able to tell them apart:

• A 400 is a malformed request. Fix the dates.
• A silent clamp returns real data for a narrower window than you asked for. Nothing in the response body tells you it happened; the numbers are smaller than you expected because the earliest part of the range was never queried. This is why the picker locks the presets — so you know before you ask.
• A 402 is your plan. It names the quota, and how far back you tried to reach:

{
  "error": "upgrade_required",
  "reason": "quota_exceeded",
  "feature": "analyticsRetention",
  "currentTier": "free",
  "quota": 30,
  "used": 92
}

quota is your retention in days and used is how many days back the requested start reached — so 92 against a quota of 30 means you asked for something roughly three months old.

The prior-period comparison window is clamped by the same cutoff. That matters: a delta on the Know dashboard can never quietly include data from before your retention window, so the comparison is either honest or narrower than the label suggests — never fabricated.

After a downgrade

The picker repairs a remembered range on read, so a plan change cannot resurrect a view you are no longer entitled to.

• A range that straddles your new cutoff keeps its end date and starts at the cutoff.
• A range that lies entirely before the new cutoff is discarded and the default preset — Previous 30 days — takes its place.

The repair happens the moment the picker mounts, before any query is issued, so you never see a request fail because of a stale stored range.

What the picker remembers

The selected range is stored in session storage, not local storage.

The keys are per surface, which is why Know and the editor panel can sit on different ranges at the same time:

The Range checkbox state and which preset was active are stored alongside the dates, so reopening the popover shows the preset highlighted rather than an equivalent custom range.

Chart granularity

Every chart derives its bucket size from the span of the range, not from a setting. There is no bucket control.

Buckets with no events are zero-filled rather than omitted, so a chart never has a gap in the middle of it — a flat stretch at zero is a real quiet period, not missing data.

The step changes are worth knowing when you compare two ranges: a 14-day window is drawn in daily bars and a 15-day window in weekly ones, so the same traffic can look very different either side of that boundary. If two charts look inexplicably unlike each other, check whether their spans fall on opposite sides of a row in this table.

These bucket sizes decide the shape of every chart on the Know dashboard and in the Page Analytics panel.