Building Google Analytics and Search Console AI Skills: A Unified Approach to Data-Driven Decision Making

Making informed decisions from real-time data matters for any business, but when you’re a solo entrepreneur wearing every hat at once, the gap between having the data and actually using it becomes painfully obvious. I’ve spent years working at the intersection of data systems and applied technology, and the challenge I kept running into wasn’t that the tools didn’t exist. They did. The problem was that the time and complexity required to pull meaningful insights out of them created a bottleneck I couldn’t justify, not when I also had a product to build, users to support, and a business to grow.

That friction is what pushed me to build two Claude AI skills: Google Analytics Insights and Google Search Console Insights. By combining them with a hybrid MCP workflow, I ended up with a unified system that works for me whether I’m heads-down writing code or stepping back to think about strategy in Claude Desktop.

The problem and its context

When I launched Tarsia.ai, a platform designed to make math more approachable for students and educators, I understood early on that tracking user engagement and SEO performance would be critical. Not eventually critical. Immediately critical. But as a solo founder, the tension between needing that data and having the bandwidth to go get it never really went away. I couldn’t wait on outside developers to build custom dashboards. I also couldn’t spend my evenings navigating query interfaces just to figure out whether users were actually engaging with the content or bouncing off after thirty seconds.

So I leaned into automation. The Google Analytics Insights skill gave me custom reports that surface daily engagement patterns, user flows, and drop-off points. I could see at a glance where users were spending time and, more importantly, where they were leaving. Then I built the Google Search Console Insights skill on top of that, which brought in automated SEO reporting: keyword performance, indexing health, click-through trends. Everything feeding into the same workflow. No more switching between three different tabs and trying to mentally stitch the picture together.

How it works

Both skills follow the same architecture: a Python layer that authenticates with Google’s APIs via a service account, runs queries against GA4 or Search Console, and exposes the results through an MCP server that Claude can call as a tool.

โ”Œโ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”
โ”‚            Claude Code / Desktop             โ”‚
โ”‚         (MCP Client + Skill Runner)          โ”‚
โ””โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”ฌโ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”ฌโ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”˜
           โ”‚                  โ”‚
    โ”Œโ”€โ”€โ”€โ”€โ”€โ”€โ–ผโ”€โ”€โ”€โ”€โ”€โ”€โ”    โ”Œโ”€โ”€โ”€โ”€โ”€โ”€โ–ผโ”€โ”€โ”€โ”€โ”€โ”€โ”
    โ”‚  GA4 Skill  โ”‚    โ”‚  GSC Skill  โ”‚
    โ”‚ (MCP Server)โ”‚    โ”‚ (MCP Server)โ”‚
    โ””โ”€โ”€โ”€โ”€โ”€โ”€โ”ฌโ”€โ”€โ”€โ”€โ”€โ”€โ”˜    โ””โ”€โ”€โ”€โ”€โ”€โ”€โ”ฌโ”€โ”€โ”€โ”€โ”€โ”€โ”˜
           โ”‚                  โ”‚
    โ”Œโ”€โ”€โ”€โ”€โ”€โ”€โ–ผโ”€โ”€โ”€โ”€โ”€โ”€โ”    โ”Œโ”€โ”€โ”€โ”€โ”€โ”€โ–ผโ”€โ”€โ”€โ”€โ”€โ”€โ”
    โ”‚  GA4 API    โ”‚    โ”‚  GSC API    โ”‚
    โ”‚ (Analytics) โ”‚    โ”‚ (Search)    โ”‚
    โ””โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”˜    โ””โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”˜

The key design decision was making each skill work in two modes: as a Claude Code skill (invoked directly via /ga4 or /gsc commands) and as a standalone MCP server (connectable from Claude Desktop, Cursor, or any MCP-compatible client). That dual-mode approach meant I didn’t have to maintain two separate toolsets for different environments.

Here’s what a typical skill configuration looks like in your MCP settings:

{
  "mcpServers": {
    "ga4-insights": {
      "command": "python3",
      "args": ["/path/to/ga4-skill-mcp/server.py"],
      "env": {
        "GA4_PROPERTY_ID": "properties/YOUR_PROPERTY_ID",
        "GOOGLE_APPLICATION_CREDENTIALS": "/path/to/service-account.json"
      }
    }
  }
}

Once connected, Claude has access to tools like run_ga4_report and get_search_analytics, which it can call autonomously when you ask questions about your site’s performance.

Standing on the shoulders of others

Neither of these skills came out of nowhere. The Google Analytics skill grew out of Anthony Lee’s article How to Set Up Google Analytics as a Claude Code Skill, where he walks through connecting GA4 data to Claude Code via a service account and a Python query script. The Search Console skill drew heavily from Amin Foroutan’s mcp-gsc project, an MCP server for querying Search Console data. I took concepts and implementation patterns from both, adapted them into Claude Code skills, and added an MCP server layer so the whole thing could fit the workflow I actually needed, not just the one that existed in isolation.

Illustration of Google Analytics and Search Console data flowing through Claude AI skills

Cross-correlating the data

Each skill on its own is useful. I won’t pretend otherwise. But the real shift happened when I started cross-correlating both datasets inside the same system. By linking Analytics engagement metrics with Search Console query data, I could trace a search term from its initial impression all the way through to how that user actually behaved once they landed on Tarsia.ai. Did they stick around? Did they bounce? Did they convert?

That’s the kind of question that’s surprisingly hard to answer when your data lives in two separate tools with two separate logins and two separate mental models. Bringing them together let me separate the search terms that were genuinely driving engaged users from the ones that looked good on a dashboard but weren’t producing real interaction. That single distinction reshaped how I think about content strategy for the platform.

AI as a thought partner

I want to be clear about something, because I think people get this wrong. AI works best in this workflow as a thought partner, not an autopilot. Google’s algorithm changes constantly, and the skills I built do a good job of flagging shifts and surfacing patterns as they happen. But I still have to sit with the data and ask whether what I’m seeing reflects genuine user demand or just a temporary fluctuation in search behavior. That judgment call is mine. Having both tools wired into my day-to-day means I can move between coding, testing a hypothesis, or chasing down a new research thread without ever losing access to the data informing those decisions. The system meets me wherever I am in the process, but it doesn’t decide for me.

What this approach has unlocked

Since integrating these skills into my hybrid MCP setup, the results have been concrete. One of the clearest findings was that roughly 75% of my organic traffic in this niche is concentrated around a handful of search keywords. That’s the kind of thing you might suspect intuitively, but seeing it confirmed across both Search Console and Analytics data made it actionable. I stopped trying to be everywhere at once and focused on optimizing the experience around what those users were actually trying to achieve when they landed on the site. The result was a 10% increase in conversion, which for a solo-run platform is significant.

That kind of insight is invisible when your data lives in silos. It only surfaces when you can ask a single system to connect the dots across both platforms, tracing the path from what someone searched for to whether they actually got what they came for.

The through-line in all of this, and something I keep coming back to in my work more broadly, is that AI doesn’t replace the effort of building a business. It gives a solo founder the kind of analytical depth that would normally require a team. That’s not a small thing.

Putting it into practice

To make this more concrete, here’s an example of how I actually prompt Claude when I’m investigating something specific. Say organic traffic has started to dip and I want to understand why:

Analyze Google Search Console data over the last 90 days and identify any queries or pages where organic traffic has declined compared to the previous 90-day period. Then cross-reference those findings with Google Analytics engagement data for the same pages to determine whether the decline correlates with changes in user behavior, such as increased bounce rates or decreased session duration. Break the analysis down by page and by query. Cite every query you run and every data point you surface so I can review the raw findings manually.

A few things about why I structure it this way. The explicit time range and comparison baseline matter because without them, “decline” is meaningless. Decline compared to what? I also ask for a breakdown by page and query rather than leaving the scope wide open, because an unfocused investigation tends to produce an unfocused answer. And the citation requirement at the end is the most important part. I want to see every query Claude ran and every number it pulled, because the whole point is that I’m reviewing the conclusions myself. The AI surfaces the data. I make the call.

Here’s a representative example of the kind of output Claude returns when I run that prompt:

## Search Console: Declining Queries (90-day comparison)

| Query                        | Clicks (prev) | Clicks (curr) | Change  | CTR Change |
|------------------------------|---------------|---------------|---------|------------|
| tarsia puzzle maker          | 342           | 187           | -45.3%  | -2.1%      |
| math puzzle generator free   | 218           | 156           | -28.4%  | -0.8%      |
| jigsaw activity template     | 189           | 91            | -51.9%  | -3.4%      |

## GA4: Engagement on Affected Pages

| Page                   | Bounce Rate (prev) | Bounce Rate (curr) | Avg Session (prev) | Avg Session (curr) |
|------------------------|--------------------|--------------------|--------------------|--------------------|
| /create                | 42%                | 67%                | 2m 34s             | 0m 48s             |
| /templates             | 38%                | 41%                | 3m 12s             | 2m 55s             |

## Cross-Correlation Finding
"tarsia puzzle maker" drives traffic primarily to /create, where engagement
has deteriorated significantly. The bounce rate increase (+25pp) combined
with the session duration drop suggests a content-intent mismatch that
emerged after the page layout was restructured in the previous release.

The output reads like a brief you’d hand to an analyst, except I didn’t have to write the queries or pull the data myself. Claude ran the API calls, formatted the comparison, and flagged the mismatch. My job at that point is to look at the finding and decide what to do about it.

When I’m in a hurry, a shorter version works too:

Analyze Search Console for organic traffic declines over the last 90 days versus the prior period. Use Analytics to confirm whether engagement metrics changed on affected pages. Cite all queries run and data pulled.

Both trigger the same cross-correlation workflow. The longer version just tends to give me more structured output, which I prefer when I’m doing a deep dive.

For anyone else building on their own, I’d say stay curious and keep validating. These skills are open source if you want to try them: ga4-skill-mcp and gsc-skill-mcp.


This is a guest post by Jonathon O’Reilly, founder of Tarsia.ai.

Get the Daily Pulse

Sharp analysis on what's actually moving in AI. No hype, no filler, no weekly digest.

Get the Daily Pulse

Sharp AI analysis, daily. Two minutes, every morning.

Get the Daily PulseTwo minutes, every morning