How to Build an AI Visibility Dashboard

Most teams track their Google rankings every week. Nobody tracks whether they show up when a buyer asks ChatGPT which tool to buy. That second question is the one that matters now, and there is no Search Console for it. AI platforms give you nothing: no impressions, no position, no click data. So Clay's own growth team built one. Our SEO/AEO lead shipped this dashboard in two days, one of three Clay-powered systems running our SEO and AEO, at about 5x less than the off-the-shelf tools we evaluated. We call the discipline AEO, or AI Engine Optimization, and the dashboard is the measurement layer underneath it. This is how we built it, the exact prompts, schema, and code included.

What you need before you start

This build has four layers, and each one does a single job. Clay runs the prompts through the AI platforms and pulls back the raw answers. A second AI pass reads each answer and turns it into structured data. Supabase stores that data as a daily snapshot. A dashboard reads Supabase and renders the metrics; ours is a Next.js app that Claude Code generates from the Supabase data and deploys on Vercel. The whole thing sits on top of Clay and Supabase and touches no core infrastructure, which is why our team could stand it up in two days and could rebuild it in two more if it broke.

The whole point is turning an unstructured AI answer into a row you can query. The sentence "Clay was named third, framed positively, next to HubSpot and Apollo" is a judgment call, not a SQL filter. The architecture exists to make that judgment once, at write time, so every metric downstream is just arithmetic.

You will need a Clay workspace, a Supabase project, and somewhere to host the dashboard (we use Vercel). If you want a running head start, Clay publishes a SEO/AEO Visibility template you can clone instead of wiring every column by hand. Our public build shipped in two days; under the hood that breaks down to wiring Clay and Supabase cleanly, the query layer, and the dashboard. The hardest part was not code. It was writing the analyzer prompt to return clean JSON every time.

Step 1: Design your prompt library

Decide what to track before you write any code. The dashboard is only as good as the prompts you feed it, and the single most important call you make here is splitting prompts into two categories that get reported differently.

Branded prompts inflate your own score, so they never touch your visibility metrics. Every brand looks great when you ask an AI what Clay is used for, because the model always knows what you are. Mix those in and your visibility number is meaningless. Non-branded, buyer-intent prompts (best tools for B2B prospecting, how do I automate outbound) are the only ones that tell you whether you get surfaced when a buyer is not already looking for you.

Tag every prompt with the same metadata you will want to slice by later: Prompt Type (branded, non-branded, or competitive), Topic, PMM use case, Intent (informational, transactional, or navigational), and free-form Tags. Start with 20 to 30 non-branded prompts, then scale once the pipeline is stable. Your leaderboards, topic analysis, and trend lines all filter to non-branded only.

Step 2: Build the Clay table

Each row in the table is one prompt. The columns turn that prompt into a structured record, platform by platform. For each AI platform you track (Claude, ChatGPT, Perplexity), you build the same four-column sequence. We started with Claygent, Clay's AI agent for research, and learned fast that it returns the answer text but not the citation data: the URLs and domains the model actually sourced. That citation signal is one of the most valuable things you can capture, so we rebuilt collection on the native AI API integrations to get it back.

The Parsed Response column is a Formula column. It exists so the analyzer reads clean, flat fields instead of a nested query object. Keeping the query, the parse, and the analysis as separate columns is what makes the whole thing debuggable: when something breaks, you can see exactly what each step produced.

Step 3: Write the analyzer prompt

The analyzer is the intelligence layer, and it is the hardest part of the build. It reads one raw AI answer and returns strict JSON. The fields your metrics need: whether your brand was mentioned and where, sentiment, citation type, cited URLs with each domain classified, competitors mentioned, themes, and how the answer positioned you against rivals.

Normalize competitor names at extraction time, not later. An AI answer might call the same company "ZoomInfo," "Zoom Info," and "DiscoverOrg" across three responses. If you store those raw, your leaderboard shows three competitors where there is one, and the picture fragments. Fixing it once, in the analyzer prompt, keeps every downstream query clean.

Build this as a Use AI column in Clay, the feature that runs GPT, Claude, or Gemini against your row data. Test it on one known row before you scale. Clay reports a 200 OK even when the JSON silently fails to parse, so a strict schema and a test row are the only things standing between you and weeks of broken data.

Step 4: Build the Supabase schema

The schema is five tables, and one design decision carries the whole thing. The responses table holds one row per prompt, per platform, per day, with a UNIQUE (prompt_id, platform, run_day) constraint. That constraint means a same-day re-run overwrites the existing row instead of duplicating it. Add it before you have real data, because retrofitting dedup onto a table full of duplicates is miserable.

The other four tables: prompts (one row per unique prompt), citation_domains (one flattened row per cited URL, for domain analysis), and response_competitors (one flattened row per competitor, for leaderboard queries). Denormalize the prompt metadata into responses so you can filter by topic or type without a join.

Step 5: Write the upsert RPC

Clay calls one Supabase RPC with a single JSONB payload, and that function does every multi-table insert atomically. One problem will bite you the moment you connect the two systems: Clay's analyzer outputs camelCase keys (clayMentioned), but a sane Postgres schema uses snake_case (clay_mentioned). Rather than rewrite either side, make the RPC accept both.

COALESCE makes the endpoint backward-compatible without touching Clay or the schema. Read each field from the camelCase key first, then fall back to snake_case; whichever is non-null wins. Do this from day one and a key rename on either side never breaks ingestion.

The flow inside the function: normalize the payload, upsert the prompt, upsert the response (the unique constraint dedupes), then delete and re-insert the citation and competitor child rows. Replace-all on the children is simpler than diffing and always correct, because the parent response is the single source of truth for what they contain.

Step 6: Connect Clay to Supabase

The link is one HTTP API column per platform that posts to your RPC. Clay's HTTP API column can call any endpoint, native integration or not, which is exactly what you need to reach a custom Supabase function. Point each column at your RPC URL with three headers. The apikey header takes your anon key for PostgREST routing. The Authorization Bearer header takes your service-role key, which grants the RPC write and bypasses row-level security. Reference your Clay columns in the payload with the {{Column Name.field}} syntax.

One behavior to plan around: HTTP API columns fire on enrichment, meaning a scheduled refresh or a manual run, not when the table loads. So Supabase lags Clay by however long a run takes to process. Schedule your runs with Clay's scheduled columns or scheduled sources, and your dashboard refreshes on that cadence.

Step 7: Build the dashboard and define the metrics

The dashboard is a Next.js App Router app deployed on Vercel; we had Claude Code generate it against the Supabase schema, then kept editing by hand. The rule that keeps it maintainable is that components never touch SQL. Every query lives in /lib/queries as a pure async function (getVisibilityScore(supabase, filters)), and the React components just call them. Six pages cover it: Home, Citations, Competitive Intelligence, Sentiment, Prompts (the raw drill-down), and a Metric Explorer for ad-hoc questions.

Six metrics do the work. They are all simple ratios once the analyzer has done the hard part, and the table below is the exact definition behind each number.

The compare-period toggle computes the prior equal-length window and shows the delta, so every metric reads as a trend, not a snapshot. Here is a query-layer function, the shape every metric follows.

Once these are running, a PMM can ask real questions and act on them. Which platforms never mention us (a 0% platform is a content or citation gap). Which topics are we invisible on (the content to create next). Which domains does AI cite for our competitors (the sources to go earn). What does AI say about us versus them in the same answer (the clearest competitive read you can get).

Step 8: Monitor it like an engineering system

A vibe-coded pipeline that ingests silently is the one that hurts you. In late April, OpenAI shifted from GPT-4o to GPT-5.5, the response format changed, and our Clay columns failed quietly: 200 OK, empty parsed response, nulls flowing into Supabase. Weeks of data came in incomplete before anyone noticed.

Silent ingestion failures are worse than loud ones, so monitor for them on purpose. Add a daily row-count check (did we get the expected number of rows for the prompts that ran) and a null-rate check on the fields that matter most (clay_mentioned, citation_type, brand_sentiment). If row count drops or null rate spikes, something upstream changed and you want to know that day, not next month. Treat the whole thing as software with a data contract, not a spreadsheet you check sometimes.

Off-the-shelf AEO tools exist, but they are one-size-fits-all: brand mention rate and sentiment, nothing custom. The reason we built our own is the questions only we will ask. Did our new pricing change how AI describes our value? How fast did our MCP start showing up in AI answers? Those need an analyzer schema you write yourself, which is the entire payoff of this build. The other payoff is maintenance: because the dashboard sits on top of Clay and Supabase and touches no core infrastructure, there is no migration, no contract, and no sunk cost. If something breaks, we rebuild it in two days instead of filing a support ticket. This is what Clay's team means by content engineering as an extension of GTM engineering: the same instinct that turns a buying signal into an automated play turns an AI answer into a tracked, queryable metric.