How Identity Resolution Works

Summary: When someone visits your website, the Delivr pixel checks their browser cookie against our identity graph of 400M+ records. If there's a match, the event is enriched with the visitor's name, email, company, job title, and 100+ other fields. This page explains how that process works.

---

The Resolution Flow

flowchart TD
    A[Visitor lands on your website] --> B[Pixel fires an event]
    B --> C[Cookie ID captured from browser]
    C --> D{Cookie in identity graph?}
    D -->|Yes| E[Match found]
    D -->|No| F[Raw event stored]
    E --> G[Enrich with contact data]
    G --> H[Resolved event with 100+ fields]
    F --> I[Event type, URL, timestamp only]

    style E fill:#22c55e,color:#fff
    style F fill:#6b7280,color:#fff
    style H fill:#22c55e,color:#fff
    style I fill:#6b7280,color:#fff

Every page view, click, and scroll generates an event. The difference between a resolved event and a raw event is whether we could match the visitor's cookie to a known identity.

---

Step by Step

1. The Pixel Fires

When a visitor loads a page on your site, the Delivr pixel JavaScript runs in their browser. It captures:

• A cookie ID (a unique identifier stored in the visitor's browser)
• The page URL they're viewing
• The event type (page view, click, scroll, etc.)
• Browser metadata (user agent, screen size, referrer)

This happens on every page load and interaction. The visitor doesn't see or interact with the pixel.

2. Cookie Lookup

The cookie ID is checked against Delivr's identity graph -- a database of 400M+ records that maps browser cookies to real people.

The identity graph is built from multiple data sources and updated continuously. When a cookie ID matches a record in the graph, we know who the visitor is.

3. Enrichment

When a match is found, the event is enriched with data from the identity graph:

flowchart LR
    A[Cookie ID] --> B[Identity Graph]
    B --> C[Person Record]
    C --> D[Contact Info]
    C --> E[Company Info]
    C --> F[Demographics]

    D --> D1[Name, email, phone]
    D --> D2[Job title, LinkedIn]
    E --> E1[Company, domain, industry]
    E --> E2[Revenue, employee count]
    F --> F1[Location, seniority]
    F --> F2[Department, education]

A resolved event includes the original event data (URL, timestamp, event type) plus all enrichment fields. You can query for resolved events using filter=resolved:eq:true in the API.

4. Storage and Access

Events are stored and available through the API within seconds. You can:

• Query in real-time via the On-Domain Events API
• Export to CSV for CRM import via the Export Events guide
• Build audiences based on visitor behavior

---

What Makes a Cookie Resolvable

Not every visitor can be identified. Resolution depends on the visitor's browser and cookie persistence:

flowchart TD
    A[All Website Traffic] --> B{Human visitor?}
    B -->|No - Bot/Crawler| C[Filtered out]
    B -->|Yes| D{US-based IP?}
    D -->|No| E[Not resolved]
    D -->|Yes| F{Browser type?}
    F -->|Chrome, Edge, Firefox| G[Cookie persists up to 400 days]
    F -->|Android| H[Cookie persists reliably]
    F -->|Safari / iOS| I[Cookie expires every 7 days]
    G --> J{Cookie in identity graph?}
    H --> J
    I --> K[Very low match probability]
    J -->|Yes| L[Resolved - 20-30%+ of this segment]
    J -->|No| M[Not resolved]

    style C fill:#6b7280,color:#fff
    style E fill:#6b7280,color:#fff
    style K fill:#ef4444,color:#fff
    style L fill:#22c55e,color:#fff
    style M fill:#6b7280,color:#fff

The key factors:

• Bots and crawlers (15-50% of traffic) are filtered out automatically
• Safari and iOS visitors have cookies that expire every 7 days due to Apple's Intelligent Tracking Prevention (ITP), making consistent identification very difficult
• International traffic doesn't go through resolution (US IP addresses only)
• Chrome, Edge, and Firefox on desktop have the highest resolution rates because cookies persist for months

See Understanding Resolution Rates for more detail on what affects your rate.

---

The Give-to-Get Model

Delivr's identity graph grows through a give-to-get model. When customers deploy the pixel on their sites, the visitor data they contribute helps expand and refresh the identity graph. In return, they get resolution capabilities across the full graph.

This means:

• More pixels deployed = better resolution for everyone. Each new site adds cookie-to-identity mappings that benefit all customers.
• The graph stays fresh. Active browsing data continuously updates identity records, keeping contact information current.
• No single customer's data is exposed. The graph stores anonymized mappings (cookie ID to hashed email). Individual customer site data is never shared.

---

Resolved vs. Raw Events

Here's what you get in each case:

Raw events are useful for traffic analysis and bot filtering. Resolved events are what drive sales outreach and marketing campaigns.

---

Next Steps

• On-Domain Events API -- Query events and filter for resolved visitors
• Event Types Reference -- What each event type captures
• Understanding Resolution Rates -- Why rates vary and what affects them
• High-Intent Visitors -- Turn resolved events into a daily lead list