Understanding Resolution Rates

New pixel? Identification starts right away and builds as your visitors return. We identify someone once we have seen them identify themselves somewhere we can see, such as a form fill or sign-in. Therefore most first visits stay anonymous. Your own test visit usually will not be identified. See What to Expect When You First Install.

Summary: The Statistics page leads with People named: the people named on your site over the counted days. It covers visitors in every country, and it keeps visitors the rate leaves out as automated. The sentence under it is the visitor-day rate, such as "19.8% of addressable visitor-days named, 87 of 440". The rate covers US visitors, with bots and automated browsers left out. Therefore People named can be higher than the named visitor-days in the rate. The API, the Per-pixel tab and the scheduled Resolution Summary email use a different measure, covered in Event Rates.

What the Dashboard Shows

When someone visits your website, the Delivr pixel records it. If we can match that visitor to a real person in our identity graph, the visit is resolved. Resolved means we know who they are (for example name, email, company, and job title).

The Statistics page opens on the people named on your site, such as "4,812 people named on example.com, Oct 16 to Oct 30". The sentence under it is the visitor-day rate.

People named: everyone named on your pixels

People named counts the people named on the page's pixels over the counted days. It covers visitors in every country, and it keeps visitors the rate leaves out as automated. Therefore People named can be higher than the named visitor-days in the rate. For example, "159 people named" can sit above "88 of 440 addressable visitor-days named".

Each person counts once in People named, except when the figure reads "Up to N people named". On a long or high-traffic range, an exact count can be unavailable. The dashboard then shows "Up to N" with this note: "An exact count isn't available at this volume; someone seen on more than one day of a long window, or on more than one pixel, may be counted more than once." N is then an upper bound.

Visitor-day rate: the addressable basis

On the Statistics page, the sentence under People named is the visitor-day rate. For example: "29.2% of addressable visitor-days named, 85 of 291". Where your visitors went, on the same page, gives the same figure as "85 of 291 addressable visitor-days named".

Home shows that line only while the pixel is new or has named nobody. Identity shows it only while the pixel is new or has named fewer than 10. Neither page has a visitor-day rate of its own.

A visitor-day is one visitor on one day. Addressable visitor-days are US visitors, with bots and automated browsers left out. Visitors outside the US are shown on their own line. For example, the dashboard shows "120 visitors were outside the US, where far fewer people can be named (3 named)". They are not in the rate.

The rate uses the first basis the data covers for your dates:

1. Addressable: US visitors, without bots and automated browsers. The dashboard says "addressable visitor-days".
2. US visitors, bots included. The dashboard says "US visitor-days" and adds "bots included".
3. All visitors. The dashboard says "visitor-days".

When automation is left out, the dashboard says how many: "12 automated visitors (bots and scripts) were left out."

How automation is detected: we leave out browsers whose signals do not look like a real browser. We also leave out known automation tools and timing a real visitor cannot produce. Very few identified people are excluded this way.

Rates are colored on bands for their basis. Below the first number is red and below the second is amber:

Daily counts

Home leads with People named for the week, counted the same way as on the Statistics page. If that count cannot be read, Home shows Email-days named instead. That figure counts the hashed emails your visitors were matched to, once per day and added up over the week. Therefore a visitor with two emails counts twice.

On Home and the Statistics page, Visitor-days and Email-days named are daily distinct counts added up over the range, not unique people. Someone seen on 3 days counts 3 times. The People named headline on the Statistics page is different, because it counts each person once, unless it reads "Up to N".

Finished and unfinished days

Identification keeps running for a few days after a visit, so late matches can still raise the most recent days until those days are finished. These views describe data completeness. They do not promise that a given unresolved visit will be identified later.

The Statistics page opens on All N days, every day in the range, and Finished only narrows it to the days whose identification is complete. Home and the organization cards count every day in the range too. The choice appears only when the range mixes finished and unfinished days. Compare like with like: a range that includes unfinished days and a finished-only range do not have the same completeness.

Everything on the Statistics page

• The page opens on the people named on your site, such as "4,812 people named on example.com, Oct 16 to Oct 30". Each person counts once over the counted days, unless the figure reads "Up to N".
• The sentence under it is the visitor-day rate and its basis, such as "4.2% of addressable visitor-days named". The page shows no event-rate headline.
• Visitor-days (all) counts visitors in any country, once per day they visit. Email-days named counts the hashed emails visitors were matched to, once per day they visit.
• The Browser tab shows Total cookies, US cookies (US cookies, bots left out when bots are left out), Bots left out, Named, US cookies and Rate, US cookies. If US visitors cannot be counted for your dates, the tab shows Named and Rate (all traffic) instead of the US rows.
• Finished only labels the days it counts: the first and last day, then "finished days only".
• The per-browser columns (Visitor-days (all), Rate (all traffic)), and the first-time vs returning split, stay all-traffic.
• The per-pixel table shows the addressable event rate.

What to Expect When You First Install

• Identification builds over time. We identify a visitor deterministically. We do this once we have seen that person identify themselves somewhere we can see, such as a form fill or a sign-in. A new pixel's visitors are mostly people we have not seen yet, so they stay anonymous at first. Returning visitors are identified far more often than first-time ones.
• Your first identified visitors usually appear within a day. They show up on the Identity page the next day.
• Email sends bring link scanners. Right after an email goes out, security scanners (often from Microsoft and AWS address ranges) open every link in it. They look like a burst of visitors and are almost always anonymous. Bots and scripts are left out of the addressable rate even when one does match.
• Your own visit is not a reliable test. A new browser, a private window, cleared cookies, or Safari usually is not identified. Judge the pixel on real traffic over a few days.
• Today's visits appear tomorrow. The dashboard Home board counts whole days through yesterday (UTC), and the Identity page defaults to yesterday.

How to Identify More Visitors

• Declare the sites your pixel runs on. Visitors are identified only on the sites your pixel lists, so list every site you install it on, subdomains included. If one pixel runs on many sites, such as an agency's client sites, choose any site instead. See Declare Where Your Pixel Runs.
• Put the pixel on every page, and load it on the first page view. Landing and pricing pages count. A tag manager rule that fires the pixel late, on scroll or after a delay, misses visits.
• Bring visitors back. Returning visitors are identified far more often than first-time ones, so retargeting and email nurture also raise identification.

What Affects Your Rate

Things that can raise it

• More Chrome, Edge and Android traffic: these browsers keep cookies longer than Safari and iOS, so they resolve at higher rates
• Returning visitors: People who have been seen before are more likely to match
• B2B sites: Business visitors on managed devices with persistent cookies resolve better than consumer traffic

Things that can lower it

• High mobile/iOS share: If 60%+ of your traffic is iPhone, your rate will be lower
• International audience: Non-US traffic is outside the addressable benchmark and usually resolves at a lower rate, although existing matched cookies can resolve. Visitors in the EEA, the UK and Switzerland are never resolved
• Bot-heavy sites: News, content, and SEO-heavy sites attract more crawler traffic

Things that make it volatile

• Low event volume: A few visitors can move a daily percentage sharply. More traffic stabilizes the measurement. However, it does not make an individual visitor more resolvable.
• Bursty sessions: One long-lived tab, automation loop, or unclassified crawler can generate many events. The extra events can dominate an event rate while the cookie rate stays comparatively stable.

Event Rates: the API, the Per-pixel Tab and the Email

Each pixel fire is an event. Your event rate is the percentage of events that get resolved. It is not on the Statistics page headline, so do not compare it with the visitor-day rate.

You meet event rates in three places:

• The Resolution Statistics API returns them. See Via the API.
• The Statistics page Per-pixel tab shows each pixel's addressable event rate.
• The scheduled Resolution Summary email reports the addressable event rate, labelled Event rate. It covers your organization's website pixels for the report's whole UTC days.

How to Read the Number

Not all website traffic comes from people who can be identified. The all-traffic event rate includes everything, including repeated events from the same cookie. Bots, cookieless requests, international traffic, and highly active sessions can move it sharply. The addressable event rate uses directly measured US, cookied traffic with bots and automated browsers left out.

The addressable view includes US visitors with a usable cookie that were not detected as automated. It is counted directly from the event eligibility predicate. It is not reconstructed by subtracting dashboard buckets, because categories such as bot and international can overlap.

Think of it like email open rates. The all-traffic number includes a lot of recipients who never see the email (spam filters, inactive accounts). Therefore the rate looks lower than reality.

Event Rates by Browser

The rates in this table are typical ranges. Your actual rates depend on your site's traffic mix. They are rates per site event (page views, clicks, forms and other tracked actions) on addressable traffic, not the share of your visitors who are identified.

The Statistics page Browser tab shows your Safari and iOS Rate (all traffic). That is the share of all-traffic visitor-days named, not the addressable event rate in this table, so the two do not compare directly.

The Apple factor: About 36-40% of US browser traffic comes from Safari or iOS devices. The Apple factor is an industry-wide limitation that affects every identity resolution provider, not just Delivr.

Event Rate vs. Cookie Rate vs. Resolved Identifier Count

You may see two rate metrics and a resolved-identifier count. They measure different things:

Cookie rate: What percentage of distinct cookie IDs resolved? The dashboard counts US cookies only. The API counts all of them (see Dashboard vs. API).

A cookie is a browser identifier, not a guaranteed unique person. One person can have multiple cookies across browsers, devices, resets, or privacy expiry. The cookie rate removes the event-frequency weighting, so one hyperactive session does not count dozens of times.

Event rate: What percentage of total events resolved?

This weights active sessions more heavily because every pixel fire is counted. It is useful for understanding how much activity is enriched, but a long-lived tab, scripted session, or crawler can move it sharply.

Resolved identifier count: distinct_profiles counts distinct resolved hashed-email identifiers (HEMs). One person can have multiple HEMs, so this is not a guaranteed unique-person count and has no anonymous-person denominator.

Neither the event rate nor the cookie rate is guaranteed to be higher. Their relationship depends on how much activity resolved and unresolved cookies generate.

Via the API

Call the Resolution Statistics endpoint. It returns the whole picture for your organization in one response. The response includes the all-traffic and addressable rates and the why-unresolved funnel. It also includes the per-browser split, the per-visitor (cookie) rate, and the first-time vs returning breakdown.

curl "https://api.delivr.ai/api/v1/resolution/statistics" \
  -H "X-Api-Key: YOUR_API_KEY" \
  -H "X-Api-Secret: YOUR_API_SECRET"

Three fields in the response are worth understanding:

• Event rate (resolution_rate) counts pixel fires, so frequent visitors and scripted sessions carry more weight.
• Cookie rate (visitors.cookie_rate) counts distinct browser cookies. It reduces event-frequency weighting but is not a unique-person rate.
• Addressable rate (addressable.rate) uses the directly measured addressable.events and addressable.resolved_events pair. If the pair is missing, incomplete, or violates subset invariants, addressable.available is false and the three values are null instead of being estimated.

Bot-free versions sit beside these. addressable_human_rate is the event rate with automated visitors removed. In visitors, us_cookie_rate and addressable_cookie_rate are the US and US-without-bots visitor rates, and automated_us_cookies counts the US visitors left out. Each is null unless it covers every day in your window, and the original fields do not change.

The first_touch section compares first-time and returning browser cookies. Returning cookies often resolve at a higher rate, but use the measured split for your own traffic rather than assuming a fixed relationship.

Dashboard vs. API

Three things differ: which pixels are counted, the event rate, and the visitor basis.

Pixels. The Statistics page opens on website pixels. With no pixel_type, the API counts website and Ads pixels together, so its event and visitor counts run higher whenever an Ads pixel saw traffic. Send pixel_type=website (with project_id for one project) to read the pixels the page reads, or pixel_type=ads for the page's Ads type. The CSV summary's Pixels row names the type it covers.

Event rate. The page leads with people named and a visitor-day rate, not an event rate. The CSV summary's Addressable rows are addressable_human_rate, over addressable_human_events and addressable_human_resolved_events. The summary uses addressable.rate only when those are null. addressable.rate still counts automated visitors, so it reads differently from the summary for the same dates.

Visitor basis. visitors.cookie_rate is all-country: it divides by every cookie. The dashboard's visitor-day rate divides by US cookies without bots, so the two numbers differ for the same dates. To match the dashboard, pick the basis by its counts, not its rate:

• If visitors.addressable_cookies is present, use visitors.addressable_cookie_rate (addressable: US, bots excluded). A null rate here means every US visitor was automated (automated_us_cookies above zero) or there were no US visitors, and the dashboard shows no rate either.
• Otherwise, if visitors.us_cookies is present, use visitors.us_cookie_rate (US).
• Otherwise, use visitors.cookie_rate (all countries).

See the Resolution Statistics reference for the full response schema.

What Matters More Than the Rate

The resolution rate tells you how much of your traffic is identified. But for sales and marketing, what matters is:

1. Are you getting enough leads? Read People named on the Statistics page for the dates you care about. It counts each named person once, except when it reads "Up to N people named". The visitor-day rate counts visitor-days and the event rate counts events, so one person can count many times in either. Do not multiply the visitor-day rate or the event rate by your traffic to forecast leads.

2. Are they the right people? Resolved visitors come with full enrichment: name, email, company, job title, seniority, industry, and more. One identified VP of Sales on your pricing page is worth more than 100 anonymous page views.

3. Is the data actionable? Each resolved event includes the page visited, time, and full contact details. The event data is ready for CRM import or outbound campaigns.

Next Steps

• On-Domain Events API: query your resolved events
• High-Intent Visitors: build a daily lead list from high-value page visitors
• Export Events to CSV: export resolved visitor data for your CRM