A first-party hostname is still their collector

What people mean by cloaking

A DNS CNAME from collect.yoursite.com to a vendor hostname, plus a TLS certificate (often a vendor-managed SAN) that makes the browser treat the request as first-party. Cookies that would have been third-party now look first-party. EasyList may not have the subdomain yet. The payload still leaves for an ads company. The address bar still says you.

This is not sGTM. There is no container you debug. There is no server you patch. The vendor terminates TLS or you terminate and reverse-proxy to them with their cookie semantics. Users and privacy tools still see the destination when they inspect certificates, CNAME chains, or the request body. Calling it first-party collection does not change the recipient.

Safari classified CNAME

ITP treated CNAME-cloaked first-party cookies as third-party-like: capped, expired, or ignored. Safari resolved the CNAME, saw the tracker host, and classified the subdomain. The cookie you thought would last as a first-party _ga analogue on collect.yoursite.com did not. This shipped years ago. Building a new CNAME in 2026 to dodge ITP is a design that Safari already answered.

Lists followed. Once a cloaked host is known, uBlock matches it too. You then have ITP classification plus EasyList, plus a certificate that must stay valid, plus a subdomain you must not abandon. The measurement gain lasts until the next classification pass. Plan for that, or do not do it.

Why it bites operations

Certificate automation and subdomain takeovers are now your incident. If the vendor's certificate process fails, collect.yoursite.com goes red for every user, not just the ones with blockers. If you delete the CNAME but leave NS dangling, someone else can claim the name. If you put the collector on a cookie domain that covers the whole site, a XSS on a forgotten subdomain reads _ga.

SOC2 questionnaires will ask who terminates TLS and where the data goes. Calling the cookie first-party is not an answer. The CNAME target is. Legal will ask whether the privacy policy names the vendor. If you hid the host to dodge a list, you probably also hid it from the policy. That is a worse problem than a blocked pixel.

sGTM is a different design

Server-side GTM (or a reverse proxy you understand, or your own backend CAPI) is first-party because you send the event. The browser talks to sgtm.example.com on infrastructure you run. Your server talks to google-analytics.com or graph.facebook.com. Safari's CNAME classification does not apply to a host that is not a CNAME to a tracker. EasyList may still list sgtm.example.com later if the path looks like a collector. Then you still have CAPI.

You can disclose vendors. You do not need to pretend facebook.com is you. Cookies you set on example.com are actually yours. You choose what to forward. You can strip PII before it leaves. That is the product. A CNAME that only changes the hostname on the same vendor JS is not that product.

What to validate

The browser URL, even on your subdomain, still has to be an absolute https URL with a host, no userinfo. If it is a GA4 collect-shaped path, v=2, tid G-, cid, and en still matter when the request is the collect transport. If it is a custom path you invented, Pixellint will not invent a vendor pack for metrics.example.com. Attribute the host or validate the upstream vendor URL your server emits.

Do not validate the CNAME target in isolation and assume the browser URL is fine. Certificates, HSTS, and mixed content fail on the name the browser uses. curl -sI https://collect.yoursite.com/g/collect?v=2&tid=G-XXXX&cid=1.1&en=page_view and the same path on the vendor host are two artifacts if both are reachable. Prefer one design: sGTM or native vendor, not both plus a CNAME leftover from 2019.

Check the artifact

Paste the pixel URL or JSON body into the playground. Same engine as pixellint validate. Nothing leaves the tab.