Looker Studio is where agency reporting lives, so your LLM Metrix data meets it there: three BI aggregate endpoints feed a first-party community connector you can deploy in about five minutes. Everything below is also true of any other BI tool that can read JSON or CSV; Looker is just the one we ship a connector for.
What you can chart
| Dataset | Grain | Fields |
|---|---|---|
Daily scan series (/api/v1/agg/scans) |
one row per UTC day | scans, avg score, mention rate %, share of voice % |
Per-prompt aggregates (/api/v1/agg/prompts) |
prompt × window | answers, mentions, mention rate %, avg rank, engines |
Top cited domains (/api/v1/agg/citations) |
cited host | count, engines, own-domain flag |
All three accept from/to (ISO timestamps), an optional project_id, and
format=csv if you would rather pull flat files. Windows longer than 365 days are refused,
not truncated; if a report silently lost its oldest months it would be a wrong number wearing a
right shape.
Each row is derived from data that was already frozen when the scan completed, not recomputed at read time. A day’s score in the daily series is the mean of that day’s completed-scan rollups, so re-running a dashboard next week returns the same numbers this week did. The figures behind each field (how the visibility score composes, where share of voice comes from) are the same ones the dashboard renders, which is why a Studio chart and the corresponding dashboard panel should never disagree.
Honest-null discipline
A null metric means no completed scan carried a value that day. It never means zero. When you build scorecards in Studio, use AVG aggregations on score and rate fields; SUM over nulls-to-zero turns “we did not scan” into “we scored nothing”, which is a different claim.
This matters most on free plans, where scans run weekly: five of seven days in a null-to-zero scorecard would report a brand at roughly 29% of its actual visibility. On daily-cadence paid plans a single missed day is less dramatic but the principle holds: blanks are honest, invented zeros compound.
One report per client
Requests authenticate with a personal access token (Authorization: Bearer llmx_…) from
Settings → API keys. The aggregates read through exactly the allowlist the rest of the v1 API
uses: the key owner’s projects intersected with any project scope on the key.
For agencies this maps directly onto the reporting structure described in solutions for agencies: issue one project-scoped key per retainer client, and that key’s reports can never read another client’s numbers. There is no trust-on-honor step in the middle. Requesting a project outside the key’s scope is a 403, not an empty result set; a 200 with zero rows would be indistinguishable from “never scanned”, so the API refuses instead of guessing.
The connector’s configuration also accepts a custom base URL: leave it blank for llmmetrix.com, or point it at your white-label host so the report itself carries your brand rather than ours.
Refreshes and the shared rate bucket
All v1 reads share one bucket of 120 requests per minute per key. Scheduled refreshes in Studio draw from the same bucket as interactive loads and anything else using that token; a dashboard that auto-refreshes every few minutes across many tabs can crowd out the very refresh that keeps it current. For scheduled delivery of whole reports instead of live dashboards, see the reporting template; for push-style integration into your own systems, the outbound webhook reference covers events we send to you, the inverse of this pull model.
Building the report
With the connector deployed and configured:
- Score trend: daily series, AVG aggregation on score, time-series chart. Add mention rate as a second axis if the story is “visibility and recommendation moving together”.
- Engine coverage: per-prompt dataset grouped by engine, showing where you appear and where you do not yet.
- Citation sources: top cited domains as a table, filtered on the own-domain flag when the question is are they citing us or our competitors? The underlying derivation is covered in citation intelligence.
Studio’s date-range control passes straight through as from/to, so a client asking for
“last quarter” is one control move, not a query rewrite.
Deploying the connector
The connector source lives in our public repository under integrations/looker-studio/
(manifest.json + Connector.js). Follow its README alongside Google’s own
community connector deployment guide;
deployment is a five-minute Apps Script paste job. Configuration is a base URL (blank for
llmmetrix.com, or your white-label host), the token, an optional project id, and a dataset choice.
The full request/response contract is generated into our OpenAPI document (see
/openapi.json) rather than maintained by hand, so what the connector reads and what the spec
says cannot drift.
If charts come back empty
Three causes cover almost every case. The token was minted before your first scan finished, and charts need at least one completed scan per project. The project id filter points at a workspace you are not a member of, which the API answers with empty datasets rather than an error. Or the date range predates your scan history entirely. Widen the range first: it is the usual culprit, and Studio caches field metadata until you refresh the explorer.