How we measure AI activity

What counts as an “AI read”

We classify every request hitting PeerPush by user-agent and entry point. An “AI read” is any fetch of a PeerPush listing by an AI system, whether it loads the product page directly or receives the product inside a feed, list, or API response. It combines three categories:

• AI crawlers: training crawlers operated by model providers (e.g., GPTBot, ClaudeBot, PerplexityBot, Google-Extended).
• AI agents: browsing on behalf of a user via a chat assistant (e.g., ChatGPT-User, Claude-User).
• MCP clients: explicit tool calls into PeerPush's Model Context Protocol endpoint.

Search-engine crawlers (Googlebot, Bingbot) and analytics bots (Ahrefs, Semrush) are excluded; they are categorized separately and not part of the “AI” share.

The verb ladder: what we claim and what we never claim

Every published stat uses one of four verbs, each backed by a specific observable event:

• Read: an AI crawler, AI agent, or MCP client fetched the listing on PeerPush.
• Served: PeerPush delivered a product's data to an AI engine, through a feed, the API, or a direct page read.
• Indexed: a search-index crawler operated by an AI product fetched the listing repeatedly over time.
• Served live: the listing was fetched during a live, user-triggered AI conversation or tool call.
• Arrived from: a human visitor landed on the listing with an AI chat product as the referrer.

We never say a product was “cited” or “recommended” by an AI assistant. What a model says inside a private conversation is not observable from our side, and we do not publish claims we cannot verify from our own logs. Every claim is scoped to activity on PeerPush.

Where the numbers come from

All counts come from PeerPush's own first-party server logs: requests served by our infrastructure, classified at ingestion time. There are no third-party estimates, no panel extrapolation, and no sampling. If a number is shown, the underlying requests happened on our servers.

Honesty floors

Every stat has a minimum threshold below which it is hidden entirely. A per-product signal only appears once its volume, day-coverage, or cohort size clears the floor for that specific stat; category rankings additionally require a healthy cohort with broad AI coverage before any percentile is published. Below a floor we show nothing, not a zero, so small numbers are never dressed up as signal.

Positive-only policy

Public product pages only ever show stats a product has earned. There are no public shame metrics: no “not read by X” lists, no below-average badges, no absent-engine callouts. When a product has not cleared a floor, the section simply does not render.

Anti-abuse

Published stats are designed to be hard to inflate. Counts prefer distinct-day shapes over raw request volume, so replaying the same fetch thousands of times in one day does not move the number. When a product's recent AI activity spikes far beyond its own trailing baseline, its published stats are frozen at the previous values until the pattern normalizes and the anomaly is reviewed.

Platform totals, hub shape, and segment counts

Platform-wide totals are shown as real numbers: how many times AI systems read product data, how many upvotes builders have cast, how many countries see genuine human discovery.

The Signals hub lens pages publish shaperather than raw counts - share %, ordinal rank, relative bars, and change vs the prior window - which keeps the catalog's exact size off the public surface while still showing where attention is moving. Hub headline numbers appear only after a window has accumulated at least 50 distinct visitors; below that floor the page shows a “Calibrating” placeholder.

The per-segment discovery strips (below) do publish real segment-level counts, each gated by an eligibility floor so thin numbers are hidden rather than shown at zero. Human page-view figures are the one exception: they are rounded to two significant figures, so exact traffic can be cited without being reconstructed. A platform-wide total is never mixed into a segment strip.

K-anonymity floor

Public Signals surfaces never expose a named subject (a specific product, agent, category, or country) backed by fewer than 5 distinct visitors. Below the floor, the row is suppressed.

Privacy and redaction

• IP addresses are never stored. Only a salted hash is retained.
• Query strings, search terms, and prompt text pass through a PII redactor before publication. The redactor strips email addresses, phone numbers, OAuth-token shapes, and credit-card-shaped digit sequences.
• Anonymous-visitor identifiers rotate daily, so the same anonymous browser is intentionally unlinkable across UTC days.

How fresh is the data

Aggregations refresh on rolling schedules: short windows update every few minutes, longer windows on slower schedules. The “Data fresh as of…” timestamp on each Signals page reflects the slowest aggregation still feeding that page.

How each panel is computed

Discovery signals strips

Category, use case, audience, and the “best”, “top rated”, and pricing pages each show a compact strip of up to three facts about that segment, and product pages show the same kind of strip about a single listing. The mix is chosen for the page: base segment pages lead with AI attention next to community activity, “best” pages show human reach and builder momentum, “top rated” pages show the reviewer story, and pricing pages show how the segment is priced.

Below an eligibility floor a fact is hidden entirely rather than shown at zero, the strip stops rendering once fewer than two facts clear their floors, and no more than three are ever shown. Every fact uses the Signals verb ladder and never says a product was cited or recommended by an AI assistant; on segment pages nothing names or ranks an individual product. Each stat links to its exact definition in the glossary below.

What each signal means

Every stat in a Discovery signals strip carries a small “i” that links to its definition below. These are the exact meanings, grouped by what they measure.