TL;DR: I connected my Matomo analytics to Claude by building a lightweight MCP server that wraps the WP-Matomo REST API. The result is not a smarter dashboard — it is a shorter path from data to decision. In one session, the connection surfaced three improvements I would not have caught in a normal analytics review: a meta description fix, a missing internal linking structure, and a content gap. The limitations are real, but the shift from reporting tool to decision layer is genuine.
Connecting analytics to an AI agent does not just save time. It changes how you think about decisions.
I built a custom MCP server connecting my Matomo analytics — running on douli.com via the WP-Matomo WordPress plugin — directly to Claude. The point was not to replace my dashboard. It was to close the gap between seeing a problem and acting on it, without losing context to a tool switch.
What it actually enabled
The test was a content audit. I asked Claude to pull my top pages by traffic, flag articles with high impressions but low click-through, and identify gaps in my product ownership cluster.
Three things came out that I would not have caught in a standard analytics session.
My highest-traffic article had strong search visibility but a click-through rate that did not match its position. That is a title tag and meta description problem, not a content problem. I updated both in the same conversation, without opening a separate tab.
My prioritisation techniques cluster was getting early traction from search and AI referrals — but the five articles in the cluster were not linked to each other. The data surfaced the structural gap. Claude implemented the fix: a hub-and-spoke internal linking structure built in the same session.
ICE scoring appeared in my hub article on prioritisation but had no standalone article, despite MoSCoW, Kano, WSJF, RICE, and user story mapping all having one. I spotted the gap because I was looking at the cluster as a whole. The ICE article was drafted and published before the session ended.
Individually, each of these is simple. What changed is that I saw them together — traffic, structure, and content gaps — in one context. That is the real shift: not smarter answers, but a shorter path to the right questions.
The value is not that the AI can answer questions about your data. It is that having the data in the conversation changes which questions you think to ask.
What the setup is
Matomo runs on my WordPress site via WP-Matomo, which exposes a REST API returning the same data as the dashboard — visits, top pages, referrers, keywords, device breakdown. The MCP server is a small Node.js script that follows the Model Context Protocol spec — an open standard that defines how AI agents interact with external tools. It translates Claude’s tool calls into authenticated API requests and returns structured data mid-conversation.
That is the full architecture. The practical detail for replication is in the last section.
Where it breaks down
Being precise about the limitations matters here, because this is a working arrangement, not a polished product integration.
The MCP server does not persist between Cowork sessions due to container isolation. Each session, the connection is re-established via direct API calls. It works, but it is a workaround. A self-hosted or cloud-deployed MCP endpoint would solve this properly.
The WAF on my shared hosting rate-limits rapid API calls aggressively — two consecutive calls within seconds returns a 429. Spacing them 30–60 seconds apart is manageable conversationally, but it rules out any automated batch processing.
And the obvious constraint: the AI still needs to be pointed at the right questions. It removes friction between insight and action. That is genuinely useful — but it is not the same as judgement.
What this means if you are a PO
The pattern is not specific to Matomo. Any analytics tool with a REST API can be connected the same way. What changes for a PO is the cost of curiosity — and the consequence of that is more significant than it first sounds.
When the friction between a question and its answer approaches zero, you validate assumptions faster. You reduce the gap between hypothesis and action. Analytics stops being a reporting function you visit once a week and becomes a decision layer you use in the moment.
The workflow becomes: observe, ask, decide, act — in one place. When your time budget for analytics is 20 minutes a week, that compression does not just make you faster. It changes what you actually do with the data.
How to build it
If you run Matomo via WP-Matomo, the REST API is already available at /wp-json/matomo/v1/api/processed_report. Authenticate with a WordPress Application Password. The Matomo Reporting API documentation covers all available modules — visits summary, top pages, referrers, keywords, device breakdown, goals.
The MCP server is a Node.js stdio process. Define tools that correspond to the API calls you want Claude to make, handle the authentication, and return structured JSON. No framework required — the protocol is simple enough to implement from scratch in an afternoon.
The harder part is usually getting Matomo running reliably in the first place. Once the data is there and the API is accessible, the MCP layer is the straightforward part. Getting the rate limiting right on shared hosting is the less obvious constraint.
About Delphine — Delphine Ragazzi is a Product Owner with 20 years in digital analytics, CRO, and product delivery. She writes about product decisions, data, and AI at douli.com.
