I connected Google Analytics to Claude Code. Here's the setup, step by step.

If you run more than two websites, the GA4 dashboard stops being useful. I have five properties to check. ProfitBooks, ButterBlogs, HelpGuides, LevelUp, and a reviews site. Checking all of them properly means five logins, five date-range pickers, and a lot of squinting at line charts that all look vaguely like they’re going down.

Last week I wired Google Analytics directly into Claude Code using Google’s official MCP server. Now I ask a question in plain English and it pulls the actual numbers. “Which ProfitBooks landing pages lost the most organic sessions since April?” comes back in about twenty seconds, with the numbers, and then we argue about what caused it.

It’s free, it took me under an hour, and I’m not a developer. Here’s exactly how I did it.

Why the GA4 dashboard fails once you run multiple products

GA4 is built for one property at a time. The moment you’re comparing patterns across products, or checking whether a content change actually moved anything, you’re doing manual work that a machine should do. The dashboard shows you what happened. It won’t tell you why, and it definitely won’t do it across five sites at once.

The specific thing that pushed me over the edge was traffic recovery work after a Google algorithm update. I’d rewritten a batch of ProfitBooks landing pages around answer-first structure, added FAQ schema, the usual GEO work. Then I wanted to know if any of it landed. That question requires comparing page-level organic traffic across two date windows, filtered to the pages I’d actually touched.

In GA4 that’s a fifteen-minute exploration report I have to rebuild every time. As a question I type into Claude, it’s one sentence.

What the Google Analytics MCP server actually does

MCP is a protocol that lets Claude call external tools. Google publishes an official Analytics MCP server that runs on your own machine and connects Claude to the GA4 Data API and Admin API. It’s read-only, Apache-licensed, and maintained by Google’s own analytics team rather than a third party.

It exposes a small set of tools. Listing your accounts and properties. Pulling property details and custom dimensions. Running standard reports, funnel reports, and realtime reports. That’s the whole surface area.

Read-only matters here. It cannot change your tracking setup, edit key events, or touch your data streams. If you’re nervous about pointing an AI at analytics for a live business, that constraint is the reassuring part. The worst it can do is read.

The other thing worth knowing before you start: it runs locally. That means it works in Claude Code and Claude Desktop, and it will not work in claude.ai in your browser. If browser access matters to you, this isn’t the right route.

How to set up the Google Analytics MCP server in Claude Code

Six steps. Steps one through four are one-time terminal setup, then you never touch them again. Open Terminal on your Mac and go.

1. Install the two tools it needs.

brew install pipx
pipx ensurepath
brew install --cask google-cloud-sdk

Close and reopen your terminal after this so your shell picks up the new commands.

2. Set up a Google Cloud project.

Go to console.cloud.google.com and create a project. Any name. No billing needed for this. Then enable three APIs from the API Library: Google Analytics Admin API, Google Analytics Data API, and Google Search Console API (searchconsole.googleapis.com). Copy your Project ID from the dashboard. It’s the lowercase-with-dashes one, not the display name.

The third one isn’t strictly required to make Analytics work, but enable it now anyway. You will want Search Console data alongside GA4 within about a week, and enabling it later means walking back through the consent screen and re-authenticating.

3. Create an OAuth client.

In the same console, go to APIs & Services, then Credentials, then Create Credentials, then OAuth client ID. Choose Desktop app as the type. If it asks you to configure a consent screen first, pick External and add your own email as a test user. Download the JSON file when it’s created.

4. Authenticate.

gcloud auth application-default login \
  --scopes https://www.googleapis.com/auth/analytics.readonly,https://www.googleapis.com/auth/cloud-platform \
  --client-id-file=/path/to/your-downloaded.json

A browser opens. Sign in with the Google account that has access to your GA4 properties. When it finishes, the terminal prints a line saying where your credentials got saved. Copy that path.

5. Register the server with Claude Code.

claude mcp add analytics-mcp \
  --scope user \
  -e "GOOGLE_APPLICATION_CREDENTIALS=YOUR_CREDENTIALS_PATH" \
  -e "GOOGLE_PROJECT_ID=YOUR_PROJECT_ID" \
  -- pipx run analytics-mcp

That --scope user flag is the important bit. It registers the server for your whole machine, so every Claude Code session everywhere can use it. You do this once.

6. Test it.

mkdir ~/Documents/analytics-hq
cd ~/Documents/analytics-hq
claude

Then type: list all my Google Analytics accounts and properties. If your properties come back, you’re done.

Where to put it: not inside your product repos

Make a separate folder for analytics work and never do it inside your codebase. I use ~/Documents/analytics-hq. It’s a plain folder, not a Git repo, because there’s nothing here to commit.

The reason is context hygiene. My ButterBlogs repo has a CLAUDE.md tuned for that codebase. Dropping traffic-analysis conversations into it pollutes the context for actual development work, and vice versa. Keeping analytics in its own folder means each session starts with the right frame.

That folder gets its own CLAUDE.md. Mine holds a table of property IDs mapped to products, which markets each product targets, and dated notes about when I shipped things. That last part does more work than you’d expect. If Claude knows the ProfitBooks Australia pages went live in a specific month, it stops treating the pre-launch period as a fair comparison window.

What can you actually ask it?

Anything you could build as a GA4 report, phrased as a sentence. Traffic by page, by channel, by country, by device, over any date range you want, with follow-up questions that would each be a separate exploration report in the dashboard. The querying stops being the work. The thinking becomes the work.

These are the ones I keep reusing:

• Which pages lost the most organic sessions in the last 90 days compared to the previous 90?
• What are my top 20 landing pages by organic traffic, and what’s the engagement rate on each?
• Which pages get high traffic but under 30 seconds average engagement time?
• Break down sessions by channel for the last six months and show me the trend per channel.
• Which countries send the most traffic to my pricing page, and how does conversion differ by country?
• Show me the funnel from landing page to signup, and where the biggest drop-off is.
• What are the top events on this property in the last 180 days?
• Compare traffic to the pages I published after April 2026 against the older ones in the same category.
• Which referral sources actually drive engaged sessions, not just clicks?
• What’s happening on the site right now, by page and by country?

The last one uses the realtime report, which is genuinely useful the hour after you publish something or post a link somewhere.

Two habits make the answers better. Say the property name in your prompt when you have several, otherwise it guesses. And ask the follow-up you’d normally skip, because the marginal cost of question five is now roughly zero.

What it can’t do, and why that matters

It answers when asked. It has no triggers, no alerts, no scheduled monitoring. If ProfitBooks traffic falls off a cliff on a Tuesday, this setup will not tell you. You’ll find out when you next think to ask.

It also only sees GA4. GA4 tells you what happened on your site and says nothing about what happened in search results before the click. For traffic-drop diagnosis you want Search Console data alongside it, and that’s a separate MCP server.

Neither of those is a reason to skip it. But if you go in expecting an autonomous analyst that watches your sites, you’ll be disappointed. What you actually get is a very fast, very patient junior who never complains about pulling the same report a fourth time with a different filter.

The thing I didn’t expect: the value isn’t the reports. It’s that asking a follow-up question now costs nothing. In GA4 every follow-up is another five minutes of clicking, so I’d stop after the first answer. Now I ask six. About half the time the interesting finding is in question four, which I would never have reached before.