RB2B

A matching product that makes no artificial intelligence claim, and the grade records that rather than penalising it. What happens when a visitor arrives is a lookup: a script observes the visit, a signal is checked against a pre existing identity co-op, and if a match is found the resolved profile is pushed to a messaging channel. Filtering by job title, company size or industry afterwards is a rule the customer sets.

None of that is inference in any meaningful sense and the vendor does not claim it is, which is worth stating plainly in a category where almost every competitor has renamed itself around the technology. The resolution itself is probabilistic rather than deterministic, since a match is a judgement about whether a signal corresponds to a person, but probabilistic matching predates the current vocabulary by decades and is not what this axis is asking about.

A buyer evaluating this product is buying coverage and speed, not a model, and should compare it on match rate and latency rather than on capability claims. Ask whether any inferred scoring or ranking is applied to resolved visitors, or whether ordering is purely chronological.

RB2B never contacts anyone itself; the controls decide who reaches a person and where. Every plan caps delivery at a monthly number of resolutions, with overage billed per resolution on paid plans. On Pro and Pro+, Hot Leads filters delivery by title, company size and industry, and Page Suppression excludes traffic by domain, URL or list, so internal staff, competitors and irrelevant industries never reach Slack or the CRM.

Individuals can remove themselves through the database opt out run by Retention.com. Downstream action is set by the customer: a webhook, Zapier or the Apollo integration can start automated outreach on a match, and nothing published describes a review step or a stop control for a bad batch of matches flowing into those tools.

Little of this axis applies in its usual form, and the question that replaces it is unanswered. There is no generative capability, no assistant and no agent, so the model disclosure questions this axis normally asks have nothing to attach to, and the vendor does not invite them by claiming otherwise. The equivalent question for a resolution product is accuracy, and it is the one that matters, because the output is an assertion that a specific named individual visited a specific page.

Nothing published states a confidence level for a match, a false match rate, or what evidence supports a resolution, and the difference between the two upper tiers is described only as a premium resolution path drawing on additional sources without naming them or explaining what changes.

A wrong match here is not a degraded recommendation, it is a representative contacting the wrong person and telling them what they were reading, so the error rate is the number a buyer most needs and cannot get. Ask what the false match rate is, what confidence accompanies each resolution, and what the premium resolution path adds.

The vendor publishes its own coverage ceiling, which is rare, and publishes nothing about how it was measured. Its knowledge base states that the free tier identifies roughly fifteen to twenty percent of traffic at company level, that the two middle tiers add contact level identification for primarily United States visitors taking total coverage to roughly thirty to forty percent, and that the top tier reaches higher through a premium resolution path.

Telling a prospective buyer upfront that most of their traffic will remain anonymous is the opposite of how this category usually markets itself and it should count in the vendor's favour. What is missing is everything that would let a buyer trust or reproduce those figures: no population, no period, no definition of what counts as an identification, and no explanation of why the ranges are as wide as they are, which matters because the difference between the bottom and the top of a fifteen to twenty percent band doubles the cost per useful contact.

Independent accounts add a material qualifier the vendor does not, which is that resolution depends heavily on how much of the underlying co-op a particular site's audience has previously encountered, so the published range may not describe any specific buyer. No customer outcome study with a stated cohort was located. Ask how coverage is measured and across what traffic, and what determines where a given site falls in the range.

RB2B publishes a compliance guide for the customer deploying its script. It states that person level resolution is limited to United States traffic because the underlying database holds only profiles matched to US home addresses, and explains the California disclosures a customer may owe, including notice that personal information is shared for cross context behavioral advertising and routes for access and deletion.

It supplies recommended privacy policy language that points consumers to an opt out page, a data protection addendum that covers the CCPA and an information security addendum, and suggests a banner notice for teams that want to go further. The guide does not address the state wiretap and session recording claims that website tracking scripts attract, or whether the script honors Global Privacy Control signals.

RB2B states its legal position plainly: the identity database holds only people matched to US home addresses, person level resolution runs only on US traffic, and the consumers in the database agreed to share their information for third party marketing.

A data protection addendum is published in full, with a subprocessor list, 15 days of notice before a new subprocessor and a 10 day objection window that can end the agreement, and each party honors opt out and deletion requests the other passes on. Consumers can opt out of the database directly, and data submitted by customers is used for their own account and not sold. How long a visitor's page history is kept, and what an identified person can learn about it, is not stated.

The identity data behind RB2B is built and maintained by Retention.com, its parent company, and the same layer is sold directly through an API, warehouse delivery and flat files. Retention.com describes its database as consumers who agreed to provide their information for third party marketing, matched to US home addresses, and says it releases a person's data to a brand only after that person has shown interest, generally by visiting the brand's website. The parties that collected that agreement are not named, and nothing explains how a visitor is matched to a LinkedIn profile, the field a sales team acts on first.

The product's principal deliverable is data belonging to a platform it does not describe a relationship with. Every resolution is delivered as a professional network profile, independent accounts describe matching as running primarily against that platform's data, and the entire value proposition is that a representative can open the profile and act.

Nothing published states how that data is obtained, whether through a sanctioned interface, a licensing arrangement or otherwise, and no conformance position, terms reference or continuity statement appears anywhere. That is the pattern this axis treats cautiously by default, and it carries a specific continuity risk rather than an abstract one, since a product whose output is a profile link on one platform depends on that platform's continued tolerance for the arrangement.

The remainder of the surface is unremarkable in the good sense: destinations are messaging tools, customer record platforms, an automation service and enrichment products, all reached through their own documented routes, and nothing scrapes, automates an account or drives a browser extension. Ask how professional network profile data is obtained and under what terms, and what happens to the product if that access changes.

No model layer exists, and the stewardship question underneath this axis applies with full force regardless. The platform accumulates resolved identities of people who never identified themselves, attached to the pages they read and the time they spent, and does so continuously for every customer running the script.

Nothing published states how long those records are retained, whether they persist after a customer cancels, whether they are aggregated across customers, or whether a person resolved on one customer's site becomes easier to resolve on another's.

That last question is the one that matters most and follows directly from the co-op structure: if identifications feed back into the shared pool, then every deployment makes the pool more capable and every buyer is contributing the people who visited them. One comparable product in this category states explicitly that its customers do not become contributing members of its pool; nothing equivalent was found here in either direction.

No governance document or independently audited management standard was located. Ask whether resolved visitors are contributed back to the shared pool, how long resolution records are retained, and what happens to them when a customer leaves.

RB2B hands a named visitor and their page history to a salesperson, so the disclosure question is what the visitor is told. The compliance guide gives customers recommended privacy policy text that names the service and links to Retention.com's consumer opt out page, and suggests a banner notice, so disclosure is available to any customer who adopts it and is not built into the script. No software talks to the visitor; a person decides whether and how to reach out. RB2B takes no position on Article 50 of the EU AI Act, and its person level product runs only on US traffic.

A short destination list, gated so that the cheapest paid tier gets almost none of it. Named connections cover two messaging platforms, two customer record systems, an enrichment product, an automation service, a prospecting platform, generic webhooks and file export, which is a sensible set for a product whose job is to deliver a signal somewhere useful.

One third party account puts the total above fifty applications; the vendor's own material names the ones above and no enumerated directory was located to check the larger figure against. The gating is the substantive point. The entry paid tier delivers to a messaging channel and nothing else, with no email addresses and no integrations, so a customer at that level is copying names out of a channel by hand.

Everything that makes the signal operational, meaning contact details and every destination beyond messaging, requires the tier above. For a product that produces a signal and explicitly does not act on it, the route out is the product, and reserving it for the second tier means the first tier is closer to a demonstration than a deployment. Ask for the enumerated integration list and confirm which destinations are available at the tier being quoted.

Nothing on hosting, region, tenancy or recovery was reached on this pass, and no vendor infrastructure statement was located. One adjacent fact is published and should not be mistaken for an answer: person level resolution is restricted to United States traffic, which describes where the product will identify someone rather than where any resulting record is stored or processed. Those are different questions and only the first is addressed. The gap has a specific shape here.

A customer outside the United States can still deploy the script and will still receive company level identification on their non United States traffic, so European visitor records exist in the system even though European individuals are not resolved, and nothing published states where those records live or under what transfer arrangements.

A script running on every page of a customer's website also makes availability a customer facing concern rather than a back office one, and no uptime position or recovery objective was located. Ask which provider and regions host resolution records and visitor history, what happens to non United States visitor data, and what availability commitment applies to the script.

RB2B states SOC 2 Type 2 certification and CCPA compliance and links a trust profile hosted on SecurityPal under Retention.com, which lists SOC 2 Type 1 and Type 2 and CCPA and was last updated on 31 March 2026. An information security addendum and a data services agreement are available, the addendum committing RB2B to a written information security program. The trust profile carries the certification names without report access, audit periods or a description of controls.

RB2B publishes its whole price list. The free plan identifies companies only, at 150 resolutions a month. Starter is $79 a month for 300 person level resolutions delivered as LinkedIn profiles to Slack or Teams. Pro starts at $149 for 600 resolutions with business emails and every integration, stepping to $249 for 1,250 and $349 for 2,500. Pro+ starts at $199 for 600 with premium resolution and climbs through published volumes to $849 for 12,500 and $50,000 for 2.5 million.

Overage is 45 cents a resolution on Starter and 25 cents above it, extra domains cost $99 a month for up to five, and every account gets a seven day trial of every feature with no card. Volumes above 12,500 a month are sized with sales, with the ladder itself on the page.

The money position on leaving is published with unusual candour and the data position is not addressed at all. The vendor's own knowledge base states plainly that unused credits are typically forfeited immediately on downgrade, that in some cases they may remain for up to a month but will not roll forward, that refunds for unused credits are not provided, and that contact level access is removed the moment a customer drops to the free tier.

Most vendors leave all of that to be discovered at the point of downgrade, and stating it in a help article that a prospective buyer can read is worth crediting even though the terms themselves favour the vendor. Nothing is published about the data.

No export scope, format, retention period or deletion timeline was located for the accumulated record of resolved visitors and their page histories, which for a customer running the script for a year is a substantial behavioural dataset about named individuals. File export exists as a feature at the upper tiers, so a route out of the current month's records exists for those customers, and nothing states whether historical records are included or what happens to them after cancellation. Ask what exports at cancellation and in what format, whether historical resolution records are included, and what is deleted and when.

The product operates no sending infrastructure, so this axis applies by scope alone and the grade records that rather than a shortfall. Nothing leaves the platform except notifications into the customer's own messaging channel and records pushed into their own systems. There is no campaign capability, no sequencing, no mailbox and no sending reputation at stake. One adjacent point is worth a buyer's attention because it transfers risk rather than eliminating it.

The upper tiers deliver business email addresses for resolved individuals, and the natural next step is pushing those addresses into a sequencing tool, at which point mail goes to people who never gave the sender their address and never asked to be contacted.

Nothing in the record delivered indicates that a contact was resolved from a website visit rather than obtained by consent, so a downstream system treats both the same way, and the complaint exposure lands on the customer's sending domain rather than anywhere near this vendor. Ask whether resolved contacts are marked as such when pushed to a record system, so that downstream sending can distinguish them from opted in contacts.

The boundaries are stated in numbers and one of them is stated against the vendor's own interest. Geographic coverage is explicit and unusually blunt: person level identification works on United States traffic only, with company level identification alone everywhere else, and the vendor gives the reason rather than leaving a buyer to discover it after signing. A European buyer learns in one sentence that this is not their product.

Coverage is quantified too, with published resolution ranges by tier, so a buyer with a known traffic volume can compute roughly how many identified people they would receive before paying anything. The commercial ladder reinforces the position, running from a permanent free tier to a few hundred dollars a month, which puts it within reach of a founder testing the idea rather than requiring a procurement cycle, and reviewers consistently place it with small teams and founders who already have traffic.

Two things hold it below the top band. The vendor states no minimum traffic volume at which the product becomes worth deploying, which is the calculation that actually decides fit given that resolution is a percentage of visitors. And a material limitation comes only from reviewers, which is that matching depends on the professional network where the target audience must be active, so sectors with low presence there resolve at materially lower rates. Ask what monthly traffic volume the entry tier assumes, and how match rates vary by industry.