Analytics

vanityURLs analytics runs inside the Cloudflare Worker. It does not require browser tracking JavaScript, cookies, or a visitor account.

Cloudflare Web Analytics and Real User Measurement (RUM) are not part of the vanityURLs baseline. Leave Cloudflare RUM disabled unless an operator intentionally wants browser-side performance telemetry outside the redirector’s server-side event model.

The Worker sends analytics with ctx.waitUntil().¹ Redirects and pages should continue responding even when the analytics provider is slow or unavailable.

Provider limits are account- and product-specific. Verify the current vendor documentation and the plan attached to the instance before enabling high-volume collection.

The Worker uses collection endpoints for runtime analytics. Treat management API keys, reporting APIs, helper scripts, and collection events as separate paths with separate limits and credentials.

References: Fathom API documentation, Umami sending stats documentation, and Umami Cloud API-key documentation.

Configuration Fields

Configure analytics with Worker variables in wrangler.toml and Worker secrets when a helper script needs an API token.

Events

Localized lookup pages use these public paths:

Scanner probes matched by the runtime blocklist return a plain 404 before analytics. Common PHP and WordPress probes should not pollute miss metrics.

Requests blocked by Cloudflare before the Worker do not emit vanityURLs analytics events. Use Cloudflare Security Events and Cloudflare analytics for traffic blocked by Access, WAF, rate limiting, bot controls, crawler controls, DNS, or TLS policy.

Cloudflare analytics surfaces are reference tools, not setup requirements:

• Security Events: traffic blocked before the Worker by WAF, rate limiting, Access, bot controls, or AI Crawl Control
• Workers analytics: infrastructure request volume, errors, CPU time, wall time, and duration
• DNS Analytics: DNS diagnostics when investigating routing or delegation issues
• Web Analytics / RUM: disabled by default and not planned for the baseline

Umami Payload

Umami receives pageviews as native pageviews. Redirect, miss, lookup, and normalized bot activity are sent as named events with structured event data.

Umami payloads include:

• website ID
• requested URL
• referrer
• first language tag from Accept-Language
• visitor user agent or a safe bot fallback user agent
• visitor IP according to UMAMI_GEO_IP_MODE

Non-pageview event data can include:

• event type
• slug
• target host
• effective lifecycle state
• schedule label
• redirect status
• redirect error or lookup result, when present
• country and colo from Cloudflare request metadata
• correlation ID
• requested path and query
• bot family, when detected

Fathom Payload

Fathom receives provider-native collection requests from the Worker. Pageviews are sent as pageviews; redirect, miss, lookup, and bot activity are sent as named Fathom events.

Fathom request fields include:

• site ID
• page origin
• page path
• referrer
• selected query and campaign parameters
• generated client ID for the collection request
• event name for non-pageview events
• event payload for non-pageview events

Fathom event payloads can include:

• event type
• slug
• target host
• effective lifecycle state
• schedule label
• redirect status
• redirect error or lookup result, when present
• country and colo from Cloudflare request metadata
• correlation ID
• requested path and query

IP Mode

UMAMI_GEO_IP_MODE controls whether the Worker forwards CF-Connecting-IP to Umami.

Fathom collection does not require forwarding CF-Connecting-IP from the Worker. The Worker sends provider-native Fathom requests with the visitor user agent when safe, and falls back to a generic Worker user agent for known bot traffic.