You open Google Analytics on a Tuesday morning. Traffic is up 14% over the last quarter. Good. Someone asks you what changed and you say — honestly — that you don't know. Probably the spring campaign. Possibly the press mention. Could be the algorithm update everyone was talking about in February. Maybe the homepage redesign. You'll figure it out later.
You won't figure it out later. Nobody figures it out later. By the time you have the uplift in your hand, the trail of decisions that produced it is gone. The page changes are scattered across a dozen branches. The bot crawls aren't logged anywhere you can see. The citation that started showing up in ChatGPT in week six was never linked to the article you rewrote in week three. The 14% is real. The story behind it is gone.
This is the actual problem with reports.
The two ways reports fail
Most reporting fails in one of two shapes.
The snapshot. A PDF arrives Friday morning. You skim the top three numbers. You close the tab. Tuesday you have a question — did our citation rank on Gemini move after we rewrote the comparison page? — and the answer is buried in last week's report, or three weeks ago's report, or it's not in any single report because the change happened across two of them. You'd have to dig. You don't dig.
The lagged metric. Your dashboard shows a number trending up. Wonderful. But the number doesn't tell you which input moved it, and by the time the number has moved enough to be visible, the inputs that moved it have piled up into a mess too tangled to attribute. SEO has this disease worse than almost any other discipline. AI visibility has it for the same reason: the feedback loop is long enough that human memory of "what did we actually do" can't keep up.
Both shapes have the same underlying defect — there's no continuous record of what changed, when it changed, who saw the change, and what happened next. So the question "why" can't be answered, only guessed at.
What we do instead
For every AI visibility monitoring client, we ship a private repo. Three kinds of thing get written into it, continuously.
Site changes. Every page edit you ship — title rewrite, paragraph added, schema updated,
llms.txt change — is in the git history with a timestamp and a diff. The change isn't just
that you made it. It's what specifically changed, down to the word.
Bot visits. Every time GPTBot, Google-Extended, PerplexityBot, or Bingbot hits your site, it's logged. You can see exactly when the model's crawler read the page you updated. Most clients are surprised how visible this is once it's in front of them — they'd assumed it was a black box.
Citation deltas. Every weekly scan captures what each of the three providers said about you,
which sources they grounded on, and how that changed since the previous scan. The deltas are written as their
own files — 2026-W18-deltas.md — so the change record is permanent, not overwritten by next
week's scan.
Three streams, same repo, same timeline. The "why" question stops being archaeology.
The chain you can actually see
A real shape that comes up, in plain English:
You rewrote the comparison page on the 12th.
Google-Extended crawled it twice on the 14th.
The 16th scan showed Gemini quoting two new sentences from the page in its answer to "X vs Y".
Citation rank for that query moved from #4 to #1 in the next scan.
Recommendation rank moved with it.
That's not a dashboard trend line. That's a causal chain you can name, that produced a metric you can defend, traceable to a change you actually made. Six weeks later when a sceptical boss or a non-technical client asks why the Gemini number is up, you have a sentence to give them, not a shrug.
Worth saying why that number matters in the first place. When your brand isn't in the model's output, the model still answers the question — it just answers it without you, frequently inventing details to fill the space where you should have been. That's the prior argument, written up at AI is making stuff up about your business →.
The interface is a conversation
The repo on its own is just files. The thing that makes it usable is the agent sitting on top of it.
You ask a question in the language you'd use to ask a colleague — "what did we change in the last month that moved anything on Gemini" — and the agent reads the actual data: the actual diffs, the actual crawler logs, the actual scan output. It comes back with the specific changes, the specific queries that moved, the specific evidence. Not a summary. The thing itself.
Test it out — the chat on this page knows everything about this site. Try asking it about pricing, about how the monitoring works, about which Cloudflare features we disabled and why. And it probably talks your language — ask in Afrikaans, French, Mandarin, Welsh, whatever, and it'll answer in kind. That's the same shape every client gets, scoped to their own data: their pages, their bot logs, their scans, their deltas — interrogable by whoever on the team needs to ask, in whatever language they think in.
The chat isn't a feature bolted on top of a product. It is the way you talk to your reports.
Why a repo
A note on the substrate, because it matters.
The data lives in git because git is the right tool for "things that change over time and you want a permanent, queryable record of every change". It happens to also be portable. You own the repo. If you ever leave us, the history comes with you — every scan, every diff, every delta — machine-readable, in a format any future agent can read. There's no dashboard to be locked out of. No CSV export to remember to download. No retention policy that quietly expires your historic data after twelve months.
This isn't a sales line. It's just what happens when the storage layer is a git repo instead of a SaaS database.
Real results, in plain English
The point of all of this is one thing: when the number moves, you should be able to say why without guessing, in a sentence a non-technical client or a sceptical boss would accept. Not "probably the spring campaign". The actual reason, with the actual evidence, traceable from change → crawl → citation → metric.
That's what monitoring should have been doing the whole time. Reports were always a thin substitute for it. Now there's no reason to settle for them.