What is Page views?

Page views tells you who reads your marketing site and how that top-of-funnel traffic turns into agent purchases. Your site reports each page-content request to ZeroClick, which classifies the visitor against the same agent registry your storefront uses, so a page view of your pricing page and a later purchase through your storefront line up as one journey. It is a separate capability from Agentify, enabled on its own. Agentify changes what an agent receives (markdown instead of HTML); Page views only observes the request and never changes the response. Turn on either, both, or neither. Report page views one of two ways: mount the SDK middleware in your site so every page request is reported automatically, or send each view to the REST endpoint from any stack.

​

What is reported

A page view is one GET request to a page-content path. Requests for assets (anything whose final path segment has a file extension, like /_astro/app.css, /favicon.ico, or /logo.png) are skipped, as are redirects. Everything a reader actually loads to view a page is reported: your pages for people, and the same pages for agents and crawlers. There is no user-agent gate at capture. A crawler, an unknown agent, and a browser are all reported and told apart afterward, so a new agent shows up in your numbers without any change on your side.

​

How a viewer is classified

The visitor’s user-agent, Accept header, and IP are read to classify the request, then discarded. What is stored is coarse and non-identifying:

• Client kind: agent, browser, or other.
• The agent, when one is recognized: its registry slug (gptbot, perplexitybot, …) and operator (OpenAI, Perplexity, …), plus a coarse agent type.
• A user-agent family and the registry version that classified it, so history can be re-bucketed when the registry improves.

No raw user-agent or IP is ever stored. Each view carries the same anonymous viewer id your storefront traffic already does (a hash of the visitor’s IP and user-agent), so a page view, a later storefront visit, and a purchase from the same client line up as one journey, without either side ever holding an address. Two coarse context signals ride along when the edge exposes them: the visitor’s country (from Cloudflare’s cf-ipcountry, clamped to a 2-letter code) and the referrer host, the referring domain only, never the full referrer URL, so a referrer’s own path or query never leaves the visitor’s site. Both are optional and hold nothing that identifies a person.

​

Journey stitching

Beyond the anonymous viewer id, a page view can carry two fields that describe the agent’s read of the page, not just the client behind it:

• representation: whether this request was served as plain html or agentified markdown. The SDK middleware reads it from the response content-type, so you can segment journeys by whether the entry actually got the agent experience.
• journeyId: a reading-chain id that stitches this page view to the agentified read it belongs to. When Agentify serves an agent markdown, it attaches a journey id to that response; if Page views is mounted as the outer layer, it forwards that id on the view. The marketing view and the agentified read then line up on one journey.

Both are optional and present only when the machinery that produces them is running. representation is filled whenever the middleware can see the response. journeyId appears only when Agentify attached one: Page views without Agentify simply reports no journey id, and Agentify without Page views attaches a journey id that nothing reads. They come together only when Page views wraps Agentify, so the outer view observes both the agent’s request and the journey id on its response. The SDK middleware shows that wrap in each language.

​

Two timestamps

Each view carries two clocks, so you can measure delivery lag and trust the right one:

• captured_at: when your edge observed the request. Present only when your reporter sends it; it is never invented.
• received_at: when ZeroClick received the beacon. This is the authoritative time.

​

The Page views key scope

Reporting authenticates with an API key carrying the page-views:write scope. Mint one in the dashboard under Settings → API keys: create a key and enable the Page views group’s Write toggle. The scope grants POST /v1/page-views and nothing else, so the key can live on your marketing site’s edge without exposing your catalog, usage, or Agentify APIs. A key can carry both page-views:write and agentify:convert when you run both from the same edge, or just one.

​

Next steps