Every workspace on your platform is full of domains — referrers on web events, email domains on B2B profiles, UTM sources, account websites in synced CRM objects. Each one is a deterministic join key into a 102M-domain database of pre-computed audience segmentation: demographics, interests, purchase intent, B2B firmographics and 1,667 personas, coded against fixed vocabularies aligned with the IAB Audience Taxonomy 1.1. Your customers are already building this join by hand in their warehouses. This page is about productizing it: licensing the dataset and exposing it inside your CDP as a built-in enrichment source — no cookies, no identity graph, no PII.
Domain-level audience data solves three recurring product problems at once — coverage, compliance overhead, and differentiation of the enrichment catalog.
Safari, Firefox and iOS in-app browsing block third-party cookies by default, so roughly 40%+ of traffic arrives without the identifiers most enrichment integrations depend on. A referrer or source domain is present on the event regardless. Domain enrichment gives every profile some audience context — including the anonymous majority.
The attributes are statements about websites, not people: "this domain reaches an audience skewing 25–34, upper-middle income." No PII exists anywhere in the pipeline, so the capability your customers switch on adds no new identifiers, no consent surface and no cross-site tracking to their stack.
Sophisticated customers already run this exact join in the warehouse behind your platform — the workflow documented in our CDP enrichment playbook. Making it a first-class enrichment source turns a DIY SQL pattern into a differentiating catalog entry: normalize the key once, and every workspace benefits.
Every attribute value is an enumerated code from a versioned vocabulary (v1.0), aligned with the IAB Audience Taxonomy 1.1 — which is what makes it safe to build product UI on top of. Browse every allowed value in the taxonomy reference.
| Field group | Fields | Values your UI can enumerate |
|---|---|---|
| Join key | domain | Normalized registrable domain (eTLD+1) — matches referrers, email domains, UTM sources and account websites after one normalization step. |
| Demographics | age_bracket, gender_skew, income_level, education_level | 8 age brackets, 5-point gender skew, 6 income bands, 7 education levels. |
| Lifestyle | life_stage, household_composition, employment_status, home_ownership, urbanicity | 14 life stages plus household, employment, ownership and urbanicity enums. |
| Interests | interests | INT.* codes — 29 groups, 285 sub-interests. |
| Purchase intent | purchase_intent | PI.* codes — 34 groups, 283 segments. |
| B2B firmographics | audience_type, b2b_company_size_employees, b2b_seniority, b2b_job_function | b2c / b2b / mixed flag plus LinkedIn-standard company-size, seniority and job-function bands. |
| Personas | personas | Deterministic personas from a catalog of 1,667. |
| Quality | confidence, vocab_version | Banded confidence (low / medium / high) and the vocabulary release each row was coded against. |
vocab_version field mean your trait UI, audience conditions and downstream syncs stay stable across quarterly data refreshes — and any vocabulary change is an explicit, versioned event you can release-manage.The integration is deliberately boring: a reference table plus one normalization function. The product work is exposing it well.
License the corpus slice you need and load it as an internal reference table — one row per domain, replaced in place by quarterly refresh feeds.
Ship a platform-level registrable_domain() transform (public-suffix-list based) applied to referrers, email domains and source fields across every workspace.
Surface the joined attributes as computed traits and audience-builder conditions — "referred by domains with INT.personal_finance.* interests", "account domain is B2B, 201–500 employees".
For domains outside the licensed file — or per-URL granularity — call the real-time API. Same codes, same confidence bands, so responses and batch rows are interchangeable.
What customers do with the resulting traits maps directly to workflows we document for practitioners: profiling acquisition sources with referral-traffic audience analysis, scoring target accounts with ABM account-domain profiling, and joining media logs in ad-log enrichment. Each of those pages is, in effect, a feature spec for what your enrichment source enables inside a workspace.
A B2B customer's workspace holds sign-ups referred from a cloud-infrastructure tutorial site. With the enrichment source enabled, the platform attaches this row to the referrer — and every downstream trait can use it:
cloud-tutorials.example
referrer on 4,120 events in this workspace · vocab v1.0
25_3435_44male_leanupper_middleINT.tech_computing.artificial_intelligenceINT.tech_computing.computingPI.software.computer_softwarePI.web_services.web_hosting_and_cloud_computingb2bengineering_softwareThe workspace owner builds a trait — "acquired via developer-audience referrers" — from a dropdown of enumerated codes, routes those profiles to a technical onboarding journey, and reports acquisition mix by audience. Your platform did the join; no individual was profiled anywhere in the chain.
Start self-serve for evaluation; move to a licensing agreement when the data ships inside your product.
| Model | Scope | Best for | Commercials |
|---|---|---|---|
| Self-serve files | Top 100k or Top 1M domains, full attributes, internal use | Prototyping the enrichment source; solutions teams building for a single customer | Top 100k: $490 one-time, $190/quarter refresh. Top 1M: $1,990 one-time, $590/quarter — instant card checkout and download. |
| Data licensing (embedded) | 5M up to the full 102M corpus, hosted inside your platform and exposed to customers; quarterly or custom refresh feeds | Shipping domain enrichment as a catalog feature across all workspaces | Quoted individually by corpus size, refresh cadence and product surface; custom licensing from $15,000/year. Contact us. |
| Real-time API | Per-domain and per-URL lookups, audience segmentation + IAB categorization | Long-tail coverage behind the batch table; on-demand lookups in product UI | Same plans as our API tiers — e.g. Pro at $99/month for 10,000 credits. See API docs. |
The warehouse-side mechanics your customers use today — schema, join-key normalization and SQL patterns. Effectively the spec for your enrichment source.
The broader embedding story for analytics, email and personalization tools — licensing audience data as a feature of someone else's product.
Firmographics plus audience character on account domains — the same reference table powering ICP scoring and account prioritization products.
Three common models. Product teams prototype with a self-serve file (Top 100k at $490 or Top 1M at $1,990, instant download) mounted as a reference table. For a shipped feature, a data licensing agreement covers redistribution: you host the dataset inside your platform and expose it to customers as an enrichment source, with quarterly refresh feeds. For long-tail domains or per-URL granularity, the real-time API answers ad-hoc lookups against the same vocabularies, so batch rows and API responses are interchangeable.
The dataset contains no PII anywhere in the pipeline. Attributes describe the audience a domain reaches, inferred from the domain's content — they are statements about websites, not people. When a customer joins those attributes onto profiles they already lawfully hold, the enrichment adds no new identifiers, no cross-site tracking and no individual-level claims, which typically makes the data-protection review far simpler than identity-graph or onboarded-data integrations.
Embedding the data in a product you sell — hosting it in your platform, exposing it to customers, or shipping derived traits — is covered by a data licensing agreement quoted individually, based on corpus size (from 5M domains up to the full 102M), refresh cadence and how the data surfaces in your product. Custom licensing starts from $15,000/year. Self-serve tiers (Top 100k, Top 1M) are licensed for internal use and evaluation — compare them on the pricing page, then contact us for an embedded quote.
Every attribute comes from a fixed, versioned vocabulary (currently v1.0) aligned with the IAB Audience Taxonomy 1.1 — enumerated codes, not free text. A vocab_version field on every row ties it to the release it was coded against. That means trait builders, segment definitions and downstream syncs you expose to customers keep exactly the same meaning across quarterly data refreshes, and any future vocabulary change is an explicit, versioned event you can handle in your product. The full code lists are on the taxonomy page.
Look up any domain in the interactive demo, pull a self-serve tier to prototype the enrichment source, and talk to us when you're ready to ship it to customers.