Every integration sends its platform’s native log shape, and Rankly normalizes it to a single event format. These are the fields that drive your dashboard.

Core fields

FieldTypeDescription
tstimestampWhen the request happened (epoch ms or ISO 8601).
methodstringHTTP method, e.g. GET.
hoststringThe host requested, e.g. your-domain.com.
pathstringThe path requested, e.g. /products/widget.
userAgentstringThe raw user-agent string.
ipstringThe client IP, used for verification and origin mapping.
countrystringTwo-letter country code, when the edge provides it.
refererstringThe referring URL, used to detect LLM referrals.
statusnumberHTTP response status code.
bytesnumberResponse size in bytes, when available.

Identity fields (Web Bot Auth)

When a request is signed with Web Bot Auth (RFC 9421), these carry the signature so Rankly can verify it cryptographically:
FieldDescription
signatureAgentThe agent named in the Signature-Agent header.
signatureInputThe Signature-Input header.
signatureThe Signature header.

Derived fields

Rankly adds these after classification. You see them in the dashboard, not in what you send:
FieldDescription
Bot nameThe matched agent, e.g. GPTBot.
VendorThe company behind the agent, e.g. OpenAI.
CategoryThe kind of agent: AI bot, agentic commerce, search engine, scraper, and more. See Bot coverage.
PurposeFor AI bots: training, search-index, or live-fetch.
Verification tierVerified, unverified, or spoofed. See Verification.
Robots.txt violationWhether the request fetched a disallowed path. See Robots.txt violations.
Favicon requestWhether this request was a favicon fetch, used as a humanity signal.
Disguise flagIf a browser user-agent failed a coherence check, the reason why. See The humanity check.
You do not need to send every field. Send what your platform exposes; Rankly derives the rest (vendor, category, purpose, verification, robots compliance, humanity signals) from the user-agent, IP, referer, and signature.