Page Report

Shows you what a page does for the business: who sees it, how it performs, and the revenue it drives.

Use it when you are deciding which page to write, rewrite or retire — or when someone asks what a blog post is actually worth.

The question it answers: which pages introduce people who go on to pay, and which ones only collect traffic?

Two ways to call it

What you get

p75 means the 75th percentile: three quarters of the measured page loads were at least this good.

Where the numbers come from. Revenue and product events are first-touch attribution — they count people whose first-ever landing was this page, not conversions that happened on it. Traffic and engagement describe what happened on the page itself and follow page_url_scope. Product-event counts are exact unique people over the report's range, not estimates or samples, and they are aggregate only: the report returns no personally identifiable information (PII). The Precision notes at the end of this page give the exact warehouse wording.

Group form — omit page_path

A ranked, sortable scorecard of every page on one host over a date range — traffic, engagement, the revenue each page drove as a first-touch landing or an assisting touch, plus search, click-health and product-event columns. Raw columns, no composite score: you sort by whatever matters.

FullVision ranks rows by ft_revenue_cents desc, then page_views desc. limit (default 20, max 1000) applies AFTER ranking — the search, click-health and event columns are only filled for the rows you get back, which is what keeps the group form cheap.

Two orthogonal split axes — do not add them together

The row carries two independent splits of the same money, and neither is computable from the other:

A page can have 3 new customers of which 2 were first-touch credited and 1 assisted. ft_customers + new_customers is meaningless; pick one axis per question. total_cash_cents is the recency axis's total (new + existing).

is_ad_lp means Google Ads serves this page as an advertiser-configured ad final URL — not a page auto-served by Dynamic Search Ads or Performance Max. lp_path echoes the canonical path that matched, or null when is_ad_lp is false.

Reading the numbers — three traps

• First-touch vs assisted. First-touch credits the page that introduced the person; assisted credits any page the journey touched. They answer different questions and do not sum.
• Assisted overlaps across pages. One journey touching N pages credits all N, so Σ as_* across pages can exceed the workspace total. This is by design.
• ft_signups_per_landing_session_pct mixes date bases — range first-touch signups over range landing sessions, where first-touch is all-time. Treat it as a directional landing-page signal, not a cohort conversion rate.

Single form — supply page_path

The domains an SEO or content agent needs to optimise one page, assembled into one nested-JSON response:

Two page semantics — do not conflate them

• traffic + engagement describe what happened on this page (the page_path column).
• revenue + events are first-touch attribution: they count people whose first-ever landing page was this page — not on-page conversions. The revenue._note field restates this inline. This is the right framing for content ROI ("what did people who discovered us via this post go on to do"), but it is not "money made on this page".

Parameters

2026-08-17 — the page-attribution data and the attributed_page dimension behind this report now include a Non-attributed row. This is the same bucket the channel dimension has always exposed; the two dimensions are now consistent. page_url_scope gained an opt-in all value. Output under marketing or product, and output when the parameter is omitted, is unchanged.

The series array — granularity

granularity is purely additive: rows is unchanged, and omitting it returns exactly the previous response. Each point carries page_views, unique_visitors, sessions, gsc_clicks, gsc_impressions, gsc_ctr_pct, gsc_avg_position and form_submits — contact-bearing, deduplicated form submissions credited to the submitter's first-touch page, the same recipe as /channel-report and /form-report. form_submits is also a row column (the attribution block) and is not journey-modelled: it is the same under every model.

FullVision labels each bucket with its start date (Monday for weekly) and returns them oldest first. The trailing bucket may be partial — compare it against range.to.

Do not add the buckets up to get the range totals. At weekly and monthly resolution unique_visitors is an upper bound rather than an exact count, and FullVision recomputes rate metrics per bucket. Use rows for totals; the Precision notes explain why.

In the single form, metrics are aggregated totals over the range (one number per metric), except events and the per-dimension engagement lists (form_funnel, outbound_clicks, dead_clicks, rage_clicks), which are arrays. Columns that can't be summed over a range (e.g. unique_visitors on engagement views) are omitted rather than returned as blanks.

Use Channel Report for the same two-form analysis by acquisition channel.

Ranking, totals and comparison

Three group-form parameters, each independently opt-in. Omit all three and the response is exactly the one you got before they existed — no totals, no totals_meta, no prior, and the same cursor.

Re-ranking the list — order_by

order_by is a closed enum per report — the legal columns are listed in the order_by dropdown of the API panel above. Omit it and you keep this report's default ranking (ft_revenue_cents desc, then page_views desc), unchanged. order_dir is asc or desc, defaults to desc, and does nothing on its own.

• The re-rank applies to the complete row set, before limit — a page the default ranking buried below the limit surfaces, rather than the same top-20 reshuffled.
• Nulls sort last in both directions. A page with no GSC data is unknown, not worst, and floating it to the top of an ascending sort would bury the rows you asked to see.
• Ties always break on page_path ascending, so the order is total and a cursor walk visits every row exactly once.
• The widened columns (gsc_*, outbound_clicks, dead_clicks, rage_clicks, events) are not sortable here: they are filled only for the rows you get back, so sorting the complete set by one of them would sort by null on every row and silently return the default ranking.

Cursors under a non-default ordering

next_cursor is still echoed back into starting_after verbatim — never construct or parse the value. Under the default ranking it is the bare row identity it has always been. Under any order_by it becomes an opaque token that also carries the ordering, so replaying a cursor under a different order_by / order_dir is a 400 rather than a silent relocation into another ordering. Repeat the original ordering on every page of a walk, or restart from page one.

Whole-set totals — totals

totals=true adds a totals object covering the complete filtered set before limit — the number you would otherwise get by walking every page — plus a totals_meta sidecar. Anything other than true/false is a 400; nothing is coerced.

Rates are recomputed from their bases over the whole set, never summed or averaged across rows. The rate and search columns (bounce_rate_pct, engagement_rate_pct, scroll_*, gsc_*, the three click counts) come from their own whole-set aggregate queries rather than from the returned rows.

totals_meta.upper_bound names the columns whose total overcounts, because per-row values overlap between rows. Render these as approximations, not counts:

totals_meta.omitted names the columns deliberately left out, so their absence reads as a decision rather than a bug:

A fields trim trims totals with it: neither totals nor prior ever describes a column the response itself does not carry, and a whole-set column whose block was dropped joins omitted.

Comparing against a prior window — compare_to

compare_to attaches a prior object to each row, measured over a second window:

• prior: null means the page did not exist in that window. That is a different claim from a prior object of zeros, which means present and measured zero; conflating them reports a brand-new page as flat.
• Prior-only rows are not introduced. A page with traffic then and none now does not appear — the list is still the current window's.
• The prior window differs only in its dates: same workspace, same page_url_scope, same filters, same fields.
• Independent of totals. A nested totals.prior appears only when both are set.
• compare_to roughly doubles the cold-path work. Page Report is the one report that memoizes its ranked set, so a prior window you have already asked for is served from that cache rather than re-queried.

Trimming the response — fields

fields is a comma-separated list of response blocks. Omit it and you get every block — it only ever narrows a response, never widens one, so every existing call keeps its exact shape.

Both forms accept the same seven block names, but they select different keys:

?fields=traffic,vitals               → the group row keeps only those columns
?page_path=…&fields=gsc              → the single form keeps only `gsc`

Rules that bite:

• FullVision resolves the legal set AFTER form selection, not per endpoint. Supplying page_path picks the single form and its block list; omitting it picks the group form and its own. A block that exists on only one form is a 400 on the other, naming the blocks legal there.
• Empty, duplicated, unknown, and * are all 400s — fields=, fields=traffic,traffic, fields=nope, fields=*. A stray comma is a typo, not a request for everything. The error message lists the legal blocks inline.
• Trimming does not guarantee a query saved per block. Sources are shared: on the group form traffic and vitals both ride the engagement query, and attribution needs the traffic query for ft_signups_per_landing_session_pct. The contract is correct trimming — you get exactly the blocks you asked for and nothing else — never one fewer round trip per block dropped. A block never ships a key another block owns, whichever query happened to run: ?page_path=…&fields=traffic returns engagement.form_funnel but not engagement.summary.
• fields selects columns, never which rows exist. ?fields=events returns the same top-20 pages the untrimmed call does, with only the events column on each. The Precision notes say which queries decide that.
• Row identity is never droppable. page_path, host_scope and range survive every trim — a row without its key is unjoinable.
• granularity is independent. The series array is not a block: ?fields=vitals&granularity=daily still returns one.
• fields never lowers the scopes the endpoint requires. ?fields=traffic still needs attribution:read, customer:read, revenue:read, search:read and web:read (customer:read covers form_submits — aggregate counts only, never a lead row).

Segmenting the series — series_by

Supply series_by alongside granularity (group form only) to split the series by one dimension instead of returning scope-level totals. series then holds one point per (bucket × segment), each carrying key — the segment value — so the response can feed a stacked or multi-line chart directly.

Accepted here: page.

granularity=weekly                 → [{ date, <metrics> }, …]
granularity=weekly&series_by=page  → [{ date, key, <metrics> }, …]

Under series_by=page each point carries unique_visitors, new_customers, new_customer_revenue_cents, existing_customers, existing_customer_revenue_cents, total_cash_cents and form_submits, keyed on the attributed (first-touch) page. Submits whose visitor had no prior pageview have no page to segment on and are dropped from the split; the flat series counts them.

Notes that bite:

• A source view that has no breakdown for the requested dimension is dropped from the segmented series, not smeared across every segment — copying a scope-level total onto each segment would read as per-segment data and be wrong. So a segmented series can carry fewer metric keys than the flat one.
• FullVision skips rows whose dimension value is blank: an unnamed series cannot be labelled or filtered by the caller.
• An unrecognised series_by returns an empty series (not an error, and not a silent fallback to the flat series).
• Segment values may contain spaces (search queries, campaign names) — key is the full value.
• rows is unaffected. Do not sum segmented buckets to get range totals; use rows.