Analytics

First-party analytics with a CNAME: what it fixes and what it does not

One DNS record moves your counter onto your own domain. What a CNAME actually does, the certificate and Cloudflare gotchas, and how to prove it worked.

AstrinaEditorial July 17, 2026 4 min read EN RU UK

If you have measured your gap and found that a chunk of your visitors never reach your analytics, the fix is a single DNS record. This is what first-party analytics means in practice, what a CNAME actually does, and where it gets fiddly.

Third-party and first-party, precisely

A request is third-party when the hostname it goes to is not the site you are on. Read example.com, and a script pulled from some-analytics.io is third-party. That hostname sits on public blocklists, so extensions drop the request before it is made.

Point that same script at stats.example.com and it is first-party. Same script, same data, same server behind it — but now the hostname belongs to your site, and a blocklist has no way to enumerate every subdomain of every domain on the internet. So the request goes through.

The mechanism is that plain. There is no clever evasion involved, and there is no need for any.

What a CNAME does

A CNAME is a DNS record that says "this name is an alias for that name". You create stats.example.com and point it at the collection host. When a browser resolves stats.example.com, DNS quietly follows the alias and returns the collection host's address.

So the browser believes — correctly — that it is talking to a hostname under your domain. The traffic reaches the analytics service. Nothing is disguised: your DNS says openly where the name points, and anyone can look it up.

In Astrina it is one record:

stats.example.com.  CNAME  s.astrina.io.

Then you replace the counter host in your snippet, and that is the whole job. The analytics settings generate the snippet with your own host already in it, so there is nothing to hand-edit.

The parts that catch people out

The certificate

Your visitors will load https://stats.example.com, so something has to hold a valid TLS certificate for that exact name. The collection host issues one automatically once the CNAME resolves — but that means order matters: create the DNS record first, then wait. Issuance is not instant and a certificate cannot be issued for a name that does not yet point anywhere.

Cloudflare's orange cloud

If your DNS is on Cloudflare and the record is proxied, Cloudflare flattens the CNAME: every resolver sees only Cloudflare's A records, and the alias becomes invisible from outside. This is normal and it works — but it means "my CNAME disappeared" is usually not a problem, and checking with dig CNAME will mislead you. Check whether the host actually answers instead.

Your own cache

A CDN or browser holding an old 404 for that hostname will keep serving it after the setup is correct. Any check you run should include a cache-busting query string, or you will spend an hour debugging a stale answer.

What this does not do

  • It does not bypass consent, and it does not touch Do Not Track. If you needed a banner before, you need one now.
  • It does not resurrect visitors with JavaScript disabled.
  • It does not make anything anonymous that was not anonymous before.
  • It does not help if your problem is bot traffic rather than blocked traffic — that is a different diagnosis entirely.

What it does is stop a hostname blocklist from silently deleting people who never asked to be deleted. That is all, and it is enough.

How to know it worked

Do not trust a green tick — including ours. Check the two things that matter:

  1. Load https://stats.example.com/a.js in a browser. It should return the script over valid HTTPS, with no certificate warning.
  2. Compare a day of pageviews against your access log again, exactly as before. The gap should narrow. If it does not, the counter is probably still pointing at the old host — check the snippet in your page source rather than in your settings.

The measurement is the proof. Everything else is a claim.

Astrina supports this on every paid plan and the setup lives in your site settings. If you have not measured your gap yet, start with why your analytics shows fewer visitors than your server logs. If you run client sites rather than your own, the agency view covers doing this across a portfolio.

Try it on your site

The core counter is free. Add your site and explore every feature.

← All articles

What this page answers

  • analytics
  • analytics guide
  • First-party analytics with a CNAME: what it fixes and what it does not
  • First-party analytics with a CNAME: what it fixes and what it does not guide
  • First-party analytics with a CNAME: what it fixes and what it does not explained
  • First-party analytics with a CNAME: what it fixes and what it does not tutorial
  • getting started with First-party analytics with a CNAME: what it fixes and what it does not
  • First-party analytics with a CNAME: what it fixes and what it does not best practices
  • First-party analytics with a CNAME: what it fixes and what it does not step by step
  • what is First-party analytics with a CNAME: what it fixes and what it does not
  • First-party analytics with a CNAME: what it fixes and what it does not for beginners
  • First-party analytics with a CNAME: what it fixes and what it does not checklist
  • First-party analytics with a CNAME: what it fixes and what it does not examples
  • why First-party analytics with a CNAME: what it fixes and what it does not matters