One dashboard across Ads, Analytics and Search Console — and what to do about it.
Google gives you three consoles that don't talk to each other. MetricFabric.io joins Search Console, GA4 and Google Ads into a single view, then tells you where your ad spend is wasted and which pages and queries are worth working on.
Three sources, joined on the page and the query.
The joins are the point. Once impressions, sessions, conversions and cost sit on one row, the recommendations write themselves.
Every property in the account, at the row limits the API allows, plus your BigQuery bulk export if you have one.
Landing-page performance keyed to the same URLs as Search Console, so organic impressions and outcomes sit on one row.
Search-term level detail is what makes the paid-versus-organic join possible, and what makes wasted spend findable.
Recommendations, not another chart.
Deterministic checks run every day against your own rows. Each one names the account, the number and the action.
Search terms where you rank first organically and still buy the click. Needs Ads and Search Console together — which is why nobody else reports it.
Broad-match terms burning budget with no conversions, and campaigns losing impressions to budget caps while others underspend.
Queries sitting at positions 5–15 where a small gain pays, and pages whose impressions have been sliding for months before the traffic drop shows.
Or ask it yourself, from the AI client you already use.
When you want to go past the dashboard, your MCP endpoint reads the same joined data directly — across all three sources and across your whole history, not just the window Google's own tooling still holds.
How the endpoint works →→ ads.search_terms(term, range: 2025-07-01…2025-09-30)
What we do with your Google data
We request read-only scopes and use the data only to provide the features you can see in your own account. We do not sell it, we do not use it for advertising, and we do not use it to train or improve any generative model. Data is stored in Germany and deleted 90 days after you cancel — exportable in full until then.
One dashboard, then the actions.
Everything below is a view onto rows we hold in one schema. That is what makes the cross-source joins possible, what makes the recommendations checkable, and what keeps your history when Google's window has moved on.
The reports that need more than one source
Every one of these is a deterministic rule over your own rows — checkable, explainable and cheap. Where the product writes prose about a finding, the finding came first.
A read-only interface onto your own joined data.
Not an AI integration in the sense that we send your data somewhere. An authenticated endpoint, scoped to one workspace, that answers requests you make from a client you configured.
"mcpServers": {
"metricfabric": {
"url": "https://mcp.metricfabric.io/w/acme/sse",
"headers": { "Authorization": "Bearer oc_live_…" }
}
}
}
Tokens are created and revoked by you, scoped to a single workspace, and never carry your Google credentials — those stay on our servers. Every call is logged against your workspace so you can see exactly what left it and when.
Pricing
One dashboard across all three sources, with recommendations that name the action. 14 days free while the first audit runs, so you see what it finds in your own accounts before you pay — and unlimited retention on every plan, because the joins need the history.
{{ plan.blurb }}
We keep collecting and show you the overage — £6/mo per extra property on Warehouse, £5/mo on MCP. Halting ingestion to enforce a plan limit would destroy the one thing you are paying us for.
Exportable in full the whole time, in CSV or Parquet. After 90 days it is deleted and our Google access tokens are revoked. You can also delete everything immediately yourself.
Where your data lives, and who can reach it.
Written plainly because reviewers, buyers and your own clients all ask the same questions.
TLS 1.2+ in transit with HSTS, AES-256 at rest for databases, object storage and backups. OAuth and MCP tokens live in a dedicated secrets store with envelope encryption and are excluded from all logs.
Every row carries a tenant identifier and isolation is enforced by row-level security in the database, not by application code alone. MCP tokens are scoped to a single workspace.
Least privilege, named accounts, mandatory MFA for production, quarterly access review, revocation within one working day of a role change. No one reads your data except on your support request or where security or law requires it.
Encrypted daily backups with 35-day retention, restores tested quarterly, documented objectives of RPO 24 hours and RTO 8 hours.
Sub-processors
AI clients you connect over MCP are not our sub-processors — they receive data only when you make a request from a client you configured with a token you created. We give 30 days' notice before adding any sub-processor that touches ingested Google data.
Data model and API
The schema is public. Everything the dashboard, the recommendations and the MCP endpoint read is here, so you can check any number we show you.
date · query · page
country · device
clicks · impressions
ctr · position
date · landing_page
channel
sessions · engaged_sessions
conversions · key_events
date · search_term
campaign · ad_group
match_type
impressions · clicks
cost_micros · conversions
The overlap join
t.clicks as paid_clicks, t.cost_micros/1e6 as cost
from ads_search_terms_daily t
join gsc_daily g
on g.tenant_id = t.tenant_id
and g.date = t.date
and normalise(g.query) = normalise(t.search_term)
where g.position <= 3.0
and t.cost_micros > 0;
This is the whole differentiator, and it is four lines of join condition. It only works because both tables are in the same store, under the same tenant, on the same dates.
REST API
Bearer-token auth with the same workspace-scoped tokens as MCP. Full reference and the backend implementation ship in the repository.