Analytics for builders

Install analytics and prove it works in one agent session

By Jonas Reed 路 Oct 20, 2026 路 8 min read

Why "it's installed" is the wrong finish line

Most small sites never get past the install. As of Oct 17, 2026, W3Techs reports that 43% of websites use none of the traffic analysis tools it monitors. Google Analytics is on 46.8%, and every other tool it lists is below 9%. That figure covers the tools W3Techs monitors, not every possible tracker, but it shows how often the step simply does not happen.

43%46.8%NoneGoogle Analytics

Source: W3Techs, Usage statistics and market share of traffic analysis tools for websites, Oct 17, 2026. Retrieved Oct 17, 2026.

The second failure is quieter. The agent says "done," the tag is in a file, and nothing was deployed. Or the tag shipped with a typo in the site key. Either way the dashboard stays empty, and you find out a week later when you go looking for numbers.

Peeko is built so that a wrong key is invisible from the outside. The ingest endpoint answers 204 to every well formed beacon, valid key or not, so a tracker can never leak whether a key is real. That is good for privacy and bad for self-checking: if your agent sends a test request and reports "204, success," it has proven that the network works and nothing else.

So the check has to be a read. The agent writes a visit, then asks Peeko for the visit back. If the same path comes back, the whole chain worked: the key, the endpoint, and the read path.

Before the session: one key, one command

Peeko is one script tag with a site key. It sets no cookie and needs no configuration once it is on the page. Everything else in this post is about getting that tag live and confirmed.

The one thing you do outside the session is create an API key. Open the API keys card under Your account at usepeeko.com/settings, name the key, and copy it. It is shown only once. Then connect your agent. For Claude Code:

claude mcp add --transport http peeko https://usepeeko.com/api/mcp --header "Authorization: Bearer mcpk_your_key_here"

For Codex:

codex mcp add peeko --url https://usepeeko.com/api/mcp --header "Authorization: Bearer mcpk_your_key_here"

For Cursor, Claude Desktop, or any client with a config file, the same server goes in as JSON. Cursor reads ~/.cursor/mcp.json for all projects or .cursor/mcp.json for one:

{
  "mcpServers": {
    "peeko": {
      "type": "http",
      "url": "https://usepeeko.com/api/mcp",
      "headers": { "Authorization": "Bearer mcpk_your_key_here" }
    }
  }
}

Start a new session after adding the server so the agent loads its tools. The key is a bearer token, and the server is scoped by construction to the sites of the teams you belong to, so the agent can only see your sites. It is read only except for one tool, create_site. The trial is fourteen days with no card, starts when you create your account, and covers one site.

A small paper airplane leaves a window of a tiny house and a lantern on a distant shelf lights up in answer, showing that a sent message was confirmed by a separate read.

The prompt

This is the whole prompt. Replace example.com and Example with your domain and name. The agent fills in the site key itself from list_sites or create_site.

Add Peeko analytics to this project and prove it is receiving data.

1. Call the peeko MCP tool list_sites. If a site for example.com is listed, use it. If not, call create_site with name "Example" and domain "example.com". Write down the site key.
2. Add this exact tag inside the <head> so it loads on every page, replacing SITE_KEY with the key:
   <script defer src="https://usepeeko.com/t.js" data-site="SITE_KEY"></script>
   In a Vite or React project, edit index.html. In a Next.js project, use the root layout and the framework's own way of loading an external script.
3. Do not install a package, add a cookie banner, or change anything else.
4. Deploy. If deploying needs my approval or a command you cannot run, stop and tell me the exact command.
5. Fetch the live homepage with curl and report whether the script tag is in the HTML.
6. Send one test beacon with the real key and an Origin header:
   curl -sS -o /dev/null -w "%{http_code}\n" -X POST "https://usepeeko.com/a" -H "content-type: application/json" -H "Origin: https://example.com" --data '{"k":"SITE_KEY","p":"/peeko-install-check","r":"https://example.com/","sw":1512,"sh":982,"cs":"light"}'
7. Call get_top_pages and get_live_now for the site. Report whether /peeko-install-check appears in either.
8. End with exactly one line: "PROVEN: /peeko-install-check appears in Peeko" or "NOT PROVEN: <what you saw>". A 204 alone is never PROVEN.

Each step exists for a reason.

  • Steps 1 and 2 use the same MCP connection for the site and the key, so you never copy a key by hand. create_site returns the site id, the public site key, and a ready-made snippet prompt.
  • Step 3 keeps the agent from "helping." The tag is one line, and a cookie banner is not needed because Peeko sets no cookie.
  • Step 4 is where most silent failures live. A file edited on your machine is not a page on the internet.
  • Step 5 catches the case where the edit never shipped. If your framework injects the tag at runtime, the raw HTML may not contain it even when everything works, so treat a miss here as a prompt to read step 7 closely, not as a final verdict.
  • Step 6 sends the key with an Origin header, the way a browser would. The Peeko install docs warn against sending your real key without an Origin header: it is refused and logged as a rejected request on your install card.
  • Step 7 is the proof. It reads the data back through a different door than the one the beacon used.
  • Step 8 forces a verdict. Agents tend to round "probably worked" up to "done," so the prompt bans the ambiguous ending.

What each check proves

CheckWhat a pass provesWhat it does not prove
Tag in the live HTMLThe deploy shipped the editThat the key is right
204 from the beaconYour network can reach PeekoThat the key is valid, since every well formed beacon gets a 204
Path in get_top_pagesThe key, endpoint, and read path all workThat the tag fires in a real browser
Your own browser visit in get_live_nowThe tag fires in a real browserAnything about crawlers

The strongest single check is the last row, because it covers the script itself. The beacon in step 6 stands in for the script so the agent can finish without a browser. If you want the browser proof too, open the live site in a normal tab and ask the agent to call get_live_now again. It lists visitors active in the last two minutes.

One trap: the install docs say that opening a site with ?me=1 on the end tags your browser as you, badges the visit "You," and leaves it out of the totals unless you turn on "Count my own visits" in site settings. Do not use ?me=1 for the proof visit. Use it afterward, once you have confirmed the install, so your own clicks stop inflating the numbers.

If the verdict is NOT PROVEN

Work down the list in order. Each item narrows the failure to one place.

  1. Tag missing from the live HTML, and your framework renders it at runtime. Ignore this one and go on.
  2. Tag missing and the framework serves static HTML. The deploy did not ship the edit. Ask the agent for the deploy command and the build log.
  3. Beacon returned something other than 204. The install docs say any other status means something between you and Peeko is interfering, such as a proxy or a firewall rule.
  4. Beacon returned 204 but the path never appears. Compare the key in the page source with the key list_sites returned. Because the endpoint returns 204 for a bad key too, a one character difference looks exactly like success. Check that the Origin header matches the site's domain.
  5. Everything matches and the path still does not appear. Load the live site in a browser without ?me=1 and call get_live_now again. If a real visit shows up, the install is fine and only the synthetic beacon was the problem.

This post does not report a measured success rate for agents on this task. The steps follow Peeko's documentation, and the one thing we can state from the product is that a read through MCP returns what the dashboard shows. If one of your steps behaves differently from what is described here, trust what you see in the read.

Doing the same check without MCP

Some agents and CI jobs have no MCP support. The command line needs no install, and npx @usepeeko/cli speaks the same endpoint an agent does, so a command and a tool call return the same numbers. Set the key in the environment and read the same data:

export PEEKO_API_KEY=mcpk_your_key_here
npx @usepeeko/cli sites
npx @usepeeko/cli live --site example.com --json
npx @usepeeko/cli pages --site example.com --range today --json

sites confirms the key works and lists what it can reach. live and pages are the CLI forms of get_live_now and get_top_pages. The --json flag prints the raw payload, which is easier for a script to test for the string /peeko-install-check. If you prefer to create the site from the terminal, npx @usepeeko/cli init --name Example --domain example.com creates it and prints the snippet.

What this check does not cover

The tag sees browsers. It cannot see AI crawlers, because crawlers do not run JavaScript. That traffic comes through a separate server side path: the @usepeeko/bot-track middleware is ESM only, needs Node 20 or newer, has zero runtime dependencies, and weighs under 3 KB gzipped. The agent prompt above does not install it, and a passing install check says nothing about crawler hits. If you want that data, the first 30 days of AI crawlers on a new site covers what to expect, and get_bot_summary reads the result once the middleware is in place.

Visits from ChatGPT, Claude, Perplexity, Copilot, and Gemini are different again. They are counted from ordinary page views by their referrer, with no middleware, so the tag you just proved is enough. Count visits from AI assistants by referrer shows how that split works.

Goals, funnels, and revenue are separate checks too. They are definitions you add after the install, and a goal written today counts over months before it was written, so there is no rush to define them during this session.

The test beacon leaves one real row behind: a page view at /peeko-install-check with example.com as its referrer. Tell the agent to expect it, or filter it out when you read your top pages. It is a small price for a proof that does not depend on a human clicking anything.

If you build with Lovable, v0, or Bolt, where the agent lives in a chat window rather than a terminal, the shorter version of this flow is in add analytics to Lovable, v0, or Bolt with one prompt. For a view of how server side counts compare with the scores some tools publish, see AI visibility scores vs server side counts.

The short version

Mint a key once. Connect the MCP server. Paste the prompt. Read the last line it prints. If it says PROVEN, the path you wrote came back out of Peeko, and the install is done. If it says NOT PROVEN, the list above names the one place to look first.