AI Agent Analytics: Measure Machine Traffic Without Pretending Every Request Is a User

A browser analytics tool usually starts with a client event and groups events into a session. That model is useful for human browsing, but the session boundary says little about an agent's job. One agent may fetch a single machine-readable file. Another may render a site, keep cookies, execute JavaScript, wait for approval, and continue later. Both are machine visits; their client behavior is different.

The server request is the dependable starting unit for public AI traffic because the server sees the request whether or not the client runs your analytics script. A request is still only an observation. It does not reveal the principal behind the agent, the task it was given, or whether it found a useful answer.

That distinction keeps the measurement honest:

• Requests show which public resources were served.
• A classified journey estimates related machine activity over a bounded window.
• A task needs an explicit outcome that your product can observe.
• A person or account needs authenticated context rather than an inferred identity.

Today, Pulse measures the first two layers, while authenticated product events and task outcomes belong in your application analytics.

The useful split is operational, not philosophical. Human browser traffic, user-directed agent traffic, scheduled automation, and discovery crawlers can all appear in the same access log. They carry different intent, but intent is rarely present in an anonymous request.

Start with three reporting buckets: likely human, likely AI-agent or machine traffic, and unknown. Split known indexing or training crawlers again when published identifiers and network evidence support it. The unknown bucket should remain visible because a new agent can use a generic HTTP client, while a human can browse through a datacenter or privacy proxy; either signal can defeat a rigid rule.

KISSmetrics makes a similar case for separating people, user-directed agents, and crawlers in its article on what to track for AI agents. In practice, those labels are evidence-backed classifications rather than ground truth about motive.

For that reason, Apostl Pulse uses heuristic classification. The dashboard is useful for estimating demand across public pages, but it cannot tell you which person, company, or exact model made a request.

Session metrics still describe what a compatible client did. They become misleading when a team reads them as proof of interest or success across mixed human and agent traffic.

Bounce rate is the easiest example. A machine can fetch one documentation page, extract the answer, and stop. The visit looks like a bounce even when the page did its job. Time on page has the opposite problem: a fast fetch may be successful, while a long delay may mean approval, a retry, a stalled tool, or nothing at all. Scroll depth only exists for clients with a viewport and a script that reports it.

Unique visitors, device, and geography also need restraint. Machine requests may originate from shared infrastructure, change IPs, omit cookie state, or present a generic browser User-Agent. Those fields describe the observed client and network; they do not establish a unique agent or its owner.

Keep session dashboards for human experience analysis. For mixed traffic, pair them with server-side AI-agent analytics from Pulse and label each chart by the population it actually measures.

A useful dashboard starts with a small set of metrics, each tied to a decision the team can make without pretending the classifier knows more than it does.

• Estimated active agent journeys over a bounded window. Pulse groups eligible requests for the same project, trusted IP, and full User-Agent until a 30-minute inactivity window expires. This is an operational estimate, not a count of unique people or models.
• Agent traffic grouped by one canonical public page. Compare estimated journeys and request volume on docs, pricing, security, comparison, API, llms.txt, and other public resources. Pulse uses origin + pathname, so query campaigns do not fragment one page into many rows.
• Machine-readable coverage on the pages agents request. Run a separate content inspection to check whether the pages with the most machine demand return useful content without depending on client-only rendering. Measure the public paths that matter instead of scoring the whole site as one number.
• HTTP blocks and failures. Review 403, 429, and relevant 4xx patterns in server or edge logs by the same traffic buckets. The current Pulse SDK excludes 5xx responses from eligible content analytics, so failure diagnosis still needs the underlying operational logs.
• Task completion. If an authenticated product can observe a bounded task, define its terminal event: a valid API call, a completed form, a retrieved artifact, or a handoff to a person. Do not manufacture completion from page depth.
• Agent-to-human handoff. When an authenticated account or explicit handoff event connects machine work to a person, report it as a product outcome. Anonymous public requests cannot support this attribution.

The first two metrics form the public-traffic baseline in Apostl Pulse. Connected projects expose that estimate in the Pulse analytics dashboard. Machine-readable coverage needs a separate inspection of the high-demand pages, while failures and business outcomes require server logs or product events owned by your application.

Trying to force every signal into one event schema produces confident-looking reports with weak provenance. Keep three layers and join them only when you have a real key.

The public edge should record eligible requests, canonical paths, methods, response status, duration, and the evidence used for traffic classification. The open-source, MIT-licensed Pulse SDK observes public GET and HEAD responses from the server runtime. It keeps APOSTL_PULSE_API_KEY on the server and sends the canonical page plus bounded request metadata to Apostl.

Inside an authenticated product, add an actor field only when the product knows whether a person or an agent performed the event. A principal should come from an account, token, delegated session, or another explicit relationship. Unknown is a valid value; inventing a visitor identity per request is not.

For product tasks, define the terminal state before collecting a funnel. An illustrative internal event can be as small as:

{
  "actor": "agent",
  "task_type": "docs_retrieval",
  "outcome": "completed",
  "principal_id": null
}

This is a product event pattern, not a Pulse payload. The separation matters because Pulse measures public traffic while your product owns authenticated identity and business outcomes.

Pulse is designed for the part of AI agent analytics that ordinary browser scripts miss: eligible public server traffic. It estimates active machine journeys and aggregates the canonical public pages they use over a 30-day view. Query strings, fragments, URL credentials, request bodies, cookies, and authorization headers are not sent. The page identity is the canonical origin + pathname.

The boundary is as useful as the data. Pulse cannot prove the exact model, person, or company behind a request. It cannot infer a purchase, qualified lead, task instruction, or successful answer from a page fetch. Auth and account routes, assets, mutations, and other non-content traffic are intentionally outside the eligible public-content signal.

Use the Pulse product page and its public product source to inspect the installation and privacy contract. Once a real event verifies the setup, review the connected project's analytics in the Apostl Platform dashboard.

The first report should be boring enough to trust. Review the public pages with the most estimated agent activity, compare them with the pages the business considers important, and inspect server logs for blocks or repeated failures on those paths. Then choose one concrete change: make a high-demand page render complete content, expose a missing machine-readable entry point, repair a failing response, or clarify an ambiguous document.

Watch the same paths after the change. A shift in requests is evidence of traffic, not proof that the content caused a conversion. If the product owns a task outcome, analyze that outcome separately and join it only through authenticated or explicit handoff data.

This cadence gives AI agent analytics a job: reveal where machines already spend requests, show where the public surface loses them, and direct the next inspection. Apostl Pulse provides the public-traffic baseline without turning a heuristic into an identity claim.

If you do not know which public pages agents use today, start there. Install the server SDK and verify one real request; that establishes that collection works on the deployed surface. Choose a bounded review period, record it, and compare the same period after a change instead of redesigning the site around generic bot lists or illustrative benchmarks.

The page ranking identifies where to inspect, operational logs explain blocks or failures, and authenticated product events prove task outcomes. Keeping those conclusions separate produces a useful action-result-limit chain: observed demand chooses the page, a bounded change addresses the evidence, and the follow-up report stays within what each signal can prove.

Explore Apostl Pulse for the setup, data boundaries, and open-source SDK. When the project is connected, use Pulse analytics to inspect the actual page mix.