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.

Two real constraints on what reaches a person, and nothing governing who gets identified in the first place. The first constraint is architectural: the credit allowance is a hard ceiling on how many visitors are resolved and delivered in a month, so volume cannot run away, and the vendor publishes what happens at the limit rather than leaving it to be discovered.

The second is configurable filtering by job title, company size and industry before a notification is sent, which matters more than it sounds. Independent reviewers name the most common failure mode of this product as the channel becoming wallpaper, with every visit alerting until people stop reading, and filtering to profile fit is the control that prevents it. What is absent is any control over the identification itself.

Nothing published describes a suppression list for individuals who should never be resolved, a mechanism for honouring a request from someone who does not want to be identified, or the ability to exclude a company, a competitor or a jurisdiction. Reviewers note that competitors, job seekers, students and the customer's own contractors all resolve alongside buyers. Ask whether individuals or organisations can be excluded from identification, and what happens if someone asks not to be resolved.

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.

One architectural control, published with its reason, and an active legal exposure the vendor does not address. The control is a geographic restriction: person level identification operates only on United States traffic, with company level identification alone elsewhere, and the vendor attributes that directly to European and international privacy law.

A restriction built into where the product will resolve at all cannot be forgotten by an operator, and it is the right shape of control for the risk. What is not addressed is the jurisdiction where the product does operate. Independent analysis identifies the live exposure in 2026 as state wiretapping and session tracking litigation in the United States, including claims under California's invasion of privacy statute, alongside state privacy laws, and states plainly that the exposure sits with the customer deploying the script rather than with the vendor.

Nothing published describes what a customer must disclose in their own privacy policy, whether consent management platform gating is supported or expected, whether global privacy control signals are honoured, or what the vendor's own position on that litigation risk is. Ask what the customer must disclose before deploying the script, whether the product honours browser privacy signals, and what the vendor's position is on session tracking litigation.

The geographic restriction is the whole of the published posture and the instruments behind it were not reached. Restricting person level resolution to one jurisdiction because privacy law elsewhere does not permit it is a substantive position rather than a policy statement, and the vendor states it openly rather than burying it.

One further change is worth recording because it moved in the privacy conscious direction: as of January 2026 the free tier no longer returns individual contact data at all and is limited to company level identification, so the product that most people try no longer names anyone. Beyond those two things little was established. No processing agreement, subprocessor list, retention period, transfer mechanism or data protection contact was reached on this pass.

The corpus deserves stating precisely because it is unusually specific about people who never volunteered anything: a name, a job title, an employer, a professional network profile, and the individual pages that person read and how long they spent on them. That last element is behavioural rather than identifying, and it is the part a resolved individual would find most surprising. Ask for the processing agreement and subprocessor list, the retention period for resolved visitor records and page history, and how an identified person exercises rights over that data.

Resolution runs on a shared identity pool and no account of its composition was located. Independent analysis describes the underlying mechanism as a co-op, and states that a given customer's results depend on how much of that pool their particular visitors have previously interacted with, which is a meaningful disclosure about how the product works and it comes from outside the vendor.

Nothing published names a participant, a data supplier or a collection basis, describes what a member contributes, or states the legal footing on which identifiers were gathered in the first place. Two further provenance questions follow from what is delivered.

The output includes a professional network profile for the resolved individual, and nothing states how that profile data is obtained, licensed or matched, which is the most consequential unanswered question here because that platform's data is the product's main deliverable. And nothing states whether a customer's own visitors are contributed back into the pool as a condition of use, which would make every buyer a supplier as well as a consumer. No indemnification position was located. Ask what the identity pool is composed of and on what basis, how professional network profile data is obtained and licensed, and whether a customer's visitors are contributed back.

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.

The product's entire function is to tell one party who the other party is, at a moment the second party believes they are anonymous, and no disclosure position accompanies it anywhere. What is delivered is not a company name or a segment. It is a named individual, their job title, their employer, their professional network profile and the specific pages they read, pushed into a channel within minutes so that a representative can act while the visit is still fresh.

The person is not told, cannot know, and has no route to find out. Nothing published describes what a customer must disclose on their own site, whether a resolved individual can request removal, or what anyone contacted this way would be told about how their identity and reading history were obtained.

The geographic restriction is a real mitigation and is why this sits where it does rather than lower, since resolution is confined to one jurisdiction on the vendor's own reasoning about privacy law elsewhere. Two comparisons make the placement concrete rather than arbitrary. One product in this category resolves visitors and then engages them automatically, compounding the identification with machine contact.

Another delivers advertising impressions on platforms that operate their own preference controls, and requires its customers to update their privacy notice. This product delivers a named human with their browsing history to another human for direct contact, and requires nothing. Ask what a customer must disclose before deploying the script, and how a resolved individual requests removal.

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.

No security surface was reached on this pass and the limit is on the retrieval rather than established as an absence. No trust centre, certification statement, audited report, penetration testing summary, vulnerability disclosure route or enumerated control description was located, and nothing here asserts that none exists, since the vendor's own site was reached only through its knowledge base and pricing material on this pass. What can be said is what the corpus warrants.

The platform holds resolved identities of individuals who never identified themselves, the pages each of them read, and the timing of those visits, accumulated continuously across every customer running the script. That is a concentration of behavioural data about named people who are not the vendor's customers and not its customers' customers either, and a buyer whose own site visitors sit inside it inherits whatever posture protects it without being able to inspect it.

The product also places executable code on the buyer's own website, which is a supply chain position rather than only a data one. Ask whether any attestation or certification is held, what protects resolution records, and what assurance exists over the script served to the buyer's site.

The structure and the unit economics are published in genuine detail, and the figures themselves could not be confirmed at the vendor's own pricing page. What the vendor's knowledge base establishes directly: four plans, a permanent free tier limited to company level identification with a stated monthly allowance, two middle tiers adding contact level identification with the coverage each provides, a top tier differing only by resolution depth, and an explicit credit policy stating that unused credits are forfeited on downgrade, that they may persist up to a month in some cases but never roll forward, and that refunds are not provided.

Publishing the forfeiture rule rather than leaving it in terms of service is unusually candid about the least attractive part of a credit model. Consistent independent accounts add the rates, allowances at each tier, a volume ladder extending well beyond the published tiers, and separate overage rates that differ by plan, which together would let a buyer compute a cost per identified contact at any volume.

Two things hold it below the top band and both concern verification rather than substance. The vendor's own knowledge base defers to a pricing page for current figures, and that page was not reached on this pass. And the external pricing record in this category has proved superseded on four consecutive vendors examined for this project, so third party figures alone are not a safe basis for the top grade however consistent they appear. Ask the vendor to confirm the current rates, allowances and overage charges directly.

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.