How we see AI agents, and how we connect them to revenue
Four mechanisms, explained in plain english, including exactly what the collector sends and what it refuses to. If you only read one section, read what the collector sends.
The problem
AI agents read your website. ChatGPT, Claude, Perplexity, and a dozen crawlers behind them. They pull your pages, decide whether you're worth recommending, and answer someone's question using what they found.
You see none of it.
Your analytics runs as JavaScript in a browser. Agents don't run JavaScript, so the tag never fires and the visit is never recorded. The person who asked the question usually doesn't click your link either, because they already got their answer in the chat. When they show up later, they arrive with no referrer and land in your reports as "direct."
Real traffic, real influence, no record of either.
1. We watch from the server, not the browser
You add one line to your app, point your hosting logs at us, or put a small proxy in front of your site. There is no script tag, because a script tag cannot work here. Every request gets checked against a list of known AI agents, and when ChatGPT reads your pricing page that gets written down.
The agent list lives on our side, not in your code. New agents appear constantly and the ones that exist change their signatures. Keeping the list server-side means you get new agents without reinstalling or redeploying anything. The piece running on your infrastructure stays deliberately dumb: it reports what it saw and we do the interpreting.
What the collector actually sends
This is the part worth being specific about, because "install our code on your server" is a real ask. Here is the entire payload.
| Field | What it is | Example |
|---|---|---|
actor | The agent's name, resolved to something readable | OpenAI GPTBot |
actorType | What kind of client it is | assistant, crawler, unknown_machine |
surface | What kind of resource was asked for | llms_txt, well_known_endpoint, content |
interaction | What happened | llms_txt_requested, page_requested |
path | The page, with the query string already stripped off | /docs/quickstart |
httpStatus | What your server answered, when we can see it | 404 |
What it never sends
- IP addresses. Not collected, not sent, not stored.
- The raw user-agent string. Only the resolved name leaves your server, so nothing else riding in that header goes anywhere.
- Query strings. The path is split on ? before the payload is built, so session tokens and parameters in URLs can't leak.
- Cookies, request bodies, headers, or anything at all about your human visitors on normal pages.
You don't have to take our word for any of this
The collector is MIT-licensed and public. It's a few hundred lines of unminified, commented JavaScript. You can read the whole thing in five minutes and confirm every claim on this page, which is the only reason you should believe any of them.
Three more properties that matter when the thing is running in your request path:
- It can't slow you down. The send is fire-and-forget with a 1500ms abort. A failure on our end never surfaces to your visitor.
- No key means no-op. With nothing configured it returns immediately and your app behaves identically. Installing before you finish setup cannot break a deploy.
- Only GET and HEAD are examined. Form posts, API writes, and checkout calls are never looked at.
2. We notice what agents asked for and couldn't get
Because the collector can also see what your server answered, a request that came back 404 shows up as a gap. An agent asked for your /llms.txt eighty-six times and it doesn't exist.
That isn't an error to clean up. It's a list of pages you should go make, written by the agents that wanted them.
3. We test whether agents actually pick you
This part has nothing to do with your traffic. We ask the major AI models the kind of question your buyers ask, worded without any brand names. Something like "what should I use to send transactional email." Then we count how often you get named and how often your competitors do.
That number is your Pick Rate, and it answers a different question from your reads. Reads tell you agents are looking at you. Pick Rate tells you whether you make it into the answer. Plenty of tools get read constantly and recommended never.
4. We connect the reading to the money
Two things happen days apart and nothing obviously connects them. An agent reads your page. Later, a person signs up. Our job is to link those, and we do it three ways.
Confirmed: a tagged link
You hand agents links with a tag on the end, like ?via=mcp. When someone arrives on one, we drop a first-party cookie that remembers where they came from. When that same browser signs up, the cookie is still there and the chain is unbroken. No guessing.
Likely: the referrer
Sometimes a person clicks straight through from chatgpt.com and their browser tells your site where they came from. We record it the same way. Slightly weaker, because referrers get stripped by privacy settings and links get shared around.
Inferred: the timing
Nobody clicked anything. The agent read your page, gave the person an answer, and three days later they typed your name into a browser and signed up looking like they came from nowhere.
We line up the two records. Agents were reading these pages in this window, and this signup arrived with no other explanation. We say the two are probably connected, and we mark it as an estimate.
How the identity part works
The cookie starts anonymous. It's a random ID that remembers where a visit came from and nothing else. When the person creates an account, we tie that random ID to the real user, which is the moment an anonymous visit becomes a known customer. If you send us an email address to make that link, it's hashed on the way in and the raw address is never stored.
First touch wins. If four agents read your page before someone signed up, credit goes to the first one. The first one is what put you in the conversation.
Why we show you our uncertainty
Every conversion carries its label: Confirmed, Likely, or Inferred. We could average those into one confident-looking number and most tools would. We'd rather you know which conversions you can take to a budget meeting and which ones are our best read of the evidence.
If a number can't survive someone asking "how do you know that," it shouldn't be reported as though it can.
Where this doesn't work
Anywhere you can't run server-side or edge code. Shopify storefronts terminate at Shopify's own edge and refuse a third-party CDN in front of them. Webflow, Wix, and Squarespace can't run server code at all. Any client-side tag is a dead end here by definition, for the same reason your current analytics is blind.
If your host gives you access logs you can paste one and get most of the picture with nothing installed. If it doesn't, this measurement isn't available to you, and we'd rather say that than sell you something that quietly records nothing.
Questions
Why can't you just use a script tag like every other analytics tool?
Because AI agents don't run JavaScript. A browser snippet only executes in a client that executes JavaScript, and an agent fetching your page is not one. The tag never fires, so the visit never appears. This isn't a preference or a design choice we made, it's a property of how agents fetch pages. Server-side is the only place the request is observable at all.
What does the collector actually send?
Six fields: the agent's resolved name, what kind of client it is, what kind of resource it asked for, what happened, the path with the query string stripped, and the response status when we can see it. No IP address, no raw user-agent string, no cookies, no request body. The collector is MIT-licensed and public, so you can read the whole thing rather than take our word for it.
Does it slow my site down or risk breaking it?
No. The send is fire-and-forget with a 1500ms abort, so a failure on our end never reaches your visitor. If no key is configured it's a no-op and your app behaves identically, which means installing it before you've finished setting up can't break a deploy. Only GET and HEAD requests are examined, so form posts and API writes are never looked at.
Is my human traffic being sent to Pickrate?
No. A request from a browser to a normal page classifies to nothing and is never sent. It isn't filtered out later on our side, it never leaves your server. The one exception is agent-specific files like /llms.txt, which are recorded whoever requested them, because knowing who asked for those is the entire point of having them.
How can you claim an AI agent drove a signup when nobody clicked anything?
Sometimes we can prove it and sometimes we're estimating, so we tell you which. A tagged link that survives to signup is Confirmed. An AI referrer is Likely. A timing correlation between agent reads and a signup with no other explanation is Inferred. You get the label with every conversion instead of one number with the uncertainty hidden inside it.
Where does this not work?
Anywhere you can't run server-side or edge code. Shopify storefronts terminate at Shopify's own edge and refuse a third-party CDN in front. Webflow, Wix, and Squarespace can't run server code. For those, paste an access log if your host gives you one, or accept that this particular measurement isn't available to you. We'd rather say so than sell you something that quietly records nothing.
See it on your own site
Paste a chunk of your access log into the scanner. No account, nothing stored, and you'll see which agents crawled you, what they read, and what they went looking for and couldn't find.