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:
- 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{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 Category | Raw Event | Resolved Event |
|---|---|---|
| Event basics | Event ID, timestamp, event type, URL | Same |
| Browser data | Cookie ID, user agent, IP, referrer | Same |
| Event details | event_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
- 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
Updated 4 days ago
