Subject: How we track if an agent or a human buys after an Agent Observatory hop

We cannot read the chat where an agent tells a human to buy. That conversation never hits our servers or yours. What we can join is a hop we issued to a paid event you send back.

What a hop is
A hop is a 302 we mint when an agent (or a human the agent sent) requests one of our /go/{your-host}/{dest} URLs. The 302 lands on your site with a common UTM scheme:

  utm_source   = agent-observatory
  utm_medium   = agent
  utm_campaign = monid   or   ploid
  utm_content  = dest (home, cli, docs, …)
  utm_term     = channel (mcp, cursor, github, …)
  utm_id       = ao_ + 16 hex, minted only at that 302

Filter PostHog to utm_source = agent-observatory. That is the whole agent-observatory slice. Campaign splits the two of you.

Three paths after the hop

Path A — a human opens the hop
The agent pastes the hop URL. A browser follows the 302. Your HTML page loads PostHog JS. PostHog stores $utm_source and $initial_utm_source. Our first-touch snippet stores ao_hop for 90 days. Checkout copies ao_hop into Stripe (client_reference_id + metadata.utm_id) or into your paid event. You POST that sale to us with hop_id. We mark it hop-attributed. This is the only path that proves a human clicked a hop we issued.

Path B — the agent fetches, a human buys later on a clean session
Most hops are tool fetches of markdown, llms.txt, CLI docs, or APIs. PostHog JS does not run. No cookie is set on the human. If that human later buys from a normal visit, we cannot join the two. We still count the hop. We do not count a sale. Do not treat this as a failed conversion; it is unobservable.

Path C — the agent is the buyer
The agent keeps utm_id from the landing URL and writes it onto the API key, first paid run, invoice, or x402 metadata. The human never needs to click. You POST that paid object with hop_id. We mark it hop-attributed. This is how CLI / API / MCP purchases join.

How we tell agent-fetch from human click on our side
On every hop we classify request signals. We never store IP, raw User-Agent, query string, cookies, body, or prompts.

  Sec-Fetch-Dest: document     → likely a browser navigating (Path A)
  Accept: text/markdown|json   → likely an agent/tool fetch (Path B or C)
  curl / python / node / go    → agent fetch
  Chrome / Safari / Firefox    → browser navigation

Those classes sit next to dest and channel on the hop. When your sale carries the hop id, we can say whether that hop looked like a human click or an agent fetch. We still cannot see the chat in between.

What we need from you, once
1. PostHog JS on every HTML page we hop to.
2. identify() before checkout so $initial_utm_source survives to the buyer.
3. First-touch snippet (or the same cookies) on those HTML pages.
4. ao_hop copied into Stripe / paid-event metadata.
5. POST paid events to our sales API (invoice id + hop_id + amount + time). No email, name, card, or IP.
6. Server-capture of the query string on .md / .txt / API dests, or those hops will never appear in PostHog.
7. If signup 307s to WorkOS (Ploid login does today), persist utm_id in a cookie or WorkOS state before the redirect.
8. If the agent buys via CLI/API, write utm_id onto the key or first paid run.

Attribution we will report
  hop      = paid event carries a utm_id we minted
  utm      = paid event carries utm_source=agent-observatory for your campaign, but not the hop id
  unknown  = organic / other; excluded from hop → sale

Ratio = attributed sales / hops in the same window.

Live hop analytics
The client center Analytics tab shows every classified signal we keep on hopping agents for both sites: dest, channel, country, colo, continent, network family, UA family, language, Accept class, fetch dest, HTTP version, TLS, bot-score bucket, browser vs API kind, and a recent hop tape. Daily agent nicknames rotate and are not people.

Until sales are ingested, hop → sale stays 0.00%. Hops are already live.