By Daniel Goodrich, Local Service Spotlight
We took the Google Analytics reporting agent we run for clients and moved it into the cloud as a hosted AI agent. Then we built a simple web form so a teammate can run it without touching any code.
It now connects to a client’s GA4 on its own, pulls the data, and writes a report a human reviews. It saves a copy to a shared folder and drops a link into a tracking sheet.
This article walks through what we built, the proof that it works, and the bugs that nearly stopped us. The hard ones only showed up once real people started using it.
The short version is simple. The agent works, it runs on Anthropic’s infrastructure instead of ours, and a reviewer runs it from a form on our own website. The only thing between a raw Google Analytics account and a plain-English report is a person clicking approve.
See What the Agent Does
Small business owners cannot read Google Analytics. They open GA4, see a wall of charts, and close the tab. Agencies burn hours every week turning that same wall into something an owner can use.
Our GA4 agent does that work. It reads a property, figures out what counts as a lead for that specific business, screens out spam, and writes a report the owner can understand.
We built it to handle any small business, not just one type. A router inside the agent adapts the analysis to the model: local service lead generation, e-commerce, audience building, membership, or donations. It never tells an owner their business is out of scope. The full discipline is written up in our guide to reading a small business’s GA4 correctly.
The method matters more than the model. Before it reports a single number, the agent confirms it is looking at the right, live property.
It separates the online action, meaning a form submit, a call click, or a booking, from the fulfilled outcome, meaning a job that actually got scheduled and paid. When a number swings, it decomposes the swing to find the real driver instead of guessing. Then it writes a draft for a human to review, and that discipline is the product.
Host the Agent in Three Pieces
Running this one client at a time inside a chat window does not scale. We wanted the agent to run on its own, on demand or on a schedule, without a person babysitting a browser. That meant three pieces.
The first piece is the connection to Google Analytics. We host a small server that speaks the agent’s tool language and talks to the GA4 API. It authenticates as a service account that impersonates our access account through domain-wide delegation.
In plain terms, we granted access once at the account level, and the agent can now read every property under it with no daily login and no token to refresh. That last part solved the problem that stops most people who try this. An agent that needs a human to log in again every day is not an agent.
The second piece is the agent itself. It carries a short set of standing rules and the full reporting method as an attached skill. The skill is the same standard operating procedure our team follows, written down so the agent follows it exactly.
The third piece is authentication. The secret that lets the agent read Google Analytics never sits in the agent’s configuration. It lives in a separate vault and attaches to each run, so secrets and instructions stay apart.
Prove It With American AF Dumpsters
We pointed the hosted agent at American AF Dumpsters, a dumpster rental company, and asked for a report comparing the last 28 days to the prior 28.
The agent made more than ten calls to Google Analytics on its own. It confirmed the live property and excluded an older dead one on the same brand. It routed the business as a local service with online booking and called the outcome leads, not conversions.
Then it found the real story. Website sessions had more than doubled, which looks like great news.
Instead of stopping there, the agent decomposed the jump and found that about three quarters of the extra traffic came from Facebook and arrived far less engaged than usual. Leads were actually down 31 percent.
It kept digging and found the more important problem. Among people who reached the booking page, the share who completed a booking fell from 6.2 percent to 2.9 percent. That is a broken booking flow, not a traffic problem, and a surface reading would have celebrated the spike and missed the leak.
The agent wrote all of this as a client-ready draft, kept the internal grading notes in a separate section, and labeled the whole thing a draft for human review. That is exactly what we want. We later ran the same agent for a residential painting client and it caught the same kind of problem, which we walk through in an anonymized case study.
Put a Form in Front of It
The Console is fine for our team, but we wanted people who do not live in the Console to run reports and leave feedback. So we built a thin web app on top of the agent’s API.
A reviewer opens a page on our own site, enters a client name and a GA4 property, and clicks run. The app calls the agent, waits while it works, renders the finished report, and collects a quick rating so we can improve the method. It saves every report as a document in a shared folder and drops a link into a tracking sheet.
The key design choice is that the app is a thin client. The API key that reaches the agent lives on the server, never in the browser, and the web page only ever talks to our own backend.
That is the pattern anyone should copy when they expose an agent to non-technical users. The interface is public. The keys are not.
Fight the Bugs That Almost Stopped Us
Meta articles are honest about the hard parts, so here are the ones that cost us the most time, in the order we hit them.
The first bug was a setup quirk. The guided setup wizard offered only one way to store the agent’s credential, and it assumed an interactive login, while our agent uses a fixed access token. We skipped the wizard and stored the token as a static bearer credential in the vault directly.
The second bug was worse and quieter. The wizard let us edit the agent’s configuration in a side panel and showed our full setup sitting there, but it never actually saved that setup to the agent.
We only caught it because the first real run behaved like a blank agent. We rebuilt the configuration in the agent’s own editor and saved a new version. The lesson is to verify what the backend actually stored, not what the screen shows you.
The next bug showed up when we wired the form to the API. The report kept coming back empty or truncated on long runs.
The cause was the order in which the agent’s events come back. The event list is oldest-first by default, so pulling one page of events on a long run gives you the early thinking steps and never the finished report at the end.
We fixed it by asking for events newest-first and taking the first real message, with the saved report file as a backstop. If you build on this API, learn that ordering before you lose an afternoon to it.
The next bug was subtle. The app kept declaring a run finished within seconds while the agent was clearly still working.
A freshly created session reports idle for a moment before it picks up the task, and we were treating that first idle as done. We fixed it by waiting until we had seen the run actually start, finalizing only when the session reported a real completed state, and continuing to wait if the report was still empty. Never trust the first idle.
The last bug was Google, not Anthropic. Saving the report as a document kept failing with a storage-quota error even though the folder had plenty of room.
Service accounts have no Drive storage of their own, so a file the service account creates in a normal personal folder has nowhere to live. We put the reports folder inside a Shared Drive, where storage belongs to the organization instead of the account. Anyone automating Google Drive with a service account will hit this exact wall.
None of these were flaws in the idea. Every one was plumbing between the agent and the outside world, and the agent produced correct reports the entire time. We wrote all of them into our runbook so the next agent we host skips them.
Run It on Your Own Account Now
Today a reviewer runs the agent from the form on our site, reads the draft, and approves it before anything reaches a client. Our team also uses the Console directly for one-off runs and debugging. Next we are wiring scheduled runs so a set of clients gets a fresh report every week with no one starting it by hand.
For partners who already work inside their own Claude, we also packaged the reporting method as a skill they can run against their own Google Analytics, with none of our infrastructure involved. Same method, their data, their account.
Protect the Method, Not the Agent
The agent is not the moat. The method is. The agent earns its keep because it enforces a discipline a rushed human skips.
Check the property. Separate the online action from the real outcome. Screen the spam. Decompose every swing. Never send anything without a review.
We wrote that discipline down, handed it to a hosted agent, and now it runs the same way every time, whether a teammate starts it from a form or a schedule fires it on a Monday morning.
The tools will keep changing, but the discipline is what I would stake our name on, and that is why we built the method first and the hosting second. If you want us to turn one of your repeatable processes into a hosted agent, or you want to test the GA4 agent on your own account, message me and we will build it with you. You can also read how BlitzMetrics builds AI agents, how we turned tasks into an AI-runnable skill library, and the system that documents itself to see where this agent fits. For the platform underneath it, read the companion guide on what Claude Managed Agents are.