Web analytics

Zero-touch by default

Every app deployed on Buildfyio reports analytics automatically. The platform injects a ~1 KB tracker into HTML responses at the edge — server-rendered apps (Next.js, Astro SSR, anything in a container) and static sites alike. You deploy; the Analytics tab fills up. There is nothing to install.

What's measured

• Pageviews — including SPA route changes.
• Unique visitors — a daily-rotating anonymous hash; the same visitor cannot be linked across days.
• Top paths and referrers.
• Core Web Vitals — LCP, CLS, TTFB, FCP at the 75th percentile, scored against Chrome's thresholds.

Privacy

Whether that still needs consent is a decision for your privacy counsel, not for us: many GDPR/KVKK regulators accept cookieless, aggregate-only measurement without a banner, some do not, and your own privacy policy may promise more. From the site's point of view bfy.js is a third-party analytics script loaded from api.buildfyio.com. Configure your consent manager to treat it like any other analytics script — or turn the automatic injection off (below) and embed the snippet yourself once the visitor has chosen.

Manual embedding

Pages served outside Buildfyio (a docs site elsewhere, an embedded widget) can still report to your project with the one-line snippet from the Analytics tab:

<script src="https://api.buildfyio.com/v1/analytics/<project-id>/bfy.js" async></script>

The tracker is idempotent — if a page ends up with both the automatic injection and a manual snippet, views count once.

Turning the tracker off

Project Settings → Analytics → Inject the analytics tracker. Off, the edge route for the project's hosts loses its HTML rewrite (server-rendered apps) and the static publisher leaves your HTML exactly as built. Data already collected stays; a manual snippet keeps reporting. The edge picks the change up on its next reconcile (within five minutes); static sites apply it on their next deploy.

Platform operators can make the tracker opt-in for new projects with ANALYTICS_INJECTION_DEFAULT=off on the API; existing projects keep whatever they have set.

Content-Security-Policy

A page that enforces a strict CSP has to allow the API origin for the tag to load and to report:

Content-Security-Policy: script-src 'self' https://api.buildfyio.com; connect-src 'self' https://api.buildfyio.com

The edge does not inject into a response whose Content-Security-Policy header does not mention api.buildfyio.com (or a *.buildfyio.com wildcard): that page is served exactly as your app rendered it and nothing is counted, instead of a CSP violation on every navigation. Pages with no CSP header are injected as before. Two things the edge cannot see: a policy delivered with <meta http-equiv>, and a policy that only allows scripts through https: or * (treated as not allowing the tag). Static sites get the tag written into the HTML at publish time, where no header check is possible — with a strict CSP in _headers, allow the origin or turn injection off.

Server-Timing header

Opt-in, same card. The edge appends a Server-Timing header with two entries: edge;dur=… (milliseconds from the request reaching the edge until the response headers left) and origin;dur=… (your app's time to first header byte). It is added, never replaced, so entries your app sets stay and all of them show up in the browser's Network panel. Container apps only — static sites are answered by the edge itself.

Notes

• Only browser navigations are instrumented; API responses, SSE streams, and asset requests pass through untouched.
• A strict Content-Security-Policy must allow https://api.buildfyio.com in script-src and connect-src, or the edge skips the injection — see above.