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 is 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 configured page view, click, and scroll generates an event while collection is enabled. The difference between a resolved event and a raw event is whether we could safely 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 for configured page loads and interactions while collection is enabled. The visitor does not interact with the pixel itself.

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:


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{Classified bot or crawler?}
    B -->|Yes| C[Outside addressable set; cookie may still match]
    B -->|No| D{US-based IP?}
    D -->|No| E[Outside addressable set; cookie may still match]
    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]
    C --> J{Cookie in identity graph?}
    E --> J
    G --> J
    H --> J
    I --> J
    J -->|Yes| L[Resolved]
    J -->|No| M[Not resolved]

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

The key factors:

  • Classified bots and crawlers are excluded from addressable traffic. Automation that the classifier misses can remain in all-traffic counts and generate many events.
  • Safari and iOS visitors can resolve, but Apple's Intelligent Tracking Prevention (ITP) shortens cookie lifetime and makes consistent identification more difficult.
  • International traffic is excluded from the addressable benchmark because the graph is US-focused. An existing matched cookie can still resolve outside the US.
  • 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:

Field CategoryRaw EventResolved Event
Event basicsEvent ID, timestamp, event type, URLSame
Browser dataCookie ID, user agent, IP, referrerSame
Event detailsevent_data (scroll %, click target, etc.)Same
Contact info--Name, email, phone, LinkedIn, job title
Company info--Company name, domain, industry, revenue, size
Demographics--Location, seniority, department, education
Identifiers--Hashed emails (MD5, SHA1, SHA256)

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


Next Steps


Did this page help you?