Most visitor identification tools will happily identify your existing customers, your current employees, and people who have explicitly opted out. That is a compliance risk and a sales-experience problem. RB2B and several other tools in the category do not offer suppression at all.
I am George, founder of Leadpipe. Suppression is one of those features nobody notices until it breaks, at which point it is the only thing anyone notices. This post is about how to think about suppression conceptually, why it belongs at the graph layer rather than as a dashboard filter, the failure modes you have to design against, and what the right behaviors look like in practice.
What suppression actually is
A suppression list is a set of identifiers that should never be returned to a customer as an identified visitor, even if the identity graph has a match. The canonical use cases:
| Use case | Why suppress |
|---|---|
| Existing customers | You don’t need an “identified visitor” alert for your own account execs |
| Your own employees | They visit your site constantly, every visit would be noise |
| Explicit opt-outs (CCPA, state data-broker laws) | Regulatory requirement, not optional |
| Competitor domains | Competitors browse your site, you don’t want that data flowing to your reps |
| High-risk regions or industries | Internal compliance rules may require exclusions |
| Test traffic | QA, load tests, synthetic users should not count against credits or populate dashboards |
Without suppression, every one of those categories leaks into your CRM, your Slack alerts, and your outbound automations.
Why suppression has to live at the graph layer
The lazy implementation is to apply suppression as a post-processing filter on the dashboard. Match the visitor, then check the suppression list, then hide the record in the UI. That approach is wrong for three reasons.
1. The data still exists
If suppression is a UI filter, the identified record was still produced, still logged, still counted against your credit pool, and possibly still fired as a webhook. An opted-out user got identified, and the identification happened even if you never looked at it. That is a bad answer on the compliance side.
2. Webhooks are already gone
Webhooks fire on identification. If suppression runs after identification, the webhook went out before the filter kicked in. Your downstream systems, CRM, Slack, Clay enrichment, AI SDR, already saw the record. Walking that back is not realistic.
3. Credit accounting is wrong
You paid for the identification. Whether the UI hides it or not, the credit was consumed. On a 500-identifications-per-month Pro plan, burning credits on suppressed records is real money.
The right place to apply suppression is at the match-decision layer, before the identification event is emitted. We suppress at the graph, not at the dashboard.
What you should be able to suppress on
A useful suppression system supports multiple identifier types. A raw email address is the obvious one, but it is not enough.
| Identifier | Use it for |
|---|---|
| Raw email address | Known customers, employees, opt-outs with a confirmed email |
| Email domain | Suppress everyone from a competitor or partner company |
| Hashed email (HEM, SHA256/SHA1/MD5) | Upload a customer list without exposing raw emails to a vendor |
| Company domain | Suppress at the firmographic level |
| Person record ID | Surgical suppression of a specific person in the graph |
| IP range | Suppress your office network so internal traffic never counts |
The HEM case matters most for enterprise buyers. Uploading raw customer emails to a third-party vendor is a compliance non-starter for many teams. Uploading hashed emails is trivially safe and still works, because a HEM-anchored graph can match on the hash directly without ever seeing the cleartext email.
The three suppression modes
Different use cases need different suppression behaviors. A serious system supports all three.
Hard suppression
The record never exists as far as the customer is concerned. No webhook, no dashboard row, no credit charged. This is what you want for opt-outs and known customers. It is the safest default.
Soft suppression
The record is returned but flagged as “suppressed” with a reason. This is useful for internal audits. You want to see that your office network is generating traffic, but you do not want those rows cluttering the outbound pipeline.
Domain-level versus person-level
Suppressing a domain suppresses every person at that domain. Suppressing a person suppresses only that person. You need both. Most customer-managed suppression is domain-level. The person-level case is real but rare, usually for surgical compliance flags.
Opt-out suppression: the compliance case
CCPA gives California residents the right to opt out of the sale or sharing of their personal information. Similar rights exist under state data-broker laws in Texas, Vermont, and Oregon, where Leadpipe is registered.
The mechanics:
- A resident submits an opt-out request through the Leadpipe privacy portal or through a state-authorized opt-out mechanism.
- The request enters the suppression queue. Identifiers (usually email, sometimes phone or postal address) are verified and resolved to person records in the graph.
- The person is flagged as suppressed. Future identifications against that person are suppressed at the match-decision layer.
- The action is audited. The suppression flag is logged with timestamp and source, so the compliance team can demonstrate handling if asked.
On the GDPR side, the default for EU and UK visitors is company-level only. Person-level identification requires affirmative consent. That is a different mechanism than suppression, but it sits in the same compliance architecture. See GDPR-compliant visitor identification for the details.
The customer-managed suppression list
Separate from regulatory opt-outs, every customer has their own suppression list they manage themselves. The most common entries:
- Their own employee domain. The pixel on your own marketing site would otherwise identify every employee who browses the pricing page. Nobody wants those alerts.
- Existing customer domains. If Acme Corp is already a customer, identifying Acme employees as new prospects is noise for the account team.
- Partner and vendor domains. Integration partners browse your product pages. They are not leads.
- Competitor domains. Suppress what competitors are researching. Their visits will still appear in Orbit intent data on the off-site side, where the exposure is different.
The suppression list is CRUD via both the dashboard and the API. That matters for multi-tenant platforms. If you are building a white-label dashboard for agencies, each client needs their own suppression list, and the suppression API lets you wire that up programmatically.
Suppression in the webhook path
Webhook delivery is where suppression bugs hurt most. Once a webhook is out, it is out. Your Clay table, your HubSpot workflow, your Slack alert all acted on it.
The rule: suppression is evaluated before webhook dispatch, not after. If a match would be suppressed, the webhook never fires. That means the suppression list has to be loaded into the hot path of match evaluation, not fetched on demand per identification.
The cost of that design decision is that the suppression list has to be available with low enough latency to sit in the match-decision path. That is an engineering constraint. The alternative, firing webhooks and then trying to un-fire them, is not a real option.
For the webhook context, see the webhook payload reference and the self-serve identity resolution API.
What competitors miss
Suppression is one of the most visible gaps in the visitor-identification category.
| Tool / Vendor | Suppression coverage |
|---|---|
| Leadpipe | Hard + soft, domain + person, HEM-supported, hot-path evaluation |
| RB2B | Limited or absent in published feature surface |
| Several smaller probabilistic tools | Dashboard-level filter only, not graph-layer |
| Enterprise identity platforms | Typically supported but at much higher price point |
The compliance exposure of running visitor identification without suppression is non-trivial. You are firing webhooks on people who may have opted out, on customers your team is already actively engaged with, and on competitors who are scoping your product. Each of those creates a different problem. Together they create a CRM hygiene mess that is expensive to clean up.
For the broader CRM hygiene argument, see Salesforce is full of bad data.
Tradeoffs we made
Hard suppression over soft by default
New suppression entries default to hard suppression. Soft is opt-in per entry. The reason: the failure mode of hard suppression (a record does not show up) is survivable. The failure mode of soft suppression (a record fires a webhook when it should not have) is not.
Domain over person by default
Most customer-managed suppression is at the domain level. The person-level case is real but rare. Optimize the UX for the common path. Keep the person-level API available for surgical cases.
Centralized list over per-pixel lists
One suppression list per account, applied to all pixels under that account. The alternative (per-pixel lists) is more flexible but produces mistakes where one pixel suppresses correctly and another does not. Multi-tenant platforms get per-tenant overrides. Single-account customers get a single list.
Suppression does not affect Orbit intent
Important nuance. Suppression affects visitor identification (who showed up on your site). It does not affect Orbit intent data, because Orbit is a different product with its own consent and data model. Suppressing your customer Acme from on-site identification does not mean Acme’s intent signals disappear from your outbound audiences. The two surfaces are separate, on purpose.
What I would prioritize today
Three improvements that matter at scale.
- Uniform identifier normalization across UI and API. Lowercase, trim, plus-addressing, internationalized domains. Edge cases where the UI and the API hash slightly differently are the bug class that creates the most support tickets. Consolidating normalization is worth the work.
- Better bulk-upload tooling. Enterprise customers want to upload large suppression lists from their CRM on a regular cadence. Faster, more observable bulk uploads are on the list.
- Suppression audit log as a first-class surface. Today the log lives in support tooling. Exposing it to customers directly (when was an entry added, by whom, what has it suppressed) makes compliance reviews much easier.
What this means for customers
Suppression is the feature you only notice when it is missing. Tools that do not offer it leave you with a compliance exposure and a CRM full of your own employees. Tools that do offer it put it in your hands with APIs, dashboards, and multi-identifier support.
The framing that matters: every identification is a policy decision, not an automatic output. Suppression is how customers set that policy. A vendor that treats suppression as an afterthought has a different view of who is in charge of the data than a vendor that treats it as a first-class surface.
Every plan ships with the same identity graph, 23 REST endpoints, webhooks, and a 27-tool MCP server. Start in 5 minutes →
