First-Party Cookies Still Need a Consent Decision
A durable misconception survives in otherwise careful teams: that consent is about third party cookies, and anything set from the site's own domain is housekeeping. It was a rough shortcut a decade ago. Modern analytics, A/B testing, and personalization tools mostly run first party now, partly because browsers squeezed third party cookies, and the law followed the function rather than the domain.
The test regulators apply asks what the cookie does and whether the user asked for the service it supports. Who technically set it barely features.
Sort by function, in writing
Strictly necessary covers load balancing, security tokens, the shopping cart the user is actively filling, and remembering a consent choice itself. The standard is narrow: the service the user requested cannot work without it. Analytics fails that standard by definition, since the site works for the visitor whether or not their visit is measured.
Write the sorting down per cookie, name, purpose, lifetime, and the reasoning. A table like that is the document an inquiry actually requests, and building it forces the discovery every team needs: cookies nobody owns, set by tools installed years ago and still firing.
The first party data still travels
A first party analytics cookie usually sends its data to a vendor platform. Under US state laws that can amount to sharing for cross-context behavioral advertising when the data feeds ad products, regardless of the cookie's party status. Contracts, opt out honoring, and Global Privacy Control handling attach to the data flow, not to the cookie's domain.
That is also why the consent tool's job is blocking behavior, not banner display. If the first party tag fires before a choice because it was classified as internal and exempt, the program has a hole exactly where modern stacks do most of their tracking.
Lifetime is part of the decision
Long lived first party identifiers, thirteen months and beyond, draw scrutiny that session cookies do not. Cap lifetimes deliberately, justify each long one, and let the consent renewal cadence match the longest identifier you set. A two year personalization cookie under a consent that is never refreshed is hard to defend as ongoing permission.
When in doubt, shorten. Almost no analytics or testing use case genuinely needs a multi year identifier, and the ones that claim to usually turn out to be defaults nobody questioned.
Related reading
These earlier guides cover connected questions in more depth: First-Party Cookies Still Need a Consent Decision, Consent Banners on Mobile: The Bottom Sheet Problem Nobody Tests, and Consent and A/B Testing Tools: The Variant Cookie That Fires Before the Choice.
Frequently asked questions
Are first-party analytics exempt from consent in the EU?
Generally no. Some member states have narrow audience measurement exemptions with strict conditions, limited purpose, no cross-site use, capped lifetime. Outside those conditions, analytics cookies need consent like any non-essential cookie.
Does server-side tagging change the consent requirement?
No. Moving collection server side changes the transport, not the processing. If the data identifies or singles out a visitor for analytics or ads, the consent and opt out duties travel with it.
What about a cookie that only stores interface preferences?
A preference the user actively set, language, display options, is usually treated as functional and often exempt, because the user asked for it. A preference inferred from tracking their behavior is a different matter.
How often should we re-audit our cookie list?
At least twice a year, and after any major tag or vendor change. Cookie inventories rot quickly because tools set new cookies in routine updates without telling anyone.