First-party measurement after cookie consent

An honest cookie choice cuts the measurement most marketing dashboards were built on. That is the point. Third-party cookies and pixels that build profiles across sites need a yes. When that yes is a real choice — reject as easy as accept — some of your visitors say no. Then sessions, "conversions" and the remarketing lists someone still treats as a force of nature all drop.

Teams react badly to the drop. They turn on Consent Mode and call the model the truth. They move the same Google tag behind your own subdomain and say "now it is first-party". They install a light script that promises cookieless, then find in the network tab that IP, URL and a fingerprint still leave the house. None of that answers the question: what can you stand behind when someone said no?

This is an SEO and product question as well, not only a compliance question. If you tune headlines, CTAs and landing pages from the slice that accepted tracking, you are steering by the most agreeable visitors. The ones who said no are still on the site. They click, they scroll, they submit the form. You just do not see them — or you see a model guessing them. That is a different problem from a banner that fires too early.

We write this because "first-party analytics" has become a sales word stacked on the same stack. An honest setup is boring: you know which hit you send, on which domain, to which service, on which basis — and you can turn it off. Without that sentence you have a dashboard. You do not have measurement you can defend.

First-party, in the browser's sense, is something you set or read on your own site. A cookie on flaretech.dk, set by flaretech.dk, is first-party. A cookie set by a script from another eTLD, or a request that takes an id to a foreign dashboard, is not — even if you CNAME tag.example.com onto your zone. CNAME cloaking changes the label. It does not change who ends up with the profile.

That is why "we run GA4 first-party" is often a sentence that does not survive the network tab. You can set _ga on your own domain. The hit still lands at Google, with URL, user-agent, and whatever user-id and events you configured. That can be legitimate after a yes. It is not cookieless, and it is not data you own if you switch tools tomorrow. You own an export for as long as the contract and the export allow.

Measurement without cookies is a different contract with the visitor. No id in storage. No profile across visits. Typically: a pageview to an endpoint you control, aggregated, without a way to point back at the person. Server logs, a light first-party beacon, or a tool that refuses to store a client-id on purpose. You get trends: which pages, which referrers, coarse geography if you insist. You do not get remarketing, user-id trails, or "this session became a meeting three weeks later" unless you bind that yourselves in your own system after an action the visitor took.

That last part is the honest first-party core most teams skip: events you write yourselves when someone submits a form, books, or signs in. That is your database. It does not need a marketing tag. It needs the product to count what you actually want to steer by — and for you not to glue a Google id on afterwards "so we can see the journey". The journey after a no is not yours unless the visitor gave it to you in an action, not in a hidden pixel.

A no removes what needed a yes. Third-party pixels. Session replay. Most chat widgets that send page content along. GA4, if you chose that it should wait. Cross-site remarketing. The detailed "user journey" in a foreign UI. That should hurt a vanity dashboard. If it does not, something is still firing.

What you do not need to lose: that a page was served (your own logs). That a form was submitted (your backend). That a payment went through (your payments). That a campaign landing got a hit, if you count first-party and aggregated — UTM in your own table, not a Google click id you keep forever "because it sat in the URL". URL parameters are also personal when you glue them onto an identity.

The dangerous compromise is keeping a coarse pageview without a cookie and then still sending IP and the full URL to five vendors. Cookieless is not a free pass to export the request. Minimisation still applies. An honest cookieless hit is short: path, maybe referrer, maybe a coarse country code you look up yourselves and then drop the IP. Not a user-agent hash plus time plus screen that is a fingerprint in practice.

SEO teams need to be especially honest here. Search Console and your own server logs tell you what Google crawls and what you serve. They do not replace on-page behaviour. They are also not an excuse to set GA4 without a yes "because SEO needs bounce". Bounce in a marketing tool is not a ranking factor. Core Web Vitals you measure with field data you have a basis for — or with the lab you run yourselves. Do not mix those conversations.

On WordPress the typical lie is a plugin that says "anonymised analytics" and still fires a Google or Facebook request because someone pasted an ID into a field two years ago. Or a cookie plugin that hides the UI while header scripts in the theme run around it. First-party here starts with inventory: which plugins send what, before you talk about Plausible, Fathom or your own beacon. A new "GDPR-friendly" plugin on top of three old pixels is a fourth pipe.

On Next.js the typical lie is that you have control because you own the repo. next/script with afterInteractive and a GA id, a third-party embed in the layout, an analytics route that proxies to Google and is called before consent state is read. You can do it right: your own /api/collect that writes aggregates, a consent signal that gates the scripts you named, and product events in the database you already have. Control is an option. It is not the default just because the stack is yours.

Both stacks can run honest cookieless measurement. Both can run GA4 after a yes. Both can lie with a CNAME. Pick the tool for the question you want to answer in three months — "which pages are read" is a different job from "who should see an ad". You can often own the first. The second needs a yes and a vendor you can delete.

If you are considering a stack change to "get first-party analytics", be honest: you are changing where the script can sit. A Next.js site with the same GTM container is not a new legal basis. Change stack if you have other reasons too. Do not change because a slide said edge and your own domain make measurement invisible to the rules. The rules look at purpose and data flow. Not at your bundler.