[shrwnsan]

What problem does this solve?

The site currently measures traffic only through the self-hosted Plausible ingest. This adds Cloudflare Web Analytics as a second, zero-maintenance view of the same aggregate numbers, using the token from the Cloudflare dashboard for tailroute.app.

How does it work?

• Both pages (site/index.html, site/docs/index.html) load the Cloudflare beacon (static.cloudflareinsights.com/beacon.min.js) next to the existing Plausible tag.
• scripts/check-site.py enforced a strict subresource contract (same-origin or pulse.tailroute.app only), so the contract widens deliberately: FIRST_PARTY_HOSTS becomes ANALYTICS_HOSTS — pulse.tailroute.app plus static.cloudflareinsights.com, both cookie-free, aggregate-only analytics origins. Anything else cross-origin (fonts, ad scripts, other analytics SaaS) still fails the check, and the deploy workflow runs this check before syncing to gh-pages.
• The docs footer said "No trackers, no analytics on this page" — stale since the Plausible tag landed ([site] Embed self-hosted Plausible analytics #81) and more so now. It now reads: "Site analytics: cookie-free, aggregate-only (Plausible + Cloudflare)—the daemon doesn't call home either."

Privacy posture

Cloudflare's documented position: Web Analytics "does not collect or use your visitors' personal data", logs no query strings, sets no cookies, and does not fingerprint or track across sites. No consent banner is required. Both allowed origins are documented in one place (ANALYTICS_HOSTS) so the page's privacy promises stay auditable.

Note on the beacon token: it is public-by-design — it ships in the served HTML of every CF Web Analytics site and is not a credential. Worst case for a published token is a third party POSTing fake beacons to inflate the dashboard's numbers.

Breaking changes

None. The checker change ships in the same PR as the beacon — merging only the beacon would have failed the deploy check on main.

Manual testing

• python3 scripts/check-site.py → OK 9 checks
• tests/run-tests.sh → 465/465 (includes a new test pinning the beacon as allowed)
• After merge, verify the deploy lands and Cloudflare's Web Analytics dashboard starts receiving pageviews for tailroute.app

Related

Keeps both analytics sources. If Cloudflare replaces the self-hosted Plausible long-term, the follow-up is to drop the pulse.tailroute.app tag and shrink ANALYTICS_HOSTS accordingly.

[shrwnsan]

Review follow-up (the box's gh token lacked write access at review time, so this landed late):

• Verdict stood: strong approve — verified during review that the type='module' snippet matches CF's own loader form (module + SRI on the auto-injected sites), neither page ships a CSP needing an allowlist entry, and inline-css.py's region rewrite is link-only so the beacon survives deploys. CI green; merged.
• Two minors: the checker failure wording nit is in chore(checker): age-proof third-party subresource failure wording #85 (this box's commit missed the squash). The beacon-token note is now in this PR's body.
• Post-merge deploy verified: beacon.min.js confirmed live in the served DOM of https://tailroute.app.