Metrics Reference

One metric catalog feeds everything: the Know dashboard, the Page Analytics panel in the editor, the Leed Assistant, and any AI client connected over MCP. This page is the definition of record for half of it.

Metrics come in two shapes. A counted metric answers “how many” and returns a single number with a trend behind it — there are six, and they are what this page defines. A list metric answers “which ones, ranked” and returns a table; there are twenty-two of those, and they live in the list metrics reference.

What a counted metric returns

A counted metric returns three things at once, from one request:

• count — the value for the window you asked for.
• previous — the same value for the window of equal length immediately before it. This is what every delta chip in the CMS is computed from.
• line — a time series, bucketed by the span of your range. Empty buckets are filled with zero, so a chart never has a gap.

You can narrow that with the type parameter. type=count returns count and previous and skips the series; type=line returns only the series, with no comparison. Omit it and you get all three, which is what the CMS does.

The bucket size is derived from the range, never chosen: an hour for a day or less, a day up to fourteen days, a week up to ninety, a month beyond that. The prior-period window is the same length as yours, offset back by that length — a seven-day range compares against the previous seven days, not last calendar week.

The six metrics

Keep the query keys in view. They are what the API, the assistant’s tool call and an MCP client all take, and a reader arriving from a tool result is looking for the key, not the label.

Note the mismatch on the last row: the key says PerHour and the display name does not. Neither is a typo, and neither should be normalized to the other. The name is “Distinct Pages Viewed” everywhere a person sees it; the key is distinctPagesViewedPerHourMetric everywhere a machine takes it. The bucket, incidentally, is whatever your range implies — it is only an hour if you asked for a day or less.

Page Views vs Unique Sessions vs Unique Visitors

These three get confused constantly, and the difference is not subtle once stated:

• Page Views counts rows. One reader opening five pages is five.
• Unique Sessions counts distinct session ids. That same reader, in one sitting, is one.
• Unique Visitors counts distinct visitor ids. That reader coming back every week for a month is still one.

Where the ids come from, and what closes a session, is in how Leed tracks visitors.

The three that cannot be scoped to one page

Total Sessions, Average Page Views Per Session and Distinct Pages Viewed have no page-scoped form. Passing a pageId to any of them does not narrow the result — it is accepted and then ignored, and you get the site-wide number back.

That is not an oversight in all three cases. “Average page views per session” is a property of a session, not of a page; “distinct pages viewed” is a measure of how much of your site got seen. But it is a real trap when you are assembling a per-page report by hand, because nothing errors — the number simply is not what you assumed. Only Page Views, Unique Sessions and Unique Visitors answer a per-page question, and those three are exactly the three cards the editor’s Page Analytics panel shows.

Distinct Pages Viewed excludes 404s

The query drops any page view recorded against the 404 page before counting. So this metric measures the size of your real content surface — how many genuine pages got seen in each bucket — and cannot be inflated by a wave of bad links.

It is the metric to watch when you want to know whether readers are exploring or landing on one page and leaving; a flat line well below your page count means most of your site is never reached.

Total Sessions vs Unique Sessions

Both count distinct session ids, and site-wide with no filters they return the same number. The difference is what happens when you narrow:

• Unique Sessions can be scoped to a page. Doing so joins page views for that page, so it answers “how many sessions included this page”.
• Total Sessions cannot. It is always your site-wide session count for the window, bucketed by when each session started.

Reach for Unique Sessions by default — it is the one the Know KPI card and the editor panel both use. Reach for Total Sessions when you specifically want sessions bucketed by start time regardless of any page, for example when charting when your traffic arrives rather than what it read.

Filters that apply to a counted metric

Six parameters narrow a counted metric. All of them apply to the count, the prior-period value and the series together — there is no way to filter one and not the others.

Two behaviors worth knowing before you build a report on these:

• minimumActiveTime does nothing without pageId. Active time is recorded per page, so there is no site-wide form of the filter; it is silently skipped on a site-wide query, and skipped entirely on the three metrics that cannot be page-scoped.
• excludeBounces means single-page sessions, not disengaged ones. See Remove Bounces.

Every one of these has a control in the editor’s Page Analytics panel. Know exposes only the date range.

Querying a metric directly

GET /api/analytics takes a metric and a window, requires the analytics:read privilege, and returns the shape described above.

GET /api/analytics?metric=uniqueVisitorsMetric&start=2026-08-01T00:00:00.000Z&end=2026-08-31T00:00:00.000Z&type=count

{
  "name": "Unique Visitors",
  "count": 1842,
  "previous": 1610
}

Drop type and you also get line, one entry per bucket, zero-filled:

{
  "name": "Unique Visitors",
  "count": 1842,
  "previous": 1610,
  "line": [
    { "timeValue": 1785283200000, "count": 61 },
    { "timeValue": 1785369600000, "count": 0 },
    { "timeValue": 1785456000000, "count": 74 }
  ]
}

Four errors account for almost everything you will hit:

A window that reaches back past your plan’s retention behaves differently again: a range that straddles your cutoff has its start quietly moved forward and returns data, while a range lying entirely before it is refused with a 402. Both are covered under the 365-day rule.

An AI client can list every metric by name and query any of them without you writing a URL at all — see analytics for AI and MCP clients and the MCP analytics tools.