AI Adoption GuideSalesProspect
Website visitor de-anonymization
An identity graph reveals which target accounts browse pricing and product pages, using tools like RB2B or Warmly.
Sales processProspectQualifyDiscoverProposeNegotiateCloseHandoffRenew
By Don, DoneThat’s AI coach · updated
The useful output is which ICP accounts hit pricing or product
The job is speed: know which target accounts were on pricing or product pages while the visit is still recent enough to act on.
Most of the value is company-level. An identity graph matches an otherwise anonymous session to a firm, often from IP, network, or a pixel. Person-level names appear in some products. Treat those as a hypothesis. The IP of an office, a VPN, or a shared network does not prove a named VP was the one scrolling pricing.
Products in this class include RB2B, Warmly, 6sense, and Clearbit. They are a class, not a ranking. They do not all resolve the same way. Some are built around company-from-IP. Some try to attach a person. Match coverage depends on traffic mix, company size, remote work, and region. Vendors do not publish comparable identification rates, and this page does not invent one. Buy the class for accounts that touched high-intent pages, not for a guaranteed name.
A homepage session, a careers bounce, or a blog skim is not the same signal as time on pricing or product. Page path is the filter.
If they are still on the site, an AI inbound chat qualifier can qualify in-session. This use case is the after-they-left path: a company (sometimes a person), not a conversation.
Score ICP accounts, then drop the rest of the traffic
Do not put every identified company on a BDR queue. Score the match against the ICP first, then against page intent.
Score it so the owner can read the reason in Slack or the CRM:
- ICP fit. Firmographics and disqualifiers you already trust. If you lack a closed-won profile, fix that with ICP lookalike account discovery before you staff a visitor queue. A non-ICP company on pricing is still not your buyer.
- Page intent. Pricing, product, comparison, integrations, and security pages outrank the homepage, the blog index, login, and careers. One pricing view from an ICP account beats a pile of unidentified homepage hits.
- Recency and depth. A same-day visit with more than a bounce is more useful than a two-week-old session. Repeat visits in a short window beat a one-off.
- Suppression. Customers, open opportunities, partners, competitors, do-not-contact, and anyone sequenced this quarter stay off the prospecting list. An existing customer on pricing is an AE or CS cue (expansion, a SKU question, a renewal risk), not a cold BDR sequence.
Treating every visit as buying intent is the usual failure. Competitors check pricing. Students collect decks. Current-customer employees look up a SKU. Shared office networks inflate "accounts." If the score cannot say why this account, why this page, why now, it is noise.
A pricing visit is stronger next to an independent reason to write. Pair it with buying-signal trigger monitoring (hiring, funding, a job change, a filing) instead of treating the pixel as the whole story.
Route the account, then research a hook that is not the visit
Once an ICP account clears the score, route it to the owner. Then research. Then outreach. Do not skip to a call.
Route first. Territory, named-account ownership, and round-robin need to be in the CRM, not in a Slack thread. If two BDRs both get "Acme viewed pricing," you will double-touch the account. If the AE already owns it, the BDR should not open a cold sequence. Put the visit on the opportunity or the account, with page path and timestamp, and stop.
Research a hook you could defend without the pixel. The visit is your internal reason to look. It is a poor external first line. "I saw you on our pricing page" reads as surveillance to many buyers, and it is often wrong about who was on the page. Use public, openable material: a hiring spike, a product launch, a filing, a post the contact actually wrote. Hyper-personalized outbound copy is the drafting step after you have a real hook. If they take a meeting, fold the public context into a pre-call account briefing. Do not brief the AE with "they were on pricing" as the only fact.
Then outreach, with a human still deciding. Speed here is a researched touch by the right owner while the visit is fresh, not a same-hour blast to a guessed name.
Worked example: Northwind Health on pricing
The following is an illustrative scenario, not a case study and not reported results.
A BDR at a usage-based billing vendor gets a Slack alert: Northwind Health, pricing page, session longer than a bounce, suggested contact Jordan Hale, VP Finance.
The wrong move
Dial Jordan and say they were just on pricing. The match is company-level. Northwind's office network can represent anyone: an analyst, procurement, IT, a contractor. Jordan may never have opened the page. Calling a named employee from a company hit is how this motion earns a complaint, a block, or a "how did you know that" that you cannot honestly answer.
The score, route, and research loop
- Score. Northwind is a mid-market health system in the ICP (employee band, industry, US). The page is pricing, not careers. Salesforce shows a named account, no open opportunity, last meaningful touch eight months ago. Score: work it.
- Route. The account owner is Priya, not the BDR who happened to be in Slack. The visit is written to the account with path and time. The BDR does not start a sequence.
- Research. Priya finds a recent job post for a revenue-cycle operations lead and a public mention of claims-denial work in an investor letter. She does not mention the website. She writes the VP of Revenue Cycle (the buying role for this product), not Jordan, unless CRM history already shows Jordan as a champion.
If the same session had been a careers-page visit from a non-ICP staffing firm, the queue would drop it. If Northwind were already in late-stage procurement, the visit would go to the AE as a timing cue, not as a new outbound.
A name on the alert is not consent to call that person
Honor privacy and cookie rules before you turn the pixel on, not after the first complaint.
Company-level identification still processes personal data in many jurisdictions once you store a session, an IP, or a device identifier. Person-level identification is a higher bar. Cookie banners, consent logs, and opt-out have to match what the pixel actually does. If a visitor declines non-essential cookies, do not identify them through a second channel and pretend the banner was theater. EU and UK traffic, and some US state laws, need a lawful basis and a legal opinion. Remote workforces and consumer ISPs make office-IP matching weaker. That is a coverage issue, not a reason to guess harder at names.
An alert is not consent to call a named employee. Consent to marketing, a lawful basis for email, and a right to be called are separate questions from "the vendor printed a name next to a company." Do not put guessed mobile numbers on a dialer. Do not email a personal address the graph invented. Do not tell the contact you watched them browse.
Write the rules reps will actually follow:
- Reference the visit internally (CRM, Slack, the AE). Do not reference it in the first line unless you have a policy legal has signed and a person-level match you trust.
- Person-level names require a second check: is this person in CRM, on the site as a form fill, or only in the vendor's graph? If only the graph, treat it as a maybe.
- Regions where you cannot run the pixel stay dark. Do not make up for it with purchased lists of employees at the same companies.
- Complaints, "how did you get my number," and opt-outs are incidents. Pause the motion. Do not raise volume.
The speed you want is ICP accounts on pricing and product, in the owner's queue the same day, with a hook that does not depend on admitting you identified them. Everything else is a faster way to annoy people who never asked to be found.
Is this worth automating for you?
Whether this pays back depends on how much time it takes your team today. Most teams estimate that from memory, and the estimate is usually wrong in one direction or the other.
DoneThat reconstructs where the time actually went, with no timers to forget, so you can measure the baseline before committing to a project and check the gain afterward.
Measure the baseline first