Anonymous analytics identifiers merge into authenticated profiles only when consent and purpose boundaries allow, with auditable lineage so pre-merge events do not inherit post-login permissions.
Package status: AI-assisted reference package. Static package validation has passed; implementation scenarios remain not run and human domain review is required before stable adoption.
Decision
Product analytics uses two identity layers: an anonymous device or session identifier collected before login and an authenticated profile identifier after login. Merge links them only when active consent covers the purposes attached to both pre- and post-merge processing. Events retain their original consent context; merging identities does not retroactively upgrade restricted events to marketing or personalization use. Denied or withdrawn consent blocks merge and schedules identity split where required.
Scope
- Anonymous id issuance, rotation, and storage boundaries.
- Login merge eligibility checks against consent records and stated purposes.
- Post-merge lineage fields on events and identity graph edges.
- Split behavior on logout or consent withdrawal for applicable purposes.
- Audit logs for merge, split, and blocked merge attempts.
Outside this block
- Legal interpretation of GDPR or other regimes; this block is engineering context only.
- Advertising network identity sync.
- Full customer data platform segmentation design.
Contract
- Merge requires explicit active consent for each purpose that will process linked pre-login events after merge.
- Pre-merge events tagged with analytics-only purpose cannot flow to marketing destinations after merge without separate consent.
- Merge operations are idempotent on pair (anonymous_id, user_id) and recorded with timestamp and consent snapshot id.
- Consent withdrawal after merge triggers split for affected purposes within the profile latency budget.
- Blocked merge attempts emit an auditable denial reason without leaking unrelated user attributes.
- Anonymous ids rotate on profile-defined intervals and do not embed email or account identifiers; rotation issues a new anon_id without retroactively widening purpose scope for events collected under the prior id.
- Downstream exports include merge_generation so replays detect stale graphs.
Implementation guidance
- Store consent snapshot ids on merge records, not full legal text, in hot paths.
- Use deterministic merge keys in batch replay jobs to avoid duplicate edges.
- Separate pipelines physically where marketing requires stronger isolation.
Failure handling and safeguards
- If consent service is unavailable, default to no-merge for restricted purposes.
- Never merge across tenant boundaries even when login credentials match.
- Do not backfill restricted events into newly consented destinations without explicit replay approval.
Verification and operations
- Monitor merge success, blocked merge rate, split latency, and export violations caught by purpose guards.
- Audit sample merges monthly for consent snapshot alignment.
- Execute acceptance scenarios in the target repository; packaged scenarios are not executed evidence.
Adoption assumptions
- Purpose names and latency budgets in fixtures are profile choices, not legal defaults.
- Teams map consent storage and taxonomy to their privacy program with legal review.