Event Resolution Field Catalog

API: GET /api/v3/events/resolution_full_profile on api.delivr.ai (v1 is legacy and remains for back-compat)
Service: Event Store Lookup Service (Rust/DataFusion)
Schema endpoint: GET /api/v3/events_schema?source=pixel
Last verified: 2026-09-02
Sources: Pixel (on-domain) and DSP (ad impression) events share enrichment fields but differ in core event fields.

---

Quick Reference

• Total schema fields: 140
• Max time window: 25 hours (end_ms - start_ms)
• Default limit: 300 rows
• Resolved on-domain events include identity + enrichment fields (person, company, demographics)
• Unresolved on-domain events include only core event fields (no person/company data)
• Some visitors are never resolved by design: see Where we do not resolve visitors

---

Query Parameters

Filter Operators

Common Filters

resolved:eq:true                          # Only resolved events
resolved:eq:false                         # Only unresolved events
event_type:eq:page_view                   # Specific event type
event_type:eq:form_submission|event_type:eq:scroll_depth  # Multiple event types (OR)
resolved:eq:true,first_name:ne:null       # Resolved with first name (AND)
ip_country:eq:US                          # Visitors on a US IP address
ip_country:eq:US|ip_country:eq:CA         # US or Canadian IPs (OR)
resolved:eq:true,ip_country:eq:US         # Resolved US visitors (AND)
ip_country:not_null                       # Exclude traffic we could not place

ip_country is the country of the request IP, not of the resolved person.
See the note under Network and Client Fields for
why it differs from personal_country, and for how to treat null.

Profile Completeness

---

Response Metadata

Every response includes a meta object:

---

Field Catalog

Fields are grouped by category. Population rates are based on a sample of 34 resolved events.

Legend:

• Rate: Percentage of resolved events where field is non-null
• Nullable: Whether the Arrow schema allows null values
• Resolved-only: Field is only populated when resolved=true

---

Core Event Fields

Always present on every event (resolved or unresolved).

Source-Specific Event Fields

Fields that differ between pixel and DSP events.

Pixel-Only Fields

Present only on pixel (on-domain) events. Null or absent on DSP events.

DSP Campaign Fields

Present only on DSP (ad impression) events. Null or absent on pixel events.

V2 Metadata Fields

Present on both pixel and DSP events when queried via v2 endpoints.

Network and Client Fields

Raw request data from the pixel capture.

ip_country is where the request came from, not where the visitor is or
who they are. It is the geolocation of the request IP observed at capture
time, so a VPN or proxy places the event at the exit node's country rather
than the visitor's physical location. personal_country and
company_country are profile attributes of the resolved person and their
employer. The three routinely disagree, and legitimately so: someone
travelling, working remotely, or on a VPN produces a request country that
differs from both. Filter on ip_country to scope by where traffic comes
from; filter on personal_country to scope by where a person is based.

Events on IPv4 addresses carry ip_country. IPv6 is not yet placed and reads
as null, as does any address outside the lookup. Null means unknown, so decide
explicitly whether unknown traffic belongs in or out of your filter.

ip_country coverage by period. The field is populated across history,
but how much of it is usable depends on when the event was captured.

Period	Coverage	What a country filter does
2026-05-16 onward	Effectively complete	Works as expected
2026-03-20 to 2026-05-15	Roughly 1 to 4%	Returns a small, unrepresentative slice
Before 2026-03-20	No events retained	No results

The gap is not a backfill limitation. During that earlier window a capture
defect on our side recorded an internal address instead of the visitor's, so
for most of those events there is no visitor IP to place and no country is
derivable by any means.

This is worth reading twice, because the failure is quiet. A filter like
ip_country:eq:US over April returns rows, and they are real rows, correctly
placed. They are simply a few percent of the traffic that was actually there.
Nothing in the response distinguishes that from a genuinely quiet month. For
any analysis spanning early 2026, either start at 2026-05-16 or compare
ip_country:not_null against the unfiltered count first, so you can see how
much of the window you are actually measuring.

---

Where we do not resolve visitors

Some events are collected normally but never carry an identity. This is by
design, not a match-rate problem, and no amount of retrying or re-firing the
pixel will change it.

You still get the event. The page view, the URL, the timestamp, the
referrer, the visitor's IP and ip_country are all recorded and returned as
usual. That data is yours: you are the controller for it, your privacy notice
governs it, and your own analytics are unaffected. What is withheld is the
person we would otherwise attach to it, which comes from our graph and which we
are the controller for.

Such an event comes back with resolved: false and no person fields: no name,
no email, no job title, no employer attributed to that individual.

Company fields may still be present. When we cannot resolve a person, we
fall back to looking up the organization from the visitor's IP, and that path
runs independently of the identity gate. So a withheld event can still carry
company_name, company_domain, company_linkedin_url,
company_employee_count_range and company_revenue_range.

That is deliberate. Those five describe an organization rather than a person, so
they are not personal data about the visitor, and account-level intelligence is
usually the reason you were watching that traffic in the first place. If you
need strictly person-resolved rows, filter on resolved:eq:true rather than on
the presence of a company name.

Two reasons a visitor is not resolved

1. The visitor asserted Global Privacy Control.

gpc is true on the event. GPC is a browser-level opt out of the sale and
sharing of personal information, recognized under the CCPA and CPRA, and it
applies regardless of where the visitor is.

To exclude these events:

gpc:ne:true|gpc:is_null

Both halves are needed. gpc is null before 2026-09-02, as noted below,
and in SQL a null compares as neither equal nor unequal to anything. So both
gpc:eq:false and the seemingly safer gpc:ne:true silently discard every
event from before that date, resolved ones included. Only the explicit
|gpc:is_null keeps them.

Note this excludes GPC events only. It is not a filter for "everything that can
resolve": the geographic exclusion below is a separate reason, with its own
filter.

2. The visitor's IP places them in a country that requires opt-in consent.

These are jurisdictions whose law requires prior consent for the kind of
profile data we would attach. We do not hold that consent for a visitor we have
never met, so we do not resolve them.

Nowhere else is excluded. Traffic from Canada, Brazil, India, Australia, Japan,
Mexico and everywhere else resolves normally, subject to the usual match rate.

Scoping your queries

Prefer a positive filter. Say what you want rather than enumerating what you do
not, and the query keeps meaning the same thing if the list above ever changes:

ip_country:eq:US
ip_country:eq:US|ip_country:eq:CA

If you do need to exclude the list explicitly, exclude nulls back in as well:

ip_country:notin:AT;BE;BG;HR;CY;CZ;DK;EE;FI;FR;DE;GR;HU;IE;IT;LV;LT;LU;MT;NL;PL;PT;RO;SK;SI;ES;SE;IS;LI;NO;GB;CH|ip_country:is_null

To combine both reasons, note that , is AND between groups and | is OR
within one. For eligible US traffic:

ip_country:eq:US,gpc:ne:true|gpc:is_null

For everything eligible to resolve anywhere, exclude the restricted countries
rather than naming one:

ip_country:notin:AT;BE;BG;HR;CY;CZ;DK;EE;FI;FR;DE;GR;HU;IE;IT;LV;LT;LU;MT;NL;PL;PT;RO;SK;SI;ES;SE;IS;LI;NO;GB;CH|ip_country:is_null,gpc:ne:true|gpc:is_null

That reads as (country not restricted OR unplaceable) AND (no GPC OR GPC
unknown). Both null branches are needed, for the reason given above and below.

The trailing |ip_country:is_null is load-bearing. notin follows SQL
semantics, where a null is neither in the list nor not in it, so a bare
notin clause silently drops every event whose country could not be placed.
Those visitors resolve normally, so dropping them undercounts your eligible
traffic by however much of it is IPv6, and nothing in the response tells you
it happened. This is the main reason to reach for the positive filter instead.

Two things this is easy to confuse with

A null ip_country is not an exclusion. Null means we could not place the
address, most often because it is IPv6. Those visitors are resolved normally.
If you want to separate "not resolved because of where they are" from "not
resolved for any other reason", note that the first group always has a non-null
ip_country drawn from the table above.

This is about the request IP, not the person. A German employee browsing
from a New York IP is resolved; a US employee browsing from Berlin is not. The
gate reads ip_country, which is where the request came from. It does not read
personal_country or company_country, which are attributes of the person we
have not identified yet at the moment the decision is made.

Why it works this way

For the event itself you are the controller. For the identity and profile we
attach, we are, because that data comes from our own databases rather than from
your site. Those countries require opt-in consent for that processing, and
consent given to you for your own purposes does not extend to ours. Rather than
rely on a basis we cannot evidence for a visitor we have never had a
relationship with, we do not make the association at all: the identity is never
attached, rather than attached and filtered out later.

gpc starts on 2026-09-02 and is null before it. That null is permanent
and correct: the signal was never read on those events, which is not the same
as a visitor declining to assert it, so it is left unknown rather than
backfilled to false.

DSP event_data: For DSP events, contains a JSON object with content (app_bundle, traffic_type), device (browser, os, carrier, connection_type, make, model), geo (city, country, lat, lon, postal_code, region), and pricing (advertiser_price, bid_price, win_price) sub-objects.

Identity Resolution Fields

Hashed email identifiers used for identity matching. Present on all resolved events.

Email Hashes (multiple algorithms and case variants)

Enrichment-Sourced Email Hashes

Duplicated from the identity graph with emails_ prefix. Populated only when full enrichment data exists.

Person Fields

Contact-level data from the identity graph. Null on unresolved events.

Name and Identity

Email

Phone Numbers

Professional Profile

Social Profiles

Personal Address

Demographics

Company Fields

Firmographic data from the identity graph. Null on unresolved events.

Internal Identifier Fields

Used for identity graph linking and deduplication.

---

Selectable Fields

All 140 fields can be used with the select parameter. Full list for copy-paste:

event_id,pixel_id,organization_id,event_type,timestamp,ts_millis,cookie_id,hem,hems,
user_agent,client_ip,ip,ip_country,gpc,event_data,headers,referrer_url,extra_json,resolved,
address_id,age_range,business_emails,company_address,company_address2,company_city,
company_country,company_description,company_domain,company_employee_count,
company_employee_count_range,company_id,company_id_right,company_industry,
company_linkedin_url,company_naics,company_name,company_name_history,company_phones,
company_phones_dnc,company_related_domains,company_revenue_range,company_sic,
company_state,company_total_revenue,company_zip_code,current_business_email,
current_business_email_validation_date,current_business_email_validation_status,
department,department_2,department_raw,direct_numbers,direct_numbers_dnc,domain_lc,
dpv_code,education_history,email,email_last_seen,email_validation_status,emails,
emails_md5_lc_hem,emails_md5_uc_hem,emails_sha1_lc_hem,emails_sha1_uc_hem,
emails_sha256_lc_hem,emails_sha256_uc_hem,first_name,first_uuid_norm,flattened_uuids,
gender,has_children,headline,income_range_lc,inferred_gender,inferred_gender_unisex,
inferred_years_experience,invalid_emails,is_email_business,is_email_personal,
is_homeowner,is_international,is_married,is_profile_b2b,is_profile_b2c,job_functions,
job_title,job_title_history,job_title_normalized,last_name,last_updated,linkedin_url,
md5_lc_hem,md5_uc_hem,middle_name,mobile_phones,mobile_phones_dnc,
mobile_phones_validation_date,mobile_phones_validation_status,net_worth,
personal_address,personal_address_2,personal_city,personal_country,
personal_country_alpha2,personal_country_alpha3,personal_country_numeric,
personal_email,personal_email_validation_status,personal_emails,personal_phones,
personal_phones_dnc,personal_state,personal_state_code,personal_timezone,personal_zip,
personal_zip4,phones,phones_dnc,photo_url,primary_contact_emails,profile_pid_all,
seniority_level,seniority_level_2,seniority_level_raw,sha1_lc_hem,sha1_uc_hem,
sha256_lc_hem,sha256_uc_hem,social_connections,subdepartments,valid_emails,twitter_url,
github_url,facebook_url,job_title_normalized

---

Notes

Population Rate Patterns

Fields fall into two tiers based on enrichment availability:

• 100% on resolved on-domain events: Core event fields (event_id, timestamp, cookie_id, ip, hem, email, user_agent, etc.). These exist for every resolved on-domain event.
• ~24% on resolved on-domain events: Full enrichment fields (person demographics, company firmographics, phone numbers, etc.). These are only populated when the identity graph has a rich profile match.

The 24% rate reflects on-domain events where only a HEM-to-email resolution occurred without full profile enrichment. The has_valuable_data=true query parameter can filter to only on-domain events with enrichment data populated.

Field Value Formatting

• Names: Stored and returned in lowercase
• Addresses, industries: Stored in lowercase, returned title-cased by the Events API (e.g., "florida" stored, "Florida" returned)
• Boolean-like strings: "y" / "n" or "true" / "false" (not actual booleans)
• Phone numbers: E.164 format with + prefix, comma-separated when multiple
• DNC fields: Positionally aligned with their phone counterpart (e.g., phones: "+1234, +5678" and phones_dnc: "n, y")
• JSON fields: event_data, headers, education_history are stringified JSON
• Hashes: Lowercase hex strings (MD5: 32 chars, SHA1: 40 chars, SHA256: 64 chars)
• Dates: Date32 fields use YYYY-MM-DD format; timestamps use ISO 8601 with microseconds

Endpoints Summary

Each tier route takes the same parameters; the route you call sets both the billable meter and the fields it can return. Use GET /api/v3/events/{tier}/schema to see what a given tier admits.

DSP Event Types

DSP events have different event types than pixel events: