Product Documentation
  1. Concepts

How Identity Resolution Works

Summary: When someone visits your website, the Delivr pixel checks their browser cookie against our identity graph. 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

Flow: a visitor lands on your website, the pixel fires an event, and the cookie ID is captured from the browser. If the visitor opted out or is in the EEA, UK or Switzerland, the raw event is stored. Otherwise, if the cookie is in the identity graph, the match is enriched with contact data into a resolved event with 100+ fields; if not, the raw event is stored. A raw event carries the company from the IP where available.

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 are viewing
  • The event type (for example, page view, click, or scroll)
  • Browser and request metadata (user agent, IP address, 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, which 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:

Identity graph: a cookie ID leads through the identity graph to a person record, which holds contact info (name, email, phone, job title, LinkedIn), company info (company, domain, industry, revenue, employee count) and demographics (location, seniority, 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. A visitor we already know is identified at once. Other visits can still be identified for a few days after they happen, so the most recent days can rise until they are finished. You can:

What Makes a Cookie Resolvable

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

Decision tree for all website traffic. Traffic classified as a bot or crawler is outside the addressable set, but its cookie may still match. Non-US traffic from the EEA, UK or Switzerland is not resolved and its identity is withheld; other non-US traffic is outside the addressable set, but its cookie may still match. For US traffic, the cookie persists up to 400 days in Chrome, Edge and Firefox, persists reliably on Android, and expires every 7 days on Safari and iOS. A cookie not in the identity graph is not resolved. A cookie in the graph is resolved, unless Sec-GPC is asserted, in which case its identity is withheld.

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. In the EEA, the UK and Switzerland, however, we never resolve a visitor, regardless of what the graph knows.
  • Chrome, Edge and Firefox on desktop, and Android, resolve at higher rates than Safari and iOS, because their cookies last longer. See the rates by browser.

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

What a match means

When you open a resolved visitor in the dashboard, it says Matched on a hashed email. That line means:

  • The visitor's browser cookie is linked to a hashed email in the identity graph.
  • We make that link only after we see the person identify themselves in that browser, for example with a form fill or a sign-in.
  • We do not identify a visitor from device or browser characteristics. A visitor whose cookie has no link to a hashed email is not resolved.

The dashboard can also show First seen on your site. That date is the person's first event on your own pixels within the lookback period it names. It is not the date the identity graph first saw the person.

How Your Site Data Is Stored and Used

Pixel data is stored on Amazon Web Services in the United States. Every event, and every visitor resolved on your site, is stored under your organization and kept separate from other customers' data. Raw visitor-level pixel data is kept for no more than 13 months from collection.

Your site data stays yours:

  • We never show your events or resolved visitors to another customer.
  • We never build an audience or segment for anyone else from traffic to your site.
  • Nothing we deliver to another customer identifies your company, your site, or a visit to it.

The identity graph is built from Delivr's own and licensed data sources, together with two things pixel deployments contribute:

  • Identifier links. The graph keeps the link between a cookie ID and a hashed email. These links carry no page URLs or browsing behavior and are not tied to your organization. Hashed emails are personal data, not anonymous data, so deletion and privacy requests apply to them.
  • Pooled intent signals. Event-level signals are pooled with Delivr's other sources to improve the identity graph and topic-level intent data. Your account and organization are removed from the signals. Results are topic-level and never name your company, domain, or pages. You can opt out by written notice, and we stop within 15 days. Signals already pooled in aggregate are not affected.

The full terms are in the Customer Site Data section of the Terms of Service and in the Data Processing Addendum.

Resolved vs. Raw Events

Here is 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 (event-specific details such as scroll % and click target)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.

Can a HEM in the redirect replace the JavaScript pixel?

No. The redir parameter on the pixel's image endpoint (/pixel/core/api/send-event/get) sends a HEM out, not in. It does not identify anyone.

When a request carries redir, the endpoint answers with a redirect to that URL. Before it redirects, it replaces these placeholders. $DLVRCOOKIE is the visitor's Delivr cookie id. $DLVRHEM is a JSON array of the HEMs already resolved for that cookie, or [] if none. It also replaces $REF (the referrer) and $EVENTTIME. It is used to hand a visitor to a partner's cookie-sync URL with their identifiers attached.

  • Nothing reads a HEM you send. The endpoint takes no hem parameter. The HEMs it expands are the ones the identity store already holds for the visitor's cookie. Therefore a visitor the cookie has not resolved gets [].
  • Only approved partner hosts are redirected to. The target must be an absolute http or https URL whose host is on our partner sync allowlist. For any other target the request still succeeds but sends no redirect.
  • Visitors who are never resolved get no HEM. Bots, visitors with Global Privacy Control, and visitors in restricted countries get [].

To identify visitors, use the JavaScript pixel (see Identify Site Visitors). Alternatively, for people who click through an email, put a dlvr_et token on the link (see Identify Email Recipients). To look up a HEM you already hold, call GET /api/v1/lookup.

Next Steps

Updated 6 days ago

Did this page help you?