Skip to main content

Analytics

Read analytics for the active product from the terminal. Analytics commands are read-only and require a token or API key with the analytics:read scope.
Analytics commands require --scope <org-slug>/<product-slug>.

Share of voice

tpc analytics sov returns one value for the selected date range. It counts completed runs that mention the product, divides by all completed runs in the same scope and range, and then multiplies by 100. The default range includes today and the preceding 29 calendar days.
--timeseries, --by, --prompt, and --topic return rolling snapshots. In those modes, --from, --to, and --last select snapshot dates. For a product or --by engine request, --granularity day|week|month selects the UTC calendar bucket and --rolling-window 1..30 controls how many buckets are included in each point. They default to day and 30. Adjacent snapshots overlap, so do not sum their mentions or runs values.

Explore: build your own analytics query

tpc analytics explore is the flexible query surface behind the fixed commands above. Pick one metric, group it by at most one value with --by, then scope it with filters and a date window. It calls the POST /api/v1/analytics/explore endpoint, so anything you can do here you can also do from the API or the exploreAnalytics MCP tool.
Date windows default to the last 30 days. Use --last 7d|30d|90d, or --from and --to together to select a range. The flexible explore SoV query retains snapshot semantics: omitting --by returns only the latest available rolling snapshot, while --by date returns one overlapping rolling snapshot per date. --granularity day|week|month selects the UTC bucket and --rolling-window 1..30 controls how many buckets each SOV snapshot contains; they default to day and 30. Custom settings work for product, date, and engine SOV series. SoV mentions and runs from explore are not start-to-end totals, so you must not sum them across dated rows. Use the fixed tpc analytics sov command when you need one accumulated date-range value. The response is a generic table: the API returns column metadata alongside flat rows, so every metric renders the same way. Add --json to get the machine-readable response for scripting:
Filters that do not apply to the chosen metric are rejected with the supported list, so agents and scripts get a correcting error instead of silently wrong data. See tpc analytics explore --help for the full flag reference.