Google Data Access for GrowReach CRO Agent — Architecture Recommendation

Goal: Give the CRO agent access to Google Search Console (GSC), Google Analytics 4 (GA4), and Google Tag Manager (GTM) data so everything can be collected in one place to correlate, analyze, present reports, and make decisions.

Date: 2026-08-17 Author: Hermes (Kanban task t_f926cbab) For: Rahul / GrowReach CRO agent


Executive Summary

The CRO agent already has PostHog (EU, project 136693, read-only). The single best move is to pull GSC and GA4 into PostHog’s Data Warehouse as managed sources — this makes all your Google data joinable with existing PostHog event data in one place, queryable via HogQL, and visible to the existing PostHog MCP tool. GTM is config (not analytics data) and should stay in the Google console; it does not belong in a warehouse.

Recommended path (short): Link GSC + GA4 as PostHog Data Warehouse sources (native, ~10 min each, no code). Skip direct MCP for the CRO agent. Use Sheets export only as a manual fallback for ad-hoc shareable reports.

Why: Native PostHog sources give you a single queryable store, automatic daily syncs, and reuse of the PostHog MCP the CRO agent already has — no new credentials, no new MCP servers, no per-tool OAuth sprawl.


The Four Questions, Answered

Q1. Is there an MCP or CLI tool for GA4 / GSC / GTM?

Yes — several exist, but they are the hard path for this use case.

ProductOfficial MCP?Notes
GA4Yes — google-analytics-mcp (official Google, 3.0k★, Apache-2.0)Read-only via analytics.readonly scope. run_report, run_funnel_report, run_realtime_report. Needs Google Cloud project + ADC/service-account setup.
GA4 (managed)Composio Google Analytics toolkitAlready have Composio connected. Managed OAuth — no manual Cloud setup.
GSCCommunity — mcp-gsc, search-console-mcpCommunity-built; service-account or OAuth. Quality varies.
GSC (managed)Composio Google Search Console toolkitManaged OAuth.
GTMCommunity — mcp-google-tagmanager, sprawz/gtm-mcp-serverGTM API is for managing containers/tags, not analytics. Low value for CRO analysis.

Key caveat (evidence-based): The official GA4 MCP and community GSC MCPs require you to create a Google Cloud project, enable APIs, and configure either a service account or OAuth Application Default Credentials. That’s real setup friction. And third-party analyses have flagged data-accuracy risks in the MCP path — the Coupler.io review reported hallucinated trends and row-limit truncation that would be disqualifying for business decisions. This strongly favors the managed PostHog-source path (Q2) for the CRO agent.

Q2. Can Google data be pulled into PostHog (Data Warehouse sources / CDP)?

Yes — this is the recommended path. PostHog has native managed sources for both:

  • Google Analytics source — syncs daily report data from a GA4 property. Tables: website_overview, daily_active_users, weekly_active_users, four_weekly_active_users, devices, locations, pages, traffic_sources, user_acquisition, landing_pages, campaigns, key_events, events. Requires GA4 Property ID (numeric — not the G-XXXX measurement ID). Note: currently in alpha.
  • Google Search Console source — syncs daily Search Analytics: clicks, impressions, CTR, avg position. Tables: search_analytics_by_date, _by_query, _by_page, _by_country, _by_device, _by_query_page, _by_search_appearance.

Both authenticate with OAuth (analytics.readonly scope) — sign in with a Google account that has read access; no Cloud project needed.

No GTM source exists in PostHog — because GTM holds no analytics data. GTM is a tag-management config surface; its “data” is your tag/trigger configuration. That belongs in the GTM console (or via GTM MCP if you ever want agent-driven tag changes), not in a warehouse.

PostHog Data Warehouse: first 1M rows/month free, usage-based beyond that — no credit card needed to start.

┌────────────┐   OAuth    ┌───────────────────────────────┐
│  GA4       │ ─────────► │                               │
│ G-2DSCDB28 │            │   PostHog Data Warehouse      │
│            │            │   (EU, project 136693)        │
├────────────┤   OAuth    │                               │
│  GSC       │ ─────────► │   • PostHog events (existing) │
│ (sc-domain)│            │   • GA4 tables                │
├────────────┤            │   • GSC tables                │
│  GTM       │  (not      │                               │
│  MQDVLQ6P  │  imported) │   ── queryable via HogQL ───► │
└────────────┘            │   ── visible to PostHog MCP ─►│  CRO Agent
                          └───────────────────────────────┘
  • PostHog = single source of truth. PostHog events + GA4 + GSC all joinable with SQL/HogQL, and the CRO agent’s existing PostHog MCP can query it all. No new MCP servers, no new OAuth to manage for the agent.
  • GTM stays in Google console. It’s configuration, not analytics. If you later want the agent to edit tags, add a GTM MCP to a specialized profile — not needed for CRO analysis.
  • Sheets export is the manual/fallback layer for one-off client-facing reports (via the googlesheets toolkit Rahul already has connected).

Q4. What does Rahul need to do (OAuth, credentials, etc.)?

Minimal. No Google Cloud project, no service account, no API keys — just one-time OAuth in the PostHog UI, using the Google account that owns the properties.

For GA4 (alpha source):

  1. Get the numeric GA4 Property ID: GA4 → Admin → Property settings → Property details. (Do not use the G-2DSCDB28FB measurement ID.)
  2. PostHog → Data pipeline → Sources → + New sourceLink next to Google Analytics.
  3. Sign in with the Google account that has read access to the GA4 property (PostHog requests analytics.readonly).
  4. Enter the numeric Property ID.
  5. Select tables + sync method + frequency → Import. (Use Incremental for daily freshness.)

For GSC:

  1. PostHog → Data pipeline → Sources → + New sourceLink next to Google Search Console.
  2. Sign in with the same Google account.
  3. Enter the Property URL — for GrowReach use the domain-property format sc-domain:growreach.app.
  4. Select the 7 tables + Incremental sync → Import.

For GTM: nothing to do. Optionally add a GTM MCP later for tag editing.

Note on the Google account: Rahul should use the account that has full access to the GA4 property and the GSC property (likely the primary 3rd.rahul or a shared marketing account). Confirm read access before starting.


Options Compared

CriterionA. PostHog Data Warehouse sources (RECOMMENDED)B. Direct MCP (GA4 official / GSC community)C. Sheets export
Setup effortLow — OAuth in PostHog UI, ~10 min/sourceHigh — Google Cloud project, enable APIs, service account or ADCLow-Medium — Google Sheets API/auth + sync script
Unified querying✅ Yes — GA4 + GSC + PostHog events joinable❌ No — each MCP returns tool output, no joins❌ No — separate sheets
Reuse CRO agent’s PostHog MCP✅ Yes❌ No — new MCP servers needed❌ No
Data accuracy / reliability✅ High — PostHog handles ETL, documented sync limits⚠️ Flagged hallucination + row-limit truncation risks⚠️ Manual, error-prone
Automation / daily freshness✅ Native incremental syncs❌ On-demand queries only⚠️ Manual or cron
New credentials to manageNone (OAuth via UI)Yes — Cloud keys / service accountsYes — Sheets auth
CostFree (1M rows/mo)Free (Google APIs)Free
Best forLong-term unified CRO analysisQuick ad-hoc single-source questionsOne-off shareable reports

Verdict: A over B. Option B duplicates what PostHog already does, adds credential sprawl, and reintroduces the accuracy risks flagged in independent reviews. Use A as the foundation; keep C (Sheets) as a manual fallback for shareable deliverables.


  1. [This week] Link GSC in PostHog — ~10 min. Get the CRO agent’s core SEO data flowing.
  2. [This week] Link GA4 in PostHog — ~10 min. Note it’s an alpha source; monitor the first few syncs.
  3. Verify in the CRO agent — run a HogQL query through the PostHog MCP joining PostHog events ↔ GSC search_analytics_by_page on page path to confirm the unified view works.
  4. Build a CRO dashboard in PostHog pulling from all three (events + GA4 + GSC).
  5. [Optional, later] GTM MCP only if the agent should edit tags — assign to a specialized profile, not the CRO agent.

Sources