Visitor Identity and Matching

Ours Privacy recognizes when someone returns to your site so their interactions connect into a single, consistent identity instead of looking like a brand new person each visit. Identity is always scoped to your own account: Ours never links a visitor across unrelated companies, and the strongest signals are the identifiers you choose to provide.

This page explains how a visitor is recognized, how you re-identify a known person, and how unified user profiles are built across a person's sessions.

How a visitor is recognized

Every visitor to your site is given a visitor ID, stored in a cookie (with local storage as a backup) in their browser. On a return visit that ID is read back, so their sessions connect to the same identity. Two things build on that base:

• Identifiers you provide. When you send an external_id or email, Ours ties the visitor to a known person and can merge their activity across devices. These are the most reliable signals because you control them, and on server-side sources, where there's no cookie, they are how a visitor is identified at all.
• Identity Recovery. When a visitor can't be recognized from their cookie, for example moving between an in-app browser and their default browser, the opt-in Identity Recovery backstop can reconnect them. It runs only after the cookie and any provided identifiers have failed.

A new ID is created only when none of these recognize the visitor.

First-party and third-party cookies

Where the visitor cookie lives determines how durable it is, and that depends on whether you use a custom domain.

• With a custom domain (recommended): the SDK is served from your own subdomain, so the cookie is first-party to your site. First-party cookies are not subject to the tracking-prevention rules that browsers apply to third parties, so a returning visitor stays recognized for a long time.
• Without a custom domain: the SDK is served from a shared Ours Privacy host, so the cookie is third-party relative to your site. Modern browsers (Safari's ITP, and others) actively limit third-party cookies, so identity is less durable and a returning visitor is more likely to look new.

The cookie is shared automatically across the subdomains of whichever domain serves it (for example www. and app. of the same site). For this reason, setting up a custom domain is the single most effective step for reliable visitor recognition.

Re-identifying a known visitor

When you know who someone is, typically once they log in, pass their external_id or email so Ours can attach the session to that person.

HTTP API

Include external_id or email in your requests to the HTTP API.

Sources

Include external_id or email in your webhook payloads.

When these identifiers are present, Ours uses them to look up and match the visitor within your account.

Maintaining identity across your own domains

Cookies are not shared between separate domains. If you operate more than one domain and want a visitor's identity to carry across them, you pass the visitor ID explicitly. Nothing is shared between domains unless you choose to pass it.

Use the ours_visitor_id query parameter:

// Example URL with visitor ID
https://example.com?ours_visitor_id=${ours.getVisitorId()}

You can carry the session along with it using ours_session_id, so the journey reads as one continuous session rather than two:

// Example URL with both visitor ID and session ID
https://example.com?ours_visitor_id=${ours.getVisitorId()}&ours_session_id=${ours.getSessionId()}

When ours_session_id is present in the URL, the SDK uses it as the current session instead of starting a new one. This is useful for:

• Navigation between domains or subdomains you own
• Linking a visitor's journey across your own properties
• Keeping analytics and destinations on one continuous session across domains

Unified user profiles

When visitors share the same external_id, Ours merges their records into a single User profile. This connects a known person's activity across the devices and sessions where they've identified themselves, giving you one view of that person within your account.

How profiles are built

1. Detection: when an event is processed, Ours checks whether the visitor has an external_id.
2. Lookup: if present, Ours finds every visitor in the account with the same external_id.
3. Merge: records are sorted by last_seen_at (newest first) and their properties combined.
4. Profile: a single user is produced with the most up-to-date information across those sessions.

Merging strategy

• Newest data wins. Properties from the most recent session take precedence.
• Nothing is lost. Properties from every session are preserved; newer values override older ones.
• Time spanning. first_seen_at keeps the earliest timestamp; last_seen_at keeps the latest.
• Deterministic. The merge is consistent and repeatable.

Example

A person interacts with your site on two devices:

Device A (mobile):

• external_id: "user123"
• email: "user@example.com"
• first_name: "John"
• last_seen_at: "2024-01-15T10:00:00Z"

Device B (desktop):

• external_id: "user123"
• email: "user@example.com"
• last_name: "Doe"
• city: "San Francisco"
• last_seen_at: "2024-01-16T14:30:00Z"

Resulting profile:

• external_id: "user123"
• email: "user@example.com"
• first_name: "John"
• last_name: "Doe"
• city: "San Francisco"
• first_seen_at: "2024-01-15T10:00:00Z"
• last_seen_at: "2024-01-16T14:30:00Z"

Accessing user data

During destination dispatch, you can reference user properties with the user.* prefix:

• user.email
• user.first_name
• user.city
• user.external_id

This unified data is available alongside visitor and event data when you map fields to a destination.

Providing your own visitor ID

If you already run your own visitor identification system, you can supply the ID when initializing the SDK:

ours('init', '<ours web api key>', {
  user_id: '<your custom visitor id>',
});

You can also set a custom visitor ID through the Tag Manager interface.

Note: When supplying your own IDs, make sure your system generates a stable, unique ID for each person and persists it across their visits.

Excluding request context

Exclude Request Context is a per-source privacy control. When enabled, Ours does not use request metadata such as the visitor's IP address for identity matching. Because Identity Recovery relies on those signals, turning this on also disables Identity Recovery for that source. Use it when you want matching to depend only on cookies and the identifiers you provide.

Privacy

• Identity is scoped to your account. Ours never links a visitor across unrelated accounts.
• The most reliable identifiers (external_id, email) are ones you choose to send.
• Identity carries across separate domains only when you pass the visitor ID yourself.
• You can exclude request context from matching on a per-source basis.

Best practices

1. Use a custom domain. First-party cookies are the single biggest improvement to reliable visitor recognition.
2. Send external_id early. Set it as soon as you know who someone is to unify their profile across devices.
3. Include email during early interactions to improve match accuracy before an account exists.
4. Pass ours_visitor_id when crossing your own domains where cookies aren't shared.
5. Use user.* properties in destination mappings to send unified, cross-device data downstream.

Next Steps

• Custom Domains: serve the SDK first-party so returning visitors stay recognized.
• Identity Recovery: the opt-in backstop for visitors a cookie can't recognize.