anacraft — Google Analytics 4

⛏ craft

Ask GA4 in plain English.

Connects your assistant to Google Analytics 4 through an MCP server, so you can ask how your site is doing and get the answer from your own numbers. Its dashboard at anacraft.dev/app creates the property and hands you the tag; the CLI audits what it is measuring so you can fix what is wrong, and reads it back as a terminal dashboard.

anacraft.dev · Releases ·

craft dash --demo · osaka-jade · 132×52

Install

macOS / Linux

curl -fsSL https://anacraft.dev/install.sh | bash

Installs to /usr/local/bin when that is writable, otherwise ~/.local/bin — never with sudo. Set INSTALL_DIR to choose somewhere else:

curl -fsSL https://anacraft.dev/install.sh | INSTALL_DIR=~/bin bash

From source

cargo install --git https://github.com/mehfuzh/anacraft

Manual — grab a binary from Releases, extract it, and put anacraft on your PATH.

Quick start

anacraft with no command opens the dashboard — dash is the default. With no property saved it runs on synthetic data, so it works before you sign in.

# The dashboard, on synthetic data — no Google account needed

craft

Connect your GA4 property

craft login # OAuth sign-in craft props # list the properties this account can read craft use 1234567 # save it as the default

Same bare command, now against your property

craft

No property yet? Sign in at anacraft.dev/app, choose Create a new property and give it your site's URL. It creates the property and its web data stream and hands you the gtag.js snippet with your measurement id already in it, with a copy button — nothing to install. Paste it into , then craft use here and craft live to watch the first visit arrive. The dashboard is part of the Anacrafter Elite plan ($9.99/month, the same one craft mcp is on); the paywall comes before anything is created in your Analytics account.

Give it a domain that already has a property and it creates nothing — it finds that property and hands its tag back — so doing it twice is how you get the tag again, not how you end up with two properties splitting your traffic.

Rather stay in the terminal? craft configure yoursite.com does the same thing in one command, on the $2.99 Anacrafter plan, and saves the property as the default. It asks Google for permission to write to your Analytics account when you run it, never at sign-in; see docs/oauth-scopes.md.

The dashboard, on your own machine

craft serve is the page at anacraft.dev/app, run locally — for when you would rather sign in with the CLI's own credentials, or want to script against the same API.

craft serve          # opens a page: sign in, pick or make the property, copy the tag

craft serve --demo # the whole walkthrough on synthetic data, creating nothing

It listens on 127.0.0.1 and nowhere else, mints a bearer token it prints once, and answers a browser only from its own origin. The page is the first caller of an API the whole of which is documented at anacraft.dev/serve.html — so a script, an editor extension or another service can register a tag the same way. It creates the same property and stream the hosted dashboard does, through the same two Admin API calls — and it can throw a property into Google's trash the way craft delete --all does, asking for the id twice before it will.

It is part of the Anacrafter Elite plan, the same one craft mcp is on, so one subscription covers the tag and the assistant that reads the numbers afterwards. The command itself starts for anybody — the page is where you sign in and, if you need to, subscribe. craft serve --demo walks all of it and creates nothing.

One-shot reports

Not everything needs a dashboard. These print and exit.

craft overview --days 30   # headline metrics, deltas, achievements

craft pages # most-visited pages craft portals # where traffic arrives from craft realms # traffic by country craft live # who is on the site right now craft demo # render an overview from synthetic data

Two flags are global: --property queries a property other than the saved default, and --theme renders with a palette other than the saved one.

Piping the numbers somewhere

overview takes --format, so the same report a person reads as panels can also leave the terminal as data.

craft overview --format json            # one object, one line — for jq or a script

craft overview --format slack # a Block Kit payload, for a webhook

json answers in the same shape as the site_status MCP tool: labelled metrics with their unit, the previous period, the percentage change, the daily user series, and the achievements that fired. The window is reported as the first and last day the API actually returned rather than computed here — GA resolves last 7 days in the property's timezone, which is not necessarily this machine's.

slack wraps the same numbers as blocks. Both print the payload and nothing else, so a weekly digest is one cron line:

0 9 * * 1  craft overview --days 7 --format slack \

| curl -sX POST -H 'Content-Type: application/json' -d @- "$SLACK_WEBHOOK"

Neither format needs a subscription — they render a report craft overview already prints for free.

Claude Desktop

craft mcp --install           # write Claude Desktop and Smartloop configs

craft mcp --install --demo # ...pointed at synthetic data instead craft mcp --uninstall # take it back out again

Restart Claude Desktop and ask it how the site is doing. The block it merges in leaves any other servers alone:

{

"mcpServers": { "anacraft": { "command": "/usr/local/bin/craft", "args": ["mcp"] } } }

Needs craft login first and an active subscription — without either the server still starts and its tools say which one is missing, so the client never reports it as disconnected. craft mcp --demo runs on synthetic data without either. More in Ask an assistant.

Audit

Every other command answers "what happened". craft audit answers the question before it — is this property measuring the site at all, and is what it measured worth trusting.

craft audit                  # sixteen checks over the last 28 days

craft audit --fix # ...and apply the ones GA4 can fix itself craft audit --days 90 # a longer window craft audit --format json # the findings as one object, for a script craft audit --format slack # a Block Kit payload, for a webhook craft audit --demo # a synthetic report — no account, no subscription

It reads two APIs, because measurement and configuration fail separately. The Data API says how often purchase fired; the Admin API says whether anybody ever told GA4 that purchase was the point. A property can pass the first and fail the second for a year without anybody noticing, and that combination — traffic arriving, nothing marked as an outcome — is the most common thing this finds.

What it checks. Five things that make a number wrong:

• nothing recorded at all, which is a tag that is not installed or a property that is not the one the site reports to
• no web data stream, so there is no measurement id to put on a site
• nothing marked as a key event, or a key event configured and never fired — GA4 matches names exactly, so Purchase and purchase are two events and only one of them counts
• purchase arriving without its value, which makes every revenue, ARPU and ROAS figure on the property zero — including in any Google Ads account importing conversions from it
• enhanced measurement switched off at the master switch, so the stream's automatic events are configured, shown as on, and collected by nothing

Five that distort one:

• page views counted twice, which is what a gtag snippet left in the page beside a GTM tag that also sends one looks like from here: bounce rate near nothing, views per session doubled
• the site referring itself, which is a visit cut in half by a domain the cross-domain configuration does not cover
• a payment or sign-in page credited with conversions, because the return trip starts a new session referred by the gateway
• an event that stopped firing between this window and the one before it, which is a tag removed, renamed, or moved behind something that no longer runs
• outcomes arriving unmarked — sign_up firing a thousand times with nothing in GA4 saying it is the point, so no conversion report counts it
• measurement that is on and silent: the stream is configured to collect scrolls, site search, video or downloads and has recorded none of them for a month, which is the one check with no threshold to tune, because the expectation is Google's rather than ours

And five that are worth knowing before reading anything else: two names for one event, sessions GA4 could not attribute at all, a direct share high enough to suggest campaigns going out untagged, more than one site reporting into the property, and measurement the stream could be collecting and is not.

What `--fix` does. Most of what the audit finds is on the site, and no API can repair it — an event that is not being sent cannot be made to arrive by changing a setting. Two kinds of finding are the exception, and craft audit --fix applies them: marking outcomes the property is *already recording* as key events, and turning on measurement the tag on the site already supports — scrolls, outbound clicks, video, downloads. Site search and form interactions are reported and never written: those record what a visitor typed, which is a decision about a privacy policy rather than about whether the analytics are set up right. Both kinds of fix are printed under the finding that motivates them before the flag is passed, both are additive, and both are undone from the GA4 console in a click. Nothing in the fix path can turn collection off, lower retention, or change what the site sends. It needs Editor on the property; Viewer is enough to run the audit and not enough to fix it.

What it will not do. It reports a symptom and names the usual cause, never the other way round — "bounce rate is 1.2%" is something the API said, and "you have two page_view tags" is a guess. It cannot see inside a GTM container, so it finds the tagging bugs that show up in the data and not the ones that only show up in the container. And every check has a floor under it: a property with eighty sessions has no meaningful bounce rate and no meaningful direct share, so those checks report as not run rather than firing on noise.

Exit codes. 0 when the property is clean, 2 when it is not, 1 on an error — and with --fix, a finding that was just repaired does not hold the exit code open. The same convention craft watch uses, so a weekly audit into Slack is one cron line:

0 9 * * 1  craft audit --format slack \