Visitor ID Plus Enrichment Platform: One Graph Wins
Run identification and enrichment as two vendors and you pay for the match between them forever.
A visitor ID plus enrichment platform does two jobs against one identity graph: it resolves anonymous website visitors into real people, then appends attributes to those same people from the same underlying data. Most teams buy this as two products, a visitor ID vendor and an enrichment vendor, and then pay for the join between them forever. Exact Match runs both sides on one graph. Site ID identifies 25-40% of verified human visitors, bots excluded, and Clean ID matches, dedupes and enriches any list deterministically across 9 data domains. Same identity anchors, same daily refresh, no second matching step in the middle.
Last updated: September 2026
The join is the whole story, and almost nobody prices it
Here's the part that gets skipped in every evaluation I've watched. When your visitor ID vendor and your enrichment vendor are different companies, the handoff between them is itself a matching problem.
Vendor A resolves a session to a person using its own anchors and its own confidence rules. You then hand that person to Vendor B, which has never seen them, and ask it to find the same human in a different database. Every record that doesn't survive that second lookup silently disappears from your funnel. Nobody reports it, because neither vendor is measuring the other's output.
You end up paying twice and matching twice to get one usable record.
That's the little-known part. Two vendors with good individual match rates can produce a bad combined one, and the combined number is the only one that affects your campaigns. If you've suspected your real-world numbers were worse than either vendor's quoted rate, you were right, and that's why the two never reconciled. Nothing in either vendor's reporting is built to show you the gap.
What "one graph" means when you get specific
"Unified platform" is a phrase that has been worn smooth by overuse, so here's what it concretely means in this case.
Exact Match matches deterministically, verifying against identity anchors like name, email, phone and address, rather than scoring probability that two records describe the same person. The graph covers 250M+ verified U.S. consumer profiles and 60M+ business records, refreshed daily. Four products sit on top of it:
- Site ID identifies anonymous website traffic, 25-40% of verified human visitors with bots excluded, returning contact and demographic profiles in real time
- Clean ID takes any uploaded customer or prospect list and matches, dedupes and enriches it across 9 data domains
- Audience ID builds and exports targeted segments across 80,000+ targeting clusters
- Predict ID uses Bayesian behavioral modeling to surface people who are in-market now rather than assigning a static historical score
An identified visitor doesn't get re-matched to be enriched. It was already resolved against the graph the enrichment comes from. That's the difference, and it's structural rather than a feature you toggle on.
The clearest illustration is cross-entity targeting: entity_traits joins B2B professional and employer filters with B2C consumer behavioral data at the identity level, not merged after the fact. You can target someone by job role and consumer lifestyle profile in a single query. Two separate vendors cannot produce that answer at all, no matter how good each one is, because the join has to happen where the identities live.
Worth reading alongside this: the visitor id plus enrichment piece covers the workflow mechanics, website visitor identification defines the terms if the vocabulary is new, and the website visitor identification tool comparison walks through the broader buying criteria.
What comes back, specifically
Enrichment is a word that hides enormous variation in output quality, so specifics matter more than the label.
Across 9 data domains you get demographics, behavior, interests, financial attributes and intent signals. Segment building runs on 80,000+ targeting clusters through trait_search, trait_get, group_entities_by_trait and calculate_trait_lift, so you can score a segment rather than just assemble one. Resolution runs through entity_resolve, entity_enrich, entity_relations and entity_traits. Whole-file work goes through resolve_and_enrich_rows with signed upload and download URLs, which processes an entire list in one call instead of row-by-row.
Output lands through background export jobs with CRM-specific column templates. I'll say plainly why that unglamorous feature keeps earning its place: column remapping is where enrichment workflows die. Not at the data step. At the part where somebody opens the export at 6pm and starts renaming headers so the import will accept it.
The same surface is available natively as an MCP server, so the identity graph, trait search and exports can be driven from Claude, from Claude Code through a data-scientist plugin, or from a Slack bot. If your team already works in an agent stack, you don't need a separate dashboard habit to use any of this.
Where a two-vendor stack still makes sense
I'd rather be useful than absolute about this, so three honest cases.
If your existing enrichment contract has real time left on it and it's performing, ripping it out to consolidate is a migration project dressed as an optimization. Run the visitor ID side first and measure the combined rate you're actually getting before you decide.
If your audience is mostly outside the U.S., the consumer graph here is built around 250M+ verified U.S. profiles, so weigh that before consolidating anything.
And if your requirement is a single narrow lookup, one field, one source, a full platform is more than the job needs.
For agencies the calculus tips differently, and that's the one case I'd push on. Subaccounts give each downstream client a scoped child identity under one parent API key, with real data isolation, its own fair-share rate limit and export concurrency, and billing visibility hidden from the client. Running that across two vendors means reconciling two permission models and two invoices per client, every month. Consolidate and you could finally run one permission model and hand a client their data without a reconciliation pass first.
What it costs
One flat Unlimited plan. Every product, every feature, unlimited credits. No per-seat fees, no tier upgrades, and no overage charges, because there are no credits to overrun. If you're tired of a seat fee stacked on top of a credit meter, that stack is the specific thing this pricing shape removes. API and MCP access defaults to 30 requests per minute and is raisable by agreement. The rate is set on one short call, so schedule a consultation to get a figure for your team.
If you're coming from the B2C side of this and want the identification half explained on its own terms first, b2c website visitor id covers it.
Frequently Asked Questions
What is a visitor ID plus enrichment platform?
It's a platform that resolves anonymous website visitors to real people and appends attributes to them from the same identity graph, rather than splitting those two jobs across separate vendors. The practical benefit is that no second matching step sits between identification and enrichment, which is where records quietly drop out of a two-vendor stack.
Why does running both on one graph matter?
Because every handoff between vendors is another match, and another match is another opportunity to lose a record. It also makes some queries possible that otherwise aren't. Joining B2B employer filters with B2C behavioral traits at the identity level, through entity_traits, can't be reproduced by merging two vendors' outputs after the fact.
How many visitors will actually get identified?
Site ID identifies 25-40% of verified human visitors, with bots excluded from that count. The range moves with traffic mix, so paid social, organic search and email traffic won't land in the same place. Most of your traffic still stays anonymous, which is worth planning around rather than discovering later.
Does this work for an agency managing multiple clients?
Yes. Subaccounts create scoped child identities under one parent API key, each with isolated data, its own fair-share rate limit and export concurrency, and no visibility into billing or credits. The flat plan covers it, so adding clients doesn't add per-seat fees or trigger a tier upgrade conversation.
Get Started: Unlimited
One plan, everything included: every product, every feature, and unlimited credits. Schedule a consultation and we will build pricing around your needs.