BigQuery and Linkeddit in Claude: load and query rank and AI answer data

BigQuery is where the tables live. Google's connector lists five tools: execute_sql, get_dataset_info, get_table_info, list_dataset_ids and list_table_ids. Four inspect or read; Google says execute_sql is the only tool that is not read-only. It sees only the data already in your project.

Linkeddit is where the measurements come from. Search records weekly Google ranks and the AI Overview above them. Answer Radar asks the five engines your buying questions and records who is named and cited. Compete grades competitor moves. All of it comes with one plan at $60 a month, and Linkeddit writes no analysis.

Claude sits between them. It reads Linkeddit's data, proposes the SQL, and runs it only after you approve. The one guide in this hub covers the rank and AI Overview table.

Treat each weekly check as a row. Search gives one per keyword with ai_overview_shown and ai_overview_cites_us, so a week-over-week SQL count shows whether Google's Overview names you more often. On the test project, plausible.io, the Overview cited the domain for 4 of the 5 keywords read in one live call, all on a first check, so there is no trend yet and none should be claimed.

Search's aio_impact view goes further when Search Console is connected: it splits keywords into those with and without an Overview and compares Search Console clicks before and after. Its windows default to 28 days each.

The same table design works for the other engines. Answer Radar records which brands each engine names, so a second table keyed by question, engine and check date carries them. Keep the two tables separate, since a Google rank and an engine answer are different measurements.

Share of voice is a ratio you compute, not a number you fetch. Load per-engine answer rows from Answer Radar, one per question, engine and check, with the brands named, then ask Claude to write the SQL: your mentions divided by all mentions, by engine and week. The query is yours, and so is the choice of denominator.

Competing guides, such as Supermetrics, show the same idea for Semrush data: compare your domain's visibility against competitors with SQL-powered share of voice reports. The difference here is the source. It is what the answer engines said when asked your buying questions, not a rank estimate.

Cap each pull. Google documents a 3,000-row result limit and a three-minute query limit on the BigQuery connector, so aggregate in SQL instead of asking Claude to read raw rows back.

For one week of data, you do not need to. Claude can read Linkeddit's checks and answer directly. BigQuery earns its place when you want history that outlives a conversation, joins to Search Console or revenue tables, or a table other tools such as Looker Studio can read.

Google's Search Console bulk export already puts your performance data there daily, which is the other half of the join. Its first export arrives up to 48 hours after setup and is not retroactive. Weekly rank checks stored from today give you the measured side to line up against it.

History matters because rank moves and comes back. An SEO at an agency on Reddit described a page that kept doing this: "Only for that page to drop out of the top 100 rankings for a period of time (sometimes a few days / sometimes a week or so)." Dated rows in a table make a gap like that visible later.

Start with a scratch dataset. Ask Claude to show every statement before it calls execute_sql, and give the agent its own identity with the narrowest roles that work. Google recommends a separate identity for agents using MCP tools so access can be controlled and monitored, and it documents IAM deny policies for read-write MCP tools.

Keep measured fields apart from your own judgments. Store Linkeddit's values as delivered, including nulls. A null rank means not in the top 10 and a null change means there was no earlier check or either check was outside the top 10; neither is zero.