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.

​

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