Claude Code analytics: turn your agent into a data analyst

"Claude Code analytics" means two different things, so let's route you correctly in one paragraph. If you're looking for analytics about Claude Code — token consumption, session counts, spend per project — that's the Anthropic console's job, plus community tools like ccusage; close this tab with our blessing. This article is the other direction: using Claude Code for data analysis — turning the agent in your terminal into a working data analyst over your marketing and product numbers. The bottom line up front: the agent's reasoning was never the bottleneck. Give it a queryable backend with fixed metric definitions and machine-readable trust metadata, and it produces analysis you can actually defend in a Monday meeting.

The real bottleneck isn't reasoning — it's reachable, trustworthy data

Claude Code writes better SQL than most of us on a good day, and it's tireless about follow-up questions. Yet "ask my agent to analyze the business" fails in practice for two mundane reasons:

• Reachability. The numbers live behind OAuth flows and quota-limited APIs — Search Console, GA4, Meta, Google Ads. A coding agent's native world is your filesystem; pasting CSV exports into chat works exactly once, then rots.
• Trustworthiness. Every platform speaks its own dialect. Meta's purchase value is not GA4's conversion value is not your CFO's revenue. An agent handed raw exports will silently pick one interpretation, compute something plausible, and narrate a wrong story with total confidence. The failure mode isn't bad math — it's mislabeled math.

So the job is infrastructure, not prompting: a place the agent can query read-only, where definitions are fixed ahead of time, and where every answer says how fresh it is and what it must not be compared to. That's what TableBI provides — a data backend for your Claude Code, with your agent as the brain and a deterministic SQL engine doing every piece of arithmetic. TableBI hosts no LLM at all: $0 inference, no second model between you and your numbers. (How that compares to "chat with your data" products that do run their own model over your warehouse is a separate discussion — see chat with your data, without handing it to another model.)

Two altitudes: unified metrics and lossless raw

Once connected, every source syncs into two layers, and knowing which one to query is half of doing good analysis:

• The metrics altitude — facts. One cross-channel table with fixed dimensions (date, platform, account, campaign, ad_group, ad, channel, country) and fixed measures (clicks, impressions, cost, conversions, conversion_value). Spend is spend and clicks are clicks regardless of which platform reported them, so cross-channel questions become one GROUP BY.
• The raw altitude — search_console_raw, ga4_raw, meta_ads_raw, google_ads_raw. Per-platform tables holding exactly what each platform reported, nothing merged or averaged away. This is where you go when a number looks wrong and you need the original rows as evidence.

The rule of thumb: decide at the metrics altitude, dispute at the raw altitude. Weekly calls and budget moves run on facts; forensic questions — "did the platform really report zero that day, or did we lose rows?" — drop to raw. Losing either altitude hurts: unified-only means you can't audit; raw-only means every cross-channel question becomes a bespoke reconciliation project.

Trust blocks: how the agent avoids mixing up numbers

An autonomous analyst is only safe if the metadata travels with the data. Every query answer arrives with a trust block carrying three things:

1. Freshness — the exact date each source runs through. GSC's final data officially lags 2–3 days; ad platforms restate recent conversions. The agent sees "data through Tuesday" and says so, instead of reporting a fake crash.
2. Caveats — the category errors, written down. The canonical one: GSC clicks ≠ GA4 sessions — different definitions that shouldn't be expected to match. An agent that has read that caveat stops "reconciling" two numbers that were never supposed to be equal, and starts explaining why they differ.
3. Lineage — where the number came from, so "wait, which table is this?" has an answer.

One more guardrail worth knowing before you write queries: the query layer rejects wall-clock anchors like current_date. Date windows anchor to the data's own high-water mark instead — WHERE date >= (SELECT MAX(date) FROM facts) - 28 — which makes "last 28 days" mean 28 days of data that actually exists, even while a source is mid-lag.

Wire it up in five minutes

# CLI + the skill that teaches your agent the commands
npm i -g @tablebi/cli
tablebi login
tablebi install

# connect sources once — OAuth opens in the browser
tablebi connect ga4
tablebi connect google_ads
tablebi connect meta_ads
tablebi connect gsc --site sc-domain:example.com

# anything without an API arrives as CSV, same definitions
tablebi connect csv --file tiktok-export.csv --platform tiktok_ads

tablebi install plants a skill in ~/.claude/skills, so from now on plain requests — "how did paid do last week?" — trigger the right commands. Each session opens with tablebi context --json, which rehydrates definitions, connected sources, freshness and the command cheatsheet in one call.

Claude Code analytics in practice: three queries

1. Cross-channel ROAS. The question every budget meeting starts with, answered from one table. The macros (roas, cpa, and friends like ctr, cpc, cpm, cvr) are definitions the engine expands identically every time — the agent never re-derives arithmetic from memory:

tablebi ask "SELECT platform, SUM(cost) AS spend,
             roas(SUM(conversion_value), SUM(cost)) AS roas,
             cpa(SUM(cost), SUM(conversions)) AS cpa
             FROM facts WHERE date >= (SELECT MAX(date) FROM facts) - 28
             GROUP BY platform ORDER BY spend DESC"

2. GA4 channel trend. Same table, filtered to one platform, split by the channel dimension — the day-by-day shape of where conversions come from:

tablebi ask "SELECT date, channel, SUM(conversions) AS conversions
             FROM facts
             WHERE platform = 'ga4'
               AND date >= (SELECT MAX(date) FROM facts) - 28
             GROUP BY date, channel ORDER BY date"

3. The forensic drill-down. When an aggregate looks suspicious, drop an altitude and pull the original rows — here, day-by-day Search Console rows for a single query, exactly as Google reported them:

tablebi ask "SELECT date, page, clicks, impressions, position
             FROM search_console_raw
             WHERE query = 'your brand term'
               AND date >= (SELECT MAX(date) FROM search_console_raw) - 7
             ORDER BY date DESC"

This is the loop a human analyst runs — aggregate, notice, drill down, explain — except your agent runs it in seconds, and every number along the way came out of the SQL engine rather than the model's imagination.

Pin the analysis so it outlives the session

Analysis that lives in scrollback gets re-done next week. When a result earns its keep, the agent pins it into a live dashboard — a public, read-only URL that refreshes itself as sources sync:

tablebi pin --title "Cross-channel performance" \
  --widget "Daily conversions (28d)::line=SELECT date, SUM(conversions) AS conversions FROM facts WHERE date >= (SELECT MAX(date) FROM facts) - 28 GROUP BY date ORDER BY date" \
  --widget "ROAS by platform=SELECT platform, roas(SUM(conversion_value), SUM(cost)) AS roas, SUM(cost) AS spend FROM facts WHERE date >= (SELECT MAX(date) FROM facts) - 28 GROUP BY platform ORDER BY spend DESC"
✓ published → https://dk.tablebi.com/d/dsh_…  (public, read-only, self-refreshing)

::line makes a widget a line chart; the default is a table. Here's a real pinned dashboard running on live Search Console data. The dashboard side — widget patterns, sharing, refresh behavior — gets a full write-up in Claude Code dashboards, and the marketing-flavored tour of the same stack is in Claude Code for marketing.

FAQ

npm i -g @tablebi/cli && tablebi install