which commit moved the metric: deploy-aware analytics

Here is a thing that happens to everyone who ships software. You open your analytics, a line has dropped, and you have no idea why. Signups are down 30% since last week. The chart is very confident about the drop. It has nothing to say about the cause.

So you start guessing. Was it a marketing thing? A seasonal thing? Did something break? You scroll through commits, you check the deploy log in another tab, you try to line up "the number fell around Tuesday" with "we shipped a few things Tuesday." It is detective work, and it is slow, and half the time you never actually find the culprit. You just wait and hope it recovers.

Every analytics tool leaves you here. Mixpanel, Amplitude, PostHog, GA4, all of them show you that a metric moved. None of them tell you which deploy moved it. And the reason is structural, not lazy: they have your data, but they have never seen your code. They are not in your repo. They do not know a deploy happened on Tuesday, let alone which commit it was.

the missing join

The fix is almost embarrassingly simple once you say it out loud: record a marker every time you ship, then line those markers up against the metric.

A deploy marker is just a timestamp with a bit of context: a git sha, the commit message, when it went out. You already have all of that; it is sitting in git log. The only thing missing is a place to put it next to your analytics.

smolanalytics records deploy markers and does the join for you. For each deploy, it compares the metric in the days after against the days before, and it leads with any ship that correlates with a real drop:

you ▸ did my last deploy move signups?
ai  ▸ signups -41% in the 3 days after a3f9c1 "tighten checkout validation"
      (was 22/day, now 13/day). significant given the volume, likely a regression.
      correlation, not proof, but that ship is the suspect.

That is the whole feature. You stop guessing which change broke the number, because the number tells you.

recording a deploy is one line

If your app deploys from CI, add one step after the deploy:

smolanalytics deploy   # records the current git HEAD as a deploy marker

That reads your HEAD sha and commit message and posts them. No SDK, no config beyond the host and write key you already have. If you would rather not add a CLI, it is a plain HTTP call:

curl -X POST $HOST/v1/deploys \
  -H "Authorization: Bearer $WRITE_KEY" \
  -d '{"sha":"'"$GIT_SHA"'","message":"tighten checkout validation"}'

In the hosted version, if you connected a repo, this is automatic: it syncs your commits as markers on its own, so the impact is there without you touching CI at all.

asking it from your editor

The part that makes this actually usable is that you never leave your editor. smolanalytics ships an MCP server, so your coding agent (Cursor, Claude Code, Windsurf, whichever you use) can query it directly. You register it once, then you ask in plain English:

did my last deploy move signups?

and the agent runs deploy_impact and reads you the before and after. Same for $pageview, or any error-shaped event, so you catch regressions the moment they show up instead of a week later when someone complains.

The important detail: the number you get in the editor is the same number the dashboard shows, byte for byte. Both are computed from the same deterministic report, and a CI test in the codebase asserts they can never disagree. So it is not a chatbot guessing at your data. It is a computed result you can trust, delivered where you are already working.

correlation, not proof

One honest caveat, and smolanalytics says it in the product too: a deploy lining up with a drop is a strong suspect, not a conviction. Two things can move at once. A marketing push and a bad deploy can land the same day. So it flags a ship only when the move is both large and backed by enough data on either side, and the copy always says "correlates with," never "caused by." It narrows your search from "everything that happened this week" to "these two commits." That is most of the work.

why this is worth caring about

The loop that every other tool leaves broken is: ship code, watch a number, notice it moved, guess why. smolanalytics closes it: ship code, and the analytics already knows what you shipped, so it can tell you what your change did. It is the one thing a data-silo analytics tool can never do, because doing it requires living where your code and your deploys are, not just where your events land.

If you have ever stared at a dropped line and thought "what did we change," this is for you. It is open source, you can self-host the single binary free, and the deploy-impact tooling is built in. Or use the hosted version and it wires the deploy sync up for you.