Channel Report

Ranks your acquisition channels by the money they actually brought in, next to the traffic they sent.

Use it when you are deciding where the next marketing hour or euro goes, or when someone asks "is SEO working?" and you want an answer with revenue in it.

The question it answers: which channels bring you visitors who become paying customers — and which only bring you visitors?

Two ways to call it

What you get

Where the numbers come from. Attributed customers and cash are the same whichever host you scope to; traffic and sources follow page_url_scope. Product events count the first-touch acquisition population — people acquired via the channel who fired the event, not events fired on the channel. Those 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.

The nine buckets

Organic Search, AI, Organic Social, Paid Search, Paid Social, Email, Direct, Referral, Non-attributed.

Every visit rolls up into exactly one of them. That is what lets you compare channels against each other instead of against a definition that shifts per report.

A paid visit — a paid utm_medium (cpc, ppc, paid, paid_social, display) or an ad click id — beats every other signal, and the network then decides which paid bucket it lands in: Paid Social for Facebook and Instagram, LinkedIn, TikTok, X, Reddit, Pinterest, Snapchat, Threads and Telegram; Paid Search for every other paid visit — Google, Bing, YouTube, display networks. Paid Social is the newest bucket: before it existed, paid social traffic was reported under Paid Search.

Matching is case-insensitive, and FullVision still accepts LLMs as a legacy alias for AI (the label was renamed on 2026-06-08; historical rows still carry it). The traffic view's catch-all Other and empty labels fold into Non-attributed, so the report never emits a bucket outside these nine.

A channel outside this vocabulary returns 404 entity_not_found. That error exists so a typo fails loudly instead of returning an empty report you would read as "this channel earned nothing". A bucket that merely has no rows in the requested range is not an error — it returns an empty report.

Group form — omit channel

Every bucket, ranked by the revenue from first-time payers who arrived through it. A bucket that sent traffic but has no attributed customers — or the reverse — still appears, with zeros on the side it is missing, so the list is complete rather than a silent intersection.

FullVision ranks rows by new_customer_revenue_cents desc, then sessions desc. limit (default 20, max 1000) caps the list — moot at nine buckets.

Single form — supply channel

Parameters

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, new_customers, new_customer_revenue_cents, existing_customers, existing_customer_revenue_cents, total_cash_cents, ft_signups and form_submits — contact-bearing, deduplicated form submissions credited to the visitor's first-touch channel, the same recipe as /page-report and /form-report. form_submits 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.

The last day or two are incomplete, not a collapse. Traffic (unique_visitors, page_views, sessions, in rows and in the flat series) reads a rollup refreshed once a day at about 06:06 UTC. Until that refresh the current day holds only the hours before it, and the previous day is partial too, so every channel drops by the same proportion at once (one live day read 196 visitors against a ~1,300 baseline). The attributed columns refresh on their own schedule, so a recent day can show more customers than visitors.

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.

Use Page Report for the same two-form analysis by landing page.

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.

Re-ranking the buckets — 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 the default ranking (new_customer_revenue_cents desc, then sessions desc), unchanged. order_dir is asc or desc, defaults to desc, and does nothing on its own.

• The re-rank applies to the complete bucket set, before limit — moot at nine buckets, but the rule is the same one every report follows.
• Nulls sort last in both directions. A bucket with no measurement for the column is unknown, not worst.
• Ties always break on channel ascending, so the order is total and repeated calls return the buckets in the same order.

Whole-set totals — totals

totals=true adds a totals object covering the complete filtered set before limit — every bucket, not just the returned ones — 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.

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.

Comparing against a prior window — compare_to

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

• prior: null means the bucket 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 newly-active channel as flat.
• Prior-only rows are not introduced. A bucket active then and silent 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 — every query this report issues runs a second time over the prior window. Only Page Report memoizes its ranked set; this one does not.

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 four block names, but they select different keys:

?fields=attribution                  → group rows keep only the outcome columns
?channel=AI&fields=sources           → the single form keeps only `sources` (+ `unclassified_referrers`)

Rules that bite:

• FullVision resolves the legal set AFTER form selection, not per endpoint. Supplying channel 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. The contract is correct trimming — you get exactly the blocks you asked for and nothing else — never one fewer round trip per block dropped. Here sources and attribution are two filters over the same underlying performance view.
• fields selects columns, never which rows exist. ?fields=events returns the same buckets the untrimmed call does, with only the events column on each. The Precision notes say which query decides that.
• Row identity is never droppable. channel, host_scope and range survive every trim.
• granularity is independent. The series array is not a block: ?fields=attribution&granularity=weekly still returns one.
• fields never lowers the scopes the endpoint requires. ?fields=traffic still needs attribution:read as well as web:read.

rows vs sources — two levels of detail, never summed together

The group form returns both:

• rows — the 8 canonical buckets (Organic Search, AI, …). This is the authoritative bucket total.
• sources — the concrete origins (Google, ChatGPT, LinkedIn, a referrer host…), each tagged with the channel_category bucket it rolls up into.

Sources roll into rows. Summing both double-counts every payer. Use rows for "how much did AI bring", sources for "which AI assistant".

sources respects the same limit as rows and ranks by new_customer_revenue_cents desc, then unique_visitors desc. FullVision folds each source's channel_category through the canonical mapping, so the legacy LLMs label appears as AI and Other/blank as Non-attributed — a source never reports a bucket outside the nine.

With the attribution block, rows[] and sources[] both carry form_submits: contact-bearing, deduplicated form submissions credited to the visitor's first-touch channel (rows[].ft_form_submits is the same value under its historical name). A source that produced leads but no attributed payer in the range still appears in sources, with zero traffic and cash. Sources partition their bucket's form_submits exactly.

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: channel_category — the 9 buckets, the same grain and labels as rows[].channel — and channel — the concrete source (Google Ads, Bing, a referrer host…), the same grain as sources[].channel. channel is not the 9 buckets: the name follows the warehouse's dimension=channel, where channel_category is the roll-up.

Under either split each point carries attributed_visitors: the attribution cohort (people the channel first-touched who converted in range — the measure sources[].unique_visitors reports), not the host-scoped traffic that rows[].unique_visitors and the flat series carry. On one live day the split read 362 for Google Ads while the traffic row read 50 for Paid Search; both are right, they count different people.

Split points also still carry unique_visitors, as a deprecated alias of the same cohort value — it is removed after 2026-11-26. Read attributed_visitors.

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

form_submits is carried under both splits (keyed on the first-touch channel category or channel). Submits whose visitor had no prior pageview have no channel to segment on and are dropped from the split; the flat series counts them. ft_signups is flat-only.

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.