The easiest platform for AI agents to use, measured

We measured how many HTTP requests an AI agent needs to go from no account to analytics that receives events, confirmed by the platform's own check. On AgentFirstStack it took 6 requests, and 5.9 and 7.3 seconds in two runs from a clean shell against production, with no person involved. For Google Analytics 4, PostHog and Plausible we counted the steps in their current docs instead of timing them, because each needs a person for part of the setup: an email code, accepting terms in a browser, or creating an API key in settings.

Measured and updated

Results

AgentFirstStackGoogle Analytics 4PostHog CloudPlausible
How we got the numberMeasured, 2 runsCounted from docsCounted from docsCounted from docs
Steps to receiving data6 HTTP requests7 steps4 steps (wizard path)5 steps
Steps that need a personNoneGoogle Account, accepting the terms, a Google Cloud OAuth client and consent for API accessSetting the password from the welcome email; creating a personal API key for the REST APIRegistering, the email code, adding the site (Sites API is Enterprise), creating an API key
Account created by APIYes, POST /v1/signupNo: the API returns a ticket for a terms page a person acceptsThrough the wizard, or a registered partner appNo
Agent confirms data arrivedRealtime of its own test event, then the setup checkRealtime report; collection "may take up to 30 minutes to begin"Automated browsers are dropped by defaultA testing tool sends test traffic once the snippet is added; "There are no delays with data"
Wall time5.9 s and 7.3 sNot timed: a person's part can't be measured fairly

Sources for the three other columns are listed under each tool, with the date we read them. Editing your code and deploying it come on top for every tool, and depend on your project.

Method

The finish line is the same for every tool: a site that exists, a tracking snippet the agent has, a pageview the platform received, and the platform's own confirmation of it. For AgentFirstStack we ran it; for the others we followed the official setup docs.

  • Counted: every HTTP request the agent sends to AgentFirstStack, from having no key to the setup check's answer. A realtime poll that came back empty would have counted too; both runs saw the pageview on the first poll.
  • Not counted: reading the manual (two GET requests: /llms.txt and the analytics manual), the agent's thinking, editing your code and deploying. Those vary by agent and host, and they're the same work with any tool.
  • Where: one macOS machine with bash, curl and jq, on one network, against the production API, on 6 November 2026 at 03:54 and 03:55 UTC. Times are curl's time_total per request; wall time was measured around the whole script, so it includes shell and jq overhead. Your network will give different numbers.
  • The pageview: the throwaway domain (afs-benchmark-<timestamp>.example.com) has no deployed page, so request 4 is the exact request the snippet sends when a page opens with ?afsa_debug=1: POST /e with dbg: 1 and a browser user agent. On a real site the agent opens the page in a browser (Playwright, Puppeteer or a browser tool) and the snippet sends the same thing. It's test traffic, kept out of reports.
  • "Verified": the setup check confirms the site exists and is receiving browser events. Domain verification, where verify finds the snippet on the live homepage, needs a deployed site, so it isn't in the count: on a real site it's one more request, POST /v1/sites/:id/verify.
  • Clean-up: each run ended with DELETE https://agentfirststack.com/v1/me, which answered "deleted": true. That request isn't counted.

The two runs, request by request

#RequestStatusRun 1Run 2
1POST /v1/signup2010.65 s0.54 s
2POST analytics /v1/sites2011.32 s1.23 s
3GET analytics /v1/sites/:id/install2000.34 s0.70 s
4POST analytics /e (test pageview)2020.96 s1.86 s
5GET analytics /v1/sites/:id/realtime?debug=only2000.36 s0.95 s
6GET /v1/setup?services=analytics2002.10 s1.86 s
Sum of requests5.73 s7.15 s
Wall time, whole script5.87 s7.28 s

What came back, in both runs: the signup answered with the key, the MCP config and next_steps; the site with its snippet and the next calls to make; realtime with "pageviews_last_30m": 1 and the pageview flagged "debug": true; and the setup check with analytics.site and analytics.receiving both ok ("1 event (1 from browsers, 0 server)"). The same check listed goals, the owner's email, a weekly report, alerts and the claim link as missing: those are the next steps of a full setup, not part of receiving data.

The script, so you can repeat it

Bash, curl and jq. It creates a real project on the hosted service and deletes it at the end. The hosted service allows 3 new accounts per hour from one network.

S=https://agentfirststack.com
A=https://analytics.agentfirststack.com
D=afs-benchmark-$(date -u +%Y%m%d%H%M%S).example.com
UA="Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/130.0.0.0 Safari/537.36"

# 1. Account and key
R=$(curl -s -X POST $S/v1/signup -H 'content-type: application/json' -d '{"name":"benchmark run"}')
K=$(echo "$R" | jq -r .api_key); ACCT=$(echo "$R" | jq -r .account_id)
H="Authorization: Bearer $K"

# 2. Site for the domain (the answer includes the snippet)
SITE=$(curl -s -X POST $A/v1/sites -H "$H" -H 'content-type: application/json' \
  -d "{\"domain\":\"$D\"}" | jq -r .site.id)

# 3. Install code for the framework
curl -s "$A/v1/sites/$SITE/install?framework=nextjs" -H "$H" | jq -r .snippet

# 4. The pageview the snippet sends from a page opened with ?afsa_debug=1
curl -s -X POST $A/e -H 'content-type: text/plain' -H "user-agent: $UA" \
  -d "{\"s\":\"$SITE\",\"n\":\"pageview\",\"u\":\"https://$D/?afsa_debug=1\",\"dbg\":1}"

# 5. Realtime, test traffic only (repeat until the pageview shows)
curl -s "$A/v1/sites/$SITE/realtime?debug=only" -H "$H" | jq '.recent_events'

# 6. The setup check for this site's analytics
curl -s "$S/v1/setup?services=analytics&domain=$D" -H "$H" | jq '{ready, checks: [.checks[] | {id, status}]}'

# Clean up (not counted)
curl -s -X DELETE $S/v1/me -H "$H" -H 'content-type: application/json' -d "{\"confirm\":\"$ACCT\"}"

To time it the way we did, add -o /dev/null -w '%{http_code} %{time_total}\n' to each request (keep the output of 1 and 2, which the next steps read) and time the whole run.

GA4, PostHog and Plausible, from their docs

We read each tool's current setup docs on 6 November 2026 and listed the steps in the order they give. Where a step can be done by API, we say what the agent needs for it.

Google Analytics 4

  1. A Google Account. "You must be signed in to a Google Account to open the property." (Set up Analytics for a website and/or app, as of 6 Nov 2026.) A person.
  2. An Analytics account, with a name and data-sharing settings. By API, accounts.provisionAccountTicket returns a ticket for a Terms of Service link; the person accepts there and is sent back to a redirect URI that "Must be configured in Cloud Console" (Admin API reference, as of 6 Nov 2026).
  3. A property: name, reporting time zone and currency, then "Select your industry category and business size" and how you intend to use Analytics. The Admin API can create properties with the analytics.edit scope.
  4. The terms: "accept the Analytics Terms of Service and the Data Processing Amendment." A person.
  5. A web data stream: the site URL, a stream name, enhanced measurement on or off. Also possible by API.
  6. The Google tag with the stream's measurement ID, in the <head> of each page. The agent can do this.
  7. Check: the Realtime report. "Data collection may take up to 30 minutes to begin."

For any of the API steps, the agent needs OAuth credentials for a Google Cloud project, which a person creates and consents to. Google's Analytics MCP server reads properties that already exist.

PostHog Cloud

  1. Account and project. The fastest path is the wizard: npx @posthog/wizard@latest --signup --email you@example.com --region us creates the account, provisions a project and installs the SDK (Wizard signup, as of 6 Nov 2026). The page recommends running it interactively; its --ci mode is "turned off in published builds".
  2. Set a password. "check your inbox for the welcome email and follow the link to set a password". A person.
  3. An API key for the agent. "Signing up this way doesn't mint a personal API key"; you create one from your project settings after logging in. A person. (Apps that register with PostHog as partners can create accounts and projects over OAuth with PKCE, after hosting a metadata document and a signing key on their own domain: Provisioning, as of 6 Nov 2026.)
  4. Check. The SDK's bot filter "also drops every capture when the browser looks automated", and Playwright, Puppeteer and Selenium match by default, so an agent testing with a headless browser has to override those signals first (Troubleshooting, as of 6 Nov 2026).

Plausible

  1. Register: name, email and a password; a 30-day trial, and "No credit card is required to sign up for the trial" (Register an account, as of 6 Nov 2026). A person.
  2. Verify the email: "enter the four digit code" from the verification email. A person.
  3. Add the site. In the dashboard; by API only with the Sites API, which "is an Enterprise plan feature", with a key Plausible issues on request. A site's domain "must be a globally unique, the request will fail if the domain is already taken" (Sites API, as of 6 Nov 2026).
  4. The snippet in the <head>. The agent can do this.
  5. Check. "Our testing tool launches automatically in the background" to send test traffic, with the result in a banner on the dashboard, and "There are no delays with data in Plausible" (Troubleshoot integration, as of 6 Nov 2026). For reading stats later, the agent needs a Stats API key, which "is a Business plan feature" (Stats API, as of 6 Nov 2026).

Where the others fit better

Being easy for an agent to set up is one criterion. These tools win on others:

  • Google Analytics 4, if you run Google Ads and want Google's own audiences and attribution, or your team already reports from GA4. Both can run on the same site, and AgentFirstStack can import GA4 history.
  • PostHog, if you want product analytics, feature flags, experiments and session replay in one product, and its wizard covers the setup well. See PostHog MCP compared.
  • Plausible, if people on your team will read the dashboard every day and want a simple, privacy-friendly one they may already know.

We wrote this benchmark about our own product. Our side is a script anyone can rerun; for the others we used their own docs and linked every claim. If a doc changes, tell us and we'll update the page.

FAQ

How many requests does an AI agent need to set up AgentFirstStack analytics?

Six, measured against production on 6 November 2026: signup, create the site, get the install code, a test pageview, realtime showing it, and the setup check confirming the site receives events. Two runs took 5.9 and 7.3 seconds. Editing the code and deploying the site come on top.

Why didn't you time GA4, PostHog and Plausible?

Each one needs a person for part of the setup, such as an email code, accepting terms in a browser or creating an API key in settings, so a timing would measure the person. We counted the steps their own docs describe instead, and linked each doc.

Which other tool comes closest?

PostHog. Its wizard (npx @posthog/wizard@latest --signup) creates an account and a project and installs the SDK from one command. The person then sets a password from a welcome email, and a personal API key for the REST API is created after logging in.

Can I rerun the benchmark?

Yes. The script is on this page and uses only curl and jq. The hosted service allows 3 new accounts per hour from one network, and the script deletes its throwaway project at the end with DELETE /v1/me.

Does the test pageview show up in my reports?

No. A pageview from a page opened with ?afsa_debug=1 is test traffic: stored, visible in realtime?debug=only, left out of every report and deleted after 7 days.

Product names belong to their owners. AgentFirstStack isn't affiliated with Google, PostHog or Plausible.