Clearbit Reveal: What IP-to-Company Identification Can and Cannot Tell You

Clearbit Reveal answered a question no other part of the Clearbit product line touched: which company is behind this anonymous website visit. It worked from the IP address, matched it against a map of corporate networks, and returned a company rather than a person. That distinction, company rather than person, is the whole shape of the product and the source of every mistake teams make with it.

This page covers what IP-to-company identification actually establishes, what it structurally cannot, where Reveal sits after the HubSpot acquisition, and how a visitor signal should and should not change an outbound motion.

Where Reveal is now

The dedicated product page is gone. Requesting clearbit.com/platform/reveal returns the same document as the Clearbit homepage, byte for byte: the "Clearbit has joined HubSpot" announcement under a "Clearbit by HubSpot" lockup. The same is true of the pricing URL.

The homepage that now answers at that address does carry the Reveal pitch. Under the eyebrow "Identify hidden intent" it offers to "Turn your anonymous website traffic into real buying intent signals with our best-in-class IP intelligence data". HubSpot's own Clearbit page describes the capability as seeing what companies are visiting your website in the past hours, days, weeks or months.

What is not published anywhere we could read is a statement about Reveal's current availability. No sunset date, no migration notice, no purchase path. The wider context, covered in our page on Clearbit enrichment, is that the capability now lives inside HubSpot's credit-priced products, and that the only account link on any remaining Clearbit surface is a login for existing customers.

What IP-to-company identification actually does

The mechanism is worth understanding because it explains both the strengths and the failure modes.

1. Step 1Capture the IP

   A script on the page records the visitor's public IP address alongside the pages viewed.

2. Step 2Match against a network map

   The IP is checked against a map of address ranges associated with corporate networks, built from registry data and observed traffic.

3. Step 3Resolve to a company

   A confident match returns a company identity, usually with firmographic attributes attached.

4. Step 4Emit a signal

   The result is written to an analytics destination, a CRM or an alerting tool for someone to act on.

Two properties fall directly out of that mechanism.

It identifies an organisation, never an individual. There is no step in which a person is named, because an IP address belongs to a network rather than to a human. Any product built on this can tell you a company looked at your pricing page. None of them can tell you who.

It works well precisely where corporate networks are well defined. A large company with its own address ranges and staff on the office network or a corporate VPN resolves cleanly. The same company's employees working from home on consumer broadband resolve to an internet service provider, which is no signal at all. Coverage therefore varies enormously by company size, country and working pattern, and it has been drifting in one direction since distributed work became normal.

What it cannot tell you, stated plainly

The gap between what the signal contains and what teams read into it is where the value gets lost.

What the signal supports

• A device on this company's network loaded these pages
• Something at that organisation is worth a closer look
• A prioritisation input for an account list
• A reason to research the account properly

What it does not support

• A named person at that company is in market
• A buying committee is evaluating you
• An individual should receive a message about their visit
• Intent, in any sense stronger than attention

The third line in that right-hand column is the one that does real damage. Writing to somebody and referencing a visit you attributed to their employer is a message that reads as surveillance to the recipient, and it is built on an inference the data cannot support: you know a network, not a person, and the person you have chosen to write to may have had nothing to do with it.

There is also a plain accuracy question. A match against a network map is probabilistic, and a shared office building, a coworking space, a corporate VPN terminating in another country or a cloud-hosted browser all produce confident-looking matches that are simply wrong. No vendor in this category publishes a match rate you could compare to another vendor's, because the population being matched is different in each case.

Where it plugs in

Reveal's integration surface was always broader than its own interface, and it is where most implementations lived: analytics pipelines, in-app messaging tools and marketing analytics platforms all carry connectors for it, with the data routed as an event rather than consumed in a Clearbit screen.

That architecture is the sensible one for this class of data, and it is worth keeping whichever vendor you use. A visitor identification signal is an input to systems you already run rather than a destination in its own right. Treating it as a dashboard someone checks is how it becomes a tool nobody opens after the first fortnight.

How to use the signal without breaking anything

Three rules keep this data useful.

Use it to prioritise, not to trigger. A signal that an account looked at your site is a reason to move that account up a list, research it properly and build a genuinely relevant campaign. It is not a reason to fire an automated message within the hour.

Never reference the visit. Whatever you send should stand on its own merits and be something you would have been comfortable sending anyway. If the message only makes sense because you saw the visit, it should not be sent.

Feed it into a new campaign, never into an old one. We run one message per campaign and do not send thread replies or bump sequences. When a signal suggests an account deserves another approach, the correct response is a fresh campaign with a genuinely new angle rather than another step added to a sequence somebody already ignored.

That last rule matters more than it sounds. Visitor identification tools are frequently sold on the promise of triggered follow-ups, which is the exact motion we do not run, and which produces the thread of increasingly insistent messages every buyer recognises.

The measurement problem nobody solves for you

Visitor identification is unusually hard to evaluate, for a reason that is structural rather than anybody's fault: there is no ground truth to check the output against.

With an email finder you can hold back a set of rows whose correct answers you already know, run them through the tool and count how many it got right. With IP matching there is no equivalent, because you have no independent record of who was actually browsing. A vendor tells you a company visited, and the only way to find out whether that is true is to ask the company, which nobody does.

What you can measure is downstream and slower. Take the accounts a tool surfaced over a quarter, and compare their eventual behaviour against a control set of accounts from the same segment that it did not surface. If the surfaced accounts convert no differently, the signal is not carrying information about your market whatever its match rate is. That test takes a quarter and it is the only one that answers the question you actually care about.

The intermediate check worth running early is cheaper: pull a week of identified accounts and read the list. If it is dominated by internet service providers, hosting companies and organisations that could not plausibly buy from you, the map is matching infrastructure rather than buyers and no amount of downstream tuning fixes that.

What it costs, and the honest answer about that

There is no standalone Reveal price to quote, because the pricing URL no longer serves a pricing page and the commercial surface has moved inside HubSpot's editions and credit allowances. Any per-visitor or per-account figure you find on a comparison article predates the acquisition. The detail on how that credit model works is in our page on Clearbit enrichment, and the state of the developer surfaces, including the Reveal API's documentation, is in our guide to the Clearbit API.

If you are shopping the category rather than this product, our Clearbit alternatives roundup covers the field, and it is worth being clear with yourself about which job you are buying for. Visitor identification and contact finding are unrelated problems that get sold in adjacent aisles. Where you need addresses for people you have already identified, that is a finder's job, and the protocol for testing one against your own rows is in our guide to email finder tools. Where you are assembling a stack from scratch, our cold email tools stack guide sets out which categories you actually need at which volume.

The short version

Clearbit Reveal identifies the company behind an anonymous website visit by matching the visitor's IP address against a map of corporate networks. It returns an organisation and never a person, which is a structural property of the method rather than a limitation of the product. Coverage is strongest for large companies whose staff sit on corporate networks and weakest for distributed teams on consumer broadband, so the signal has been getting quieter as working patterns changed. The dedicated product page now serves the HubSpot acquisition notice, no availability statement is published, and the commercial surface has moved into HubSpot's credit model. Used to prioritise accounts it is genuinely useful. Used to trigger messages that reference the visit, it produces outreach nobody enjoys receiving and inferences the data cannot support.

If you would rather see an outbound motion running on your own ICP without assembling a signal stack first, start a free campaign and we will build the list, the copy and the sending infrastructure around it.

Pricing and features verified as of August 2026. Verify current terms with the vendor before relying on them.