White-Label AI Visibility Tracking for Agencies

Agencies got asked about AI visibility by every client at roughly the same time, and the tooling question follows immediately: report it under whose brand, on whose definitions, at what per-client cost? This page is the white-label AI visibility answer, with the architecture and the arithmetic.

Can we white-label AI visibility tracking for our own clients?

Yes. The clean version is API-first: your pipeline collects AI answers per client, your database keeps each client’s data separate, your code computes the metrics, and your existing report or dashboard presents them.

The client sees your brand at every step because there is no third-party UI in the loop to hide.

The pieces, concretely:

1. One API key per client. Per-tenant keys isolate each client’s usage and data at the source, so separation is structural rather than a filter in a report. Client offboarding is key revocation.
2. One prompt set per client. Their category’s buying questions, their competitors as the mention panel. Freeze both inside reporting periods and date every change, or the trend lines lie.
3. Scheduled collection. Daily runs per prompt per engine through the monitor endpoints, async with webhooks so a night’s collection is a batch, not a process you babysit.
4. Your metric layer. Mention rate, citation counts and share of voice computed by your code on definitions you can explain to a client, per engine (the definitions and traps). Because you hold the raw answers, a skeptical client can be shown the actual AI answer behind any number.
5. Your report. The deliverable is whatever your agency already ships: a Looker page, a PDF, a section in the monthly deck. This is the part you build once and reuse across every client.

This is not a hypothetical architecture: cloro’s own monitoring corpus runs about 1,000 engine answers a day on exactly this pattern (scheduled prompts, per-answer source storage, metrics computed downstream), so the per-client version is the same pipeline with a key and a prompt set per tenant.

The honest trade: the vendor-dashboard route gives you a UI on day one, and the API route gives you a product you own by week two or three of engineering.

What you are buying underneath (the hard part) is the collection: logged-out consumer answers across engines with async webhook delivery, parsed sources, geographic targeting, and the blocking arms race handled by someone else.

What does it cost per client?

About $62 a month in data for a serious configuration. The arithmetic on cloro’s published pricing: 200 prompts a day across six engines costs roughly 5,200 credits daily (engines run 3 to 5 credits per answer), about 156,000 credits a month, and the Hobby tier prices credits at $0.40 per 1,000 ($100 a month for 250,000 credits).

A lighter 50-prompt setup is about $16 a month, and agency-scale portfolios land in the Growth tier ($500 a month for 1,350,000 credits at $0.37), which carries roughly eight serious clients or thirty light ones. Failed requests are not billed.

Set that against what AI-visibility reporting bills for on a retainer, and the margin is the business case. The cost that actually varies is your report layer, and it amortizes across every client you add.

How does this compare to reselling a dashboard?

The dashboard route (Peec, Profound and the other branded trackers we compare in the AEO tools roundup) is faster to start and structurally worse to scale for white-label work, for three reasons that have nothing to do with the dashboards’ quality:

1. Branding belongs to the vendor. Whether your client ever sees the vendor’s name depends on the vendor’s plan tiers, not on you.
2. Definitions belong to the vendor. When a client asks why their “visibility” moved, you are explaining a score you cannot recompute. With your own layer, every number decomposes to stored answers.
3. Pricing scales against you. Per-seat, per-project or per-prompt-cap plans reprice as your client list grows; API data cost scales linearly with prompts and stays a known number per client.

What should the client report actually contain?

The report is where white-label work is won or lost, because it is the only part the client sees. The structure that holds up in a monthly review:

1. Mention rate per engine, as a weekly trend. One row per engine, never a blended number; the engines behave differently enough that a pooled figure hides the story (the metric definitions).
2. Share of voice against the client’s named competitors. The panel is agreed at onboarding and frozen between reviews; every mid-period change to it rescales history and turns the review into an argument about the chart instead of the market.
3. The answers behind the worst number. Two or three stored answers, quoted, where a competitor was recommended and the client was not. This is the section clients act on, and no dashboard export produces it, because it needs the raw responses.
4. Movements with denominators. “Mentions in 41 of 168 ChatGPT answers, up from 29” survives a skeptical CMO; “visibility 24, up 6” does not.
5. One recommended action. The retrieved-but-absent third-party pages from the client’s prompts are a ready-made outreach list, which turns the report from measurement into a deliverable.

Onboarding a new client then has a fixed shape: agree the prompt set and competitor panel, issue the tenant key, run two weeks of baseline before the first report, and date everything. The two-week silence is deliberate; the sample-size math says earlier numbers are noise, and shipping noise in the first report costs credibility the retainer never recovers.

The multi-tenant data model that keeps clients separated

Separation is a sales point (“your data never mixes with another client’s”) only if the schema enforces it. The model that works at agency scale:

1. One API key per client, stored against the tenant record. The key is the isolation boundary at collection time; usage and billing per client fall out of it for free.
2. tenant_id on every row, from the first table. Answers, prompts, panels and reports all carry it; per-client views are then one WHERE clause, and a report can never join across tenants by accident.
3. Prompt sets and panels as versioned config, not spreadsheets. A prompt_set_versions table with effective dates is what lets you answer “why did March’s number move” a quarter later: the answer is often “the panel changed on March 12”, and only a dated record shows it.
4. Offboarding as key revocation plus a retention clock. Revoke the key, stop collection, and let the client’s contractual retention window decide when rows delete. Because the data lives in your warehouse, honoring a deletion request is a query, not a vendor ticket.

Peer trackers solved the same problem with plan structure: Peec’s published tiers meter projects (1, 2 or 5 per plan), and Profound sells brand-scoped monitoring. Building on the API means the workspace concept is four tables you own instead of a plan tier you rent.

Common mistakes agencies make with white-label AI visibility

Three failure patterns come up repeatedly, and all three are avoidable at setup:

1. Selling continuous numbers from a weekly-capable pipeline. If the retainer promises daily-grade alerting, the prompt volume has to support it statistically; the sample-size math says most per-client prompt sets support weekly claims. Sell the cadence the data can carry.
2. Letting clients edit their own prompt sets mid-period. Every edit rescales the trend, and the client who added ten prompts in week three will not remember doing so when the chart dips. Batch changes at period boundaries, in writing.
3. Reporting the score without keeping the answers. The first time a CEO disputes a number, the agency that can paste the three actual AI answers behind it keeps the account. Storage is the cheapest part of the whole stack; keep everything.

The meta-mistake is treating AI visibility as a bolt-on metric in an SEO report. The clients asking for it are asking because ChatGPT and Gemini answers are where their buyers went; the agencies winning the line item run it with the same rigor as their search reporting, which is exactly what the report structure above operationalizes.

Which route fits which agency?

The dashboard route fits when one client wants a tool and you want no engineering. The white-label AI visibility route fits when the metric is becoming a line item on every retainer, because then the report layer pays for itself in margin and in the ability to stand behind the numbers. For how much data those numbers need before a monthly trend is honest, budget with AI visibility sample size.