Emit a server-set first-party identifier the brand controls, so the customer can be recognized after Safari ITP, third-party cookie deprecation, and the next round of browser changes still to come
The third-party identifier era is ending in slow motion. Safari's Intelligent Tracking Prevention caps third-party cookies and clamps first-party cookies set via document.cookie to seven days. Chrome's third-party cookie removal has been promised, paused, and rescheduled enough that a competent stack stopped relying on it years ago. Firefox blocks third-party storage by default. The cumulative effect is that the identifier the brand used to recognize its visitors across sessions has been getting flakier each year, and the stack that depends on it has been losing visibility without anybody flipping a switch.
The post-cookie identifier the brand controls is a first-party identifier emitted by a server the brand owns, set as an httpOnly cookie scoped to the brand's domain. The browser treats it as first-party storage with the longer lifetime that affords, the server controls the generation logic and the rotation schedule, and the brand can disclose what the identifier does and why because the brand is the one issuing it. The recipe is medium-high readiness because the technical work is straightforward but the disclosure, retention, and downstream-consumer migration are real organizational efforts.
This recipe builds the emission path, the graph integration, and the consent and disclosure scaffolding that makes the identifier defensible.
A first-party identifier emitted on first visit and recognized on subsequent visits, with coverage measurable against the audience the prior identifier reached. The metric is first-party identifier coverage: the percentage of returning sessions that carry the identifier and resolve cleanly, against a baseline of the prior identifier coverage. The value shows up in identity continuity across sessions (the second visit is recognized as the same visitor without depending on a third-party mechanism), in the resilience of the recognition (browser changes affect the third-party slice; the first-party slice survives), and in the disclosure clarity (the brand can answer the question of what identifier they use because they own it).
The second outcome is the identifier-graph integration: the first-party identifier becomes the edge that downstream identity resolution reads from, so the graph stays current as the third-party signals decay.
A backend service that issues the cookie, ideally co-located with the existing authentication or session layer so the deployment shape is familiar. Composable stacks suit this because the identifier service is one more component the warehouse and activation layer consume; packaged stacks may have a vendor-emitted identifier that conflicts in subtle ways with a brand-owned one and the question of which is canonical matters. The capability that decides whether the recipe is durable is the cookie-domain configuration: a cookie set on www.brand.com will not survive a visit to brand.com unless the domain attribute is set carefully, and the migration from third-party to first-party identifiers is the moment teams discover that their multi-subdomain setup never settled cleanly.
Compare the tools on Martech Stack Builder
Data engineering owns the emission service, the cookie endpoint, the identifier-graph write, and the integration with the customer-identifier resolution. Legal is critical because a persistent first-party identifier is processing personal data under GDPR-strict, the disclosure language has to be specific (the customer needs to understand what the identifier does), the retention window has to be defensible, and the withdrawal mechanic (clearing the cookie when the visitor withdraws consent, or rotating it) has to actually work. Marketing ops owns the downstream consumer migration: the audiences, the campaign segments, the activation paths that were keying on the prior identifier need to switch over, and the parallel-running period needs a clean cutover plan. Infrastructure handles the cookie-domain configuration and the certificate posture that lets the first-party cookie work across the brand's surfaces. The recipe ships in weeks where the backend infrastructure already serves authenticated sessions; longer where the team is building the first server-side capability of any kind. The slip is rarely the cookie itself; it is the disclosure conversation with legal and the downstream-consumer migration.
Work in this order. Mint server-side, write to the graph, scope to consent, link on login.
Set-Cookie response header. A document.cookie write falls under the same seven-day ITP clamp as before, and the recipe delivers nothing.Server-side event collection with client-side fallback covers steps 1 and 3, identifier graph write steps 2, 6 and 7, and consent-scoped signal collection steps 4 and 5.
The first failure is the cookie that does not actually survive. A first-party identifier set as document.cookie on the client falls under the same ITP seven-day clamp as the prior third-party cookies, defeating the recipe entirely. The cookie has to be server-set (Set-Cookie response header) for the browser to treat it as the longer-lived first-party storage. Teams that get this wrong ship a recipe that produces a more complex implementation of the same fragility they had.
The second is the missing disclosure. A persistent first-party identifier the brand uses for personalization is the kind of processing that the cookie banner needs to describe and the customer needs to be able to refuse, and a stack that emits the identifier silently because "it is first-party so it is fine" misreads the GDPR-strict line. The disclosure is the work that makes the recipe defensible; the technical emission is the easy part.
The third is the consumer migration that never completes. Activation paths, audiences, and campaign segments that were keying on the prior identifier need to switch to the new one, and a team that ships the new identifier alongside the old without setting a deprecation date ends up running both indefinitely. The parallel-running period is fine; the indefinite parallel-running is the state where the identifier proliferation that motivated the recipe quietly reproduces itself.
Did this recipe match your situation?Anonymous response. Sign up to leave a longer note tied to your account.
Resolve individual visitors to the account they belong to, so the buying committee shows up as one account rather than scattered anonymous leads
Connect the same person across phone, laptop, and tablet using signals you can stand behind, with an honest fallback when you cannot
Run identity resolution behind one service rather than each downstream system maintaining its own join logic, so a single resolution rule survives the next stack change