siteline Start free trial Log in

First-party analytics proxy

See your data

Ad blockers and some browsers treat siteline.tools/js/script.js and POST /api/analytics/event as third-party analytics. They drop the request. A first-party proxy serves those two paths from your hostname so the browser sees a same-origin script and a same-origin collect URL.

SiteLine does not manage a custom CNAME for you in v1. You configure reverse proxying on nginx, Caddy, Cloudflare, or Vercel. Copy-paste lives on /docs/proxy. This article is the privacy and product version: what a proxy changes, what it does not, and how it interacts with a cookieless tracker.

Events still go to SiteLine servers run by Aglet Technologies. A proxy is not EU hosting, not a cookie, and not a way to keep payloads in your database. Policy: /privacy. Tracking model: /docs/privacy.

What to proxy

Forward:

Then load:

<script
    defer
    data-site-id="YOUR_SITE_ID"
    data-endpoint="/api/analytics/event"
    src="/js/script.js"
></script>

Keep the analytics hostname allowlist on the hosts visitors actually see (your site, www, maybe app). If you only allowlisted the SiteLine origin, first-party pageviews will be rejected.

Pass X-Forwarded-For and X-Forwarded-Proto on the collect path so truncation (IPv4 /24, IPv6 /48) hashes the visitor, not your proxy’s IP. If every visitor collapses to one office NAT, uniques become nonsense.

What the proxy does not do

It does not keep data on your machine. nginx proxy_pass, Caddy reverse_proxy, a Cloudflare Worker, and Vercel rewrites all fetch SiteLine server-side (or from the edge) and return the response. Aglet still processes the event. Stripe and Cloudflare remain subprocessors of the product. If your proxy is Cloudflare, say so in the privacy notice — you have put Cloudflare on the client site’s request path as well as on siteline.tools.

It does not set an analytics cookie. Collect still uses credentials: 'omit' in the tracker. Same-origin does not magically enable a SiteLine cookie; we do not issue one. Do not invent a “first-party analytics cookie” in the banner because you proxied a path. See Cookieless tracking explained and Do I need a cookie banner for analytics?.

It does not make you Schrems-proof. EU analytics after Schrems: the importer is still Aglet Technologies. An EU origin that forwards to SiteLine is an extra hop.

It is not a managed CDN hostname. There is no analytics.clientsite.com CNAME we provision, no TLS we terminate for you, no dashboard switch. If the proxy breaks, collect breaks; that is your runtime.

Privacy notice language that stays true

Something like: “We measure traffic with SiteLine (Aglet Technologies). The script is loaded from our domain and events are forwarded to SiteLine. SiteLine does not set an analytics cookie. Visitor identifiers are daily hashes of truncated IP and user agent. Raw IP is not stored on the event.” Link /privacy.

If you already promised “no data is sent to third parties,” a proxy does not let you keep that sentence. SiteLine is a third party. First-party is a browser same-origin trick, not a legal entity trick.

Hostname allowlisting and bot filters still apply on our ingest. Flooding /api/analytics/event on your domain is still flooding us, with your origin in the middle.

When you should bother

Default third-party collect is simpler. Use it until blockers show up in the numbers (marketing sites with EasyList-heavy audiences, or docs that look like “analytics” to uBlock).

SaaS marketing teams: Privacy-first analytics for SaaS. Agencies rolling this out per CMS: Privacy-first analytics for agencies. The proxy is optional in both.

Plans stay $4.99 / $19.99 / $99.99 USD, 7-day trial, regardless of proxy. Analytics retention is still 13 months of raw events, daily totals while subscribed + 30-day grace; Search Console while the account exists. App cookies on siteline.tools remain session, CSRF, theme/sidebar — your proxy does not receive those.

Questions about a broken proxy_pass: [email protected]. Bring the config, not a “please CNAME us” feature request. That is v1.

FAQ

Not because of SiteLine: we still do not set an analytics cookie. Other cookies on that first-party domain are unchanged. This is not legal advice.

Can SiteLine issue a managed CNAME later?

Not in v1. Assume you own nginx/Caddy/Cloudflare/Vercel. Documented examples: /docs/proxy.

If the Worker runs on Cloudflare, is Cloudflare a subprocessor of ours or yours?

Both, in different roles. Cloudflare is Aglet’s subprocessor for the SiteLine app (email, often the edge). If you route collect through a Worker on your zone, Cloudflare is also your processor for that reverse proxy. Write both in the notice. Do not hide the SiteLine hop.