Scope company attribution beyond anonymous browser identity

Feature request: prevent anonymous browser continuity from becoming a false multi-company account journey
I found a case in Claire’s Ploy analytics where one anonymous ID was presented across three company observations: Temp Mail Pro, VTS, and Buildify.
The underlying event evidence does not support a three-company journey:

• 19 events across 2 sessions
• 3 IP addresses
• 1 stable iPhone/Chrome user agent
• 0 events assigned through a deterministic identity
• all page URLs remained on [clairemed.ai](http://clairemed.ai)
• the first IP change happened inside the same session, with the same browser and a normal scroll/exit continuation
• a later return visit used the same browser profile on a new session and IP

This looks like valid anonymous browser continuity combined with an overmerged company journey, not an anonymous-ID collision. IP and company observations are useful context, but they should not permanently define the organization attached to a browser.
Product critique
Ploy currently exposes enough event evidence to preserve a browser journey, but the company/account presentation can imply more certainty than the evidence supports. When several company observations become associated with one anonymous ID, downstream account summaries can make separate, time-bounded observations look like one organization’s continuous activity.
That creates three risks:

1. False account intent: activity from different observations may be combined into one company journey.
2. Misleading outreach decisions: teams may contact an account based on events that cannot be attributed to it confidently.
3. Unsafe remediation pressure: users may conclude that anonymous IDs should rotate whenever an IP changes, which would break legitimate repeat-visit and session continuity.

The browser identity is not necessarily wrong. The company relationship needs stronger boundaries and visible provenance.
Spec ask
Please separate these concepts in Ploy’s analytics model:

1. Anonymous browser identity

Persistent browser/client continuity.
Must not rotate solely because IP or company observation changes.

1. Known-person identity

Created only from an approved deterministic signal, such as a consented identify call or verified form submission.
Must expose whether an event was attached through that signal.

1. Organization observation

• Append-only and linked to an event or session, not permanently attached to an anonymous ID.
• Fields should include:

observation ID
anonymous ID
event ID and/or session key
company domain and normalized company ID
observed timestamp
valid-from and valid-to timestamps
confidence
provenance/derivation version
conflict state
Required behavior

• Build company journeys from event- or session-scoped observations.
• Never let a later company observation relabel earlier events or sessions.
• Require a deterministic identity signal before merging company observations across sessions as one known journey.
• If one anonymous ID receives two or more company domains within 24 hours without deterministic identity, set company_conflict.
• Exclude conflicted identities from company/account summaries by default while keeping every observation auditable.
• Keep corrections in derived relationships. Do not rewrite raw events, session keys, anonymous IDs, timestamps, or attribution history.
• Show confidence and provenance in the account view so users can distinguish deterministic attribution from temporal alignment.

Event-contract improvements
The incident was harder to diagnose because the current event view does not expose every contract needed for durable QA. Please add:

• a stable unique event ID on every event;
• separate client user agent and delivery/request user agent fields;
• an explicit organization-observation ID or relationship;
• organization observation time and confidence;
• derivation/version metadata;
• a visible reason when an event appears in a company journey;
• conflict/quarantine state in account summaries.

Acceptance criteria

1. Mid-session IP change

The same browser and session change IP. The session remains intact, no new visitor is created, and no company journey is created solely from that IP change.

1. Legitimate repeat visit

The same browser returns later on a new IP. Anonymous continuity is retained, a new session and pageview are counted normally, and company attribution remains scoped to the applicable observation.

1. Conflicting companies

Two company domains are observed for one anonymous ID within 24 hours without deterministic identity. Raw events remain unchanged, the observations stay separate, company_conflict is set, and the identity is excluded from combined account summaries.

1. No historical backfill

A company observation received later does not relabel earlier sessions.

1. Deterministic identify

A consented known-user identify event can connect legitimate sessions, with the merge reason and provenance visible.

1. Collision candidate

Concurrent sessions with incompatible user agents or device families are quarantined for review rather than silently merged.

1. Pageview integrity

The correction introduces no duplicate or replacement pageviews and does not interfere with valid lifecycle pageview repair.

1. Reversibility

Removing or changing a derived organization relationship restores the account view without modifying the raw event ledger.
Reproduction fixture
Anonymous ID: 5d4082f7-b595-49d5-8a27-e4c263873cf9
Expected interpretation:

• preserve one anonymous browser identity;
• preserve both sessions and all 19 raw events;
• keep the three company observations separately auditable;
• do not present Temp Mail Pro, VTS, and Buildify as one coherent account journey;
• treat the VTS association as unresolved unless a direct event/session relationship exists.

The goal is not to reduce identity continuity. It is to make company attribution appropriately scoped, confidence-bearing, reversible, and safe for account-level decisions.