AI Visibility Tracking: compute mention rate and share of voice across every AI engine

Five primary metrics, all aggregated from raw `sources[]` per response: mention rate (fraction of runs that cite your domain), citation position (where you appear in the cited list), share of voice (your citation rate vs competitors on the same prompt set), cross-engine coverage (how many of the 7 engines cite you), and entity recognition (whether engines correctly attribute claims to your brand vs misattribute or omit). All five are computed by your code from the response, so you can match them to whatever methodology your team already reports.

A packaged AI visibility platform gives you a dashboard and stops at its edges; the API gives you the data underneath. Three reasons teams pick the API. (1) Data ownership: citation data lands in your warehouse alongside the rest of your marketing analytics, not behind someone else's login. (2) Custom metrics: most teams already have a share-of-voice methodology their finance team reports, and computing it from raw responses means your AI numbers match your existing numbers. (3) Workflow integration: alerting, BigQuery ETL, dbt models, and Looker dashboards plug in as easily as any other API.

That is the shape most teams deploy it in. There is no UI to adopt and no seat model to negotiate, so the integration surface is a single REST endpoint per engine plus async webhook delivery for scheduled runs. The common pattern is a nightly batch into BigQuery or Snowflake, dbt models computing mention rate and share of voice on your own definitions, and the result joined to GA4, Search Console, and CRM data in whatever BI layer already carries your search reporting. Agencies and multi-brand teams run the same thing with per-tenant API keys, which keeps each client's data separated at the source rather than filtered in the report. Because the metrics are computed by your code from the raw response, the AI-visibility numbers reconcile against the search numbers you already publish instead of arriving as a vendor score nobody can audit.

Yes, because the architecture puts the data where you put it. The API returns each answer as JSON over a REST call; your pipeline writes it into your warehouse, in your region, under your retention policy, and every metric is computed there. There is no hosted analytics layer your compliance team has to audit as a second system of record, no seat-based SaaS holding a copy of your competitive analysis, and agencies isolate client data at the source with per-tenant API keys. For teams with formal residency or retention paperwork, the surface to review is one API integration rather than a vendor's entire dashboard stack.

The API response is the raw JSON export: every answer arrives as structured JSON (`text`, `markdown`, `sources[]` with positions and URLs, plus engine-specific fields), so there is no export step to wait on and no row limit to negotiate. CSV is one flattening step in your own pipeline; most teams write answers straight to BigQuery or Snowflake and let the BI layer export CSV on demand. The practical difference from dashboard exports: you get every field, per answer, at collection time, never the subset a vendor chose to expose on an export screen.

Yes. Prompts are free text in any language, and the country parameter localizes each request, so a German prompt from DE and a Portuguese prompt from BR return the answers users in those markets actually see. Two behaviors to plan for, both documented: some engines generate part of their internal search queries in English regardless of prompt language (ChatGPT shows a roughly 50/50 split), so group captured queries by language before comparing markets, and per-country availability differs by engine, so validate coverage with the countries endpoint before committing a market to a client report.

Daily on prompts that matter (typically 50–200 long-tail informational queries × 2–3 countries × 7 engines), hourly on a smaller crisis-sensitive subset. Engine-specific cadence floors apply: Grok needs hourly (real-time X content), and ChatGPT, Perplexity, and Gemini move on weekly+ scales for most queries. The async endpoints (`POST /v1/monitor/{engine}/async`) deliver via webhook, so high-throughput cross-engine monitoring doesn't burn sync concurrency.

Core fields are consistent across all six monitor endpoints: `text`, `markdown`, `sources` (with `position`, `url`, `label`, `description`), and the `country` parameter. Engine-specific fields ride alongside: `searchQueries` on ChatGPT and Grok, `places`/`shopping_cards` on Perplexity and AI Mode, and `confidence_level` on Gemini sources. One unified parser plus engine-specific accessors covers everything.

One key, one shared credit pool. Per-engine credit counts vary (ChatGPT web search 5, Perplexity 4, Gemini 4, AI Mode 4, Copilot 5, Grok 4) and a Google SERP call with AI Overview enrichment is 5 credits (3 base + 2 AIO). One prompt fanned across all six monitor engines is roughly 26 credits — so the Hobby plan ($100/month, 250k credits) covers ~10k cross-engine monitored prompts per month. Most production programs land on Growth ($500/month, 1.35M credits) when they expand to a full competitor-tracking prompt set.

Yes — for the AI search slice. Online brand monitoring traditionally covers social, news, and review surfaces (handled by established social-listening platforms). cloro covers the AI-search surface specifically: ChatGPT, Perplexity, Gemini, AI Mode, Copilot, and Grok. Most enterprise brand-monitoring stacks now run two pipelines — a social-listening tool for social/news/reviews, plus cloro for AI-engine citations. The two surfaces measure different signals and feed different reports.

Submit per-engine async batches (`POST /v1/monitor/{engine}/async`) and let webhooks fire as results land. For a 100-prompt × daily program this is the right pattern: sync polling across every monitor endpoint burns concurrency you don't need to spend, and async lets the orchestration layer (Airflow, Temporal, plain cron) drive the cadence.