Documentation
Coming from another tool
Reading the reports
Count what matters
Machine access
Twenty screens, one menu.
What each screen answers, what every card and every screen can do, and the honesty rules the numbers follow. The map of the panel, front to back.
The menu, in reading order
Twenty screens, grouped by the question they answer and listed here in the order the sidebar lists them. Screens whose module is off are absent, not greyed. See modules. The API's registry holds twenty-six reports; the ones without a screen of their own, hours, window widths, and Google's search terms among them, draw as cards on these twenty.
| Group | Screens | The question |
|---|---|---|
| Overview | one screen | How is the site doing, at a glance, with tiles you arrange yourself |
| Realtime | one screen | Who is on the site right now. No date range, on purpose |
| Behavior | Pages, Events, Traffic patterns, Journeys, Funnels, Web Vitals | What people did once they were here, and what the pages did to them |
| Acquisition | Channels, AI traffic, Campaigns, Referrers | Where they came from. AI assistants are their own channel, classified ahead of search |
| Audience | Geo, Tech | Countries and regions. Browsers, systems, and window widths |
| Commerce | Revenue, Products, Coupons | What it earned. See ecommerce |
| Outcomes | Goals, Forecast | Whether it is working, and where it is heading. Forecast rows are modeled and labeled so |
| Integrity | Bots | What was removed before any human metric was computed, and by which rule |
Four pages walk the screens in depth: Overview and Realtime, Pages and behavior, Acquisition and audience, and Goals, pacing, and bots. The commerce screens live in Ecommerce.
What every card can do
Every box on every screen follows one contract, so learning one screen is learning them all:
- Tiles carry their own history. A stat tile wears a sparkline wherever a real series exists, and contextual evidence where one does not. It never leaves an unexplained blank.
- Tables are tools. Per-row sparkline, sort, and search, and search reaches the whole result rather than the rows currently drawn. Every observed row stays reachable through pagination.
- Click to filter. Select a supported page, local hour, campaign, referring domain, audience value, product, SKU, or coupon to narrow the report. Active filters travel with you across screens.
- One download per screen, from the header. Every dataset on the screen at once, one per card, as CSV, JSON, NDJSON, Markdown, or XML, or Copy for AI, which prefixes the range and context so a pasted answer stands on its own. Cards carry no download of their own. More in sharing and exports.
- One bookmark per screen, beside the download. It saves the screen with its dates, comparison, and filters under a name, as a row in the sidebar everybody on the site can open. More in saved views.
When a screen refuses
A report that cannot answer says why, and offers the one action that fixes it, rather than announcing that something broke:
- The range. More than 366 days in one request, a start after its end, or a date that is not one. The screen says so and offers "Show the default range", which keeps your filters.
- A filter. A dimension the report cannot apply, or a value it does not accept. The screen names it and offers to remove that one filter while keeping the others.
- An exclusion. A rule money cannot apply, described under rules. The screen prints the rule as the Rules screen spells it and offers "Open Rules".
- A module that is off answers 404, and the screen says the report does not exist for this site, with the module named.
Only a failure that is not one of those, a network gone or the service down, reads as an outage with Refresh as the answer.
The honesty rules
Global segments cover country, channel, device, page path, all five UTM fields, referring domain, browser, operating system, city, local hour, product, SKU, and coupon. Each condition uses one exact value, and multiple conditions must all match. The same selection travels in the URL, saved views, report exports, API, and MCP.
Select an hour in Traffic Patterns or Filters to keep events within that local clock hour on each selected day. For example, 11:00 means 11:00 through 11:59 in the site's timezone. Journeys and funnels keep only steps within that hour. Commerce uses the time of each transaction or refund. Imported aggregates and Search Console daily rows cannot answer an hour segment.
Product and SKU mean orders containing that item. If you select both, they must match the same item. Revenue includes the whole selected basket, and Products includes its other items too. These order records cannot identify browser visitors: Channels and Campaigns show the order figures with traffic unavailable, while traffic-only reports explain which filter they cannot apply. Imported aggregates cannot supply a dimension or intersection they did not retain. Forecast and Pacing use their own outcome scope.
A few behaviors look like bugs until you know they are the point:
- A filter that cannot be answered is refused, not ignored. Revenue under a device filter says so, because orders carry no device. A report that silently dropped the filter would show an unfiltered total under a filtered heading.
- Days cut at your site's midnights, in the time zone the Site screen holds, everywhere, the API and share pages included.
- Measured, imported, and modeled never sum. An imported day is labeled with the tool that measured it. A forecast row never joins a counted total.
- Absent is not zero. A missing measurement stays missing rather than being reconstructed from another number, and unlike currencies never enter one sum.
- A rate compares in points. A bounce rate of 38% that was 39.2% reads "-1.2 pp" on every screen, never "-3.1%", because a share of a share is a number nobody can act on.
- Kehai invents no rows. A dimension member that was never observed does not appear, and a zero appears only where the report's own logic creates one.