Visitor Identification Match Rate: Calculate It Yourself

How do you calculate visitor identification match rate?

Divide identified sessions by a denominator you explicitly choose and label — all sessions, filtered human sessions, target-market sessions, or high-intent sessions — then multiply by the precision of a ground-truth sample: usable match rate = (identified sessions × precision) ÷ denominator sessions. The raw rate overstates reality; the usable rate is the one your alerts can run on. The free match-rate calculator runs this guide's whole worksheet — four denominators, false-positive adjustment, and precision-sample sizing — on your own numbers.

Match rate is the most quoted and least defined number in visitor identification. Vendors publish their own percentages — one prominent person-level vendor advertises an identification-percentage range right on its homepage — but a vendor's marketing figure tells you nothing about the number you will get, because match rate depends on your traffic mix, your geography, your visitors' networks, and, above all, on which denominator the calculator chose. This guide gives you the arithmetic to compute your own.

This page is the calculation companion to the match-quality audit worksheet: the audit tells you whether matches are right; this tells you how to count them honestly in the first place. Do both before any alert, routing rule, or renewal decision trusts the data.

Why every match rate needs a denominator label

"We identify 40% of your traffic" is meaningless until you know 40% of what. There are four defensible denominators, and they produce wildly different numbers on the same site:

Denominator	What it counts	What the resulting rate tells you	Trap
D1: All sessions	Every session your analytics property records	Marketing-honest coverage of raw traffic	Bots, monitors, and your own employees inflate the denominator and deflate the rate
D2: Filtered human sessions	Sessions after excluding known bots, monitors, employees, and existing customers	Coverage of traffic you could conceivably act on	Requires your exclusion rules to exist and work
D3: Target-market sessions	Filtered sessions from geographies and segments the vendor claims to cover	The vendor's claim tested on its own terms	Easy to gerrymander; document the scope in writing
D4: High-intent sessions	Filtered sessions that touched pricing, comparison, or product pages	Coverage of the traffic sales actually cares about	Small numbers; needs longer windows for stability

Compute all four when you can, but D2 is the working number for operations and D4 is the number that decides whether the tool feeds sales. When a vendor quotes a rate, your first question is: which denominator, measured where, over what window?

Your denominator source should be independent of the vendor: your own analytics property, set up per Google's standard documentation, with the identification tag and the analytics tag deployed through the same governed tag-management scope so they see comparable traffic. If the two tags fire on different page sets, every ratio you compute is fiction — QA this first with the tag QA guide.

The two formulas

Raw match rate is the easy one:

raw match rate = identified sessions / denominator sessions

Raw match rate overstates reality because some identifications are wrong. The number you can operate on is:

usable match rate = (identified sessions × precision) / denominator sessions

where precision is the share of identifications that survive ground-truthing. A tool that "identifies" 50% of traffic at 60% precision is a 30%-usable tool, and — this is the part renewal decks omit — the errors are not evenly distributed: mismatches cluster in exactly the shared-network and remote-work traffic that makes B2B identification hard.

Measuring precision with ground truth you already own

You cannot audit every match, so sample. You already own three ground-truth sets, and standard CRM plumbing produces them:

1. Known-visitor events. Form submissions (Salesforce Web-to-Lead or your form stack) and tracked known contacts (first-party tracking code, as HubSpot's documentation describes) give you sessions where you independently know the company. Check what the identification tool said about those same sessions.
2. Customer and opportunity lists. Build static lists of current customers and open opportunities (HubSpot lists or the Salesforce equivalent). When the tool claims one of these accounts visited, your team can usually verify plausibility quickly — an active deal's champion visiting the pricing page is checkable against the deal.
3. Your own employees and vendors. You know your office networks and your agency's. Every self-visit the tool attributes to a random company is a scored false positive; every correctly identified partner visit is a scored true positive.

Sampling method: each week, pull 50 identified sessions at random (or all of them, if you have fewer), mark each as confirmed, plausible-unverified, or wrong, and compute precision as confirmed ÷ (confirmed + wrong), tracking the plausible-unverified share separately. If plausible-unverified exceeds half your sample, your ground-truth sets are too thin to score the tool yet — grow the lists before trusting the number. Record everything in the worksheet:

Week	Denominator (D2)	Identified	Raw rate	Sampled	Confirmed	Wrong	Precision	Usable rate
—	—	—	—	—	—	—	—	—

Variance: the check that keeps you honest

A single week's match rate is weather, not climate. Before quoting any number internally, run three checks:

• Week-over-week spread. Compute the rate for at least four consecutive weeks. If the spread between the best and worst week exceeds a third of the average, your traffic mix is shifting (campaigns, geography, bot waves) and no single number should drive decisions yet.
• Segment stability. Compute D2 rates separately for your top two geographies and for mobile versus desktop. International and mobile-carrier traffic routinely match worse; a blended rate hides the fact that your German pipeline is invisible to the tool.
• Spike hygiene. Any day with a traffic spike gets inspected before it enters the average — bot bursts and newsletter blasts both move the denominator without moving identifiable traffic. Your exclusion rules (the employee/customer/bad-fit guide) are load-bearing here.

The myth to retire is the perfect-identification assumption. No tool identifies everyone; the operational question is whether the usable rate on the traffic you care about justifies the workflow you are building. Sometimes the honest answer is "not yet" — the incomplete-data playbook covers running a useful motion at partial coverage.

What to do with the number

• Below your action threshold on D4: keep the tool in research/reporting mode; do not wire alerts. Set the threshold before measuring, or the measurement will negotiate with you.
• Usable but volatile: operate weekly reviews rather than real-time alerts until four stable weeks exist — the first-30-days measurement plan sequences this.
• Renewal or vendor comparison: compute the same worksheet on the same weeks for both tools during a parallel test, and take the grid — not the anecdotes — into the negotiation. The Leadfeeder vs Lead Forensics comparison grid shows where measured rates fit in a full vendor decision.
• Any external quote: never repeat your rate without its denominator label and window. "31% usable on filtered human sessions, four-week average" is a fact; "we identify a third of our traffic" is a future disappointment.

Claim ledger

Claim used in this guide	Source boundary	Review rule
Vendors publish their own identification-percentage claims.	Current RB2B homepage, observed 2026-09-13, as one public example.	Treat all such figures as marketing claims to test, never as benchmarks.
Analytics, tag-manager, tracking-code, lists, and Web-to-Lead mechanics.	Official Google, HubSpot, and Salesforce documentation, observed 2026-09-13.	Platform docs support the plumbing only; they prove nothing about any identification vendor's accuracy.
No industry-average match rate, precision benchmark, or vendor ranking is claimed here.	Not used — deliberately.	If a future edit adds a benchmark, it must carry a current primary source and a denominator label.

FAQ

What is a good visitor identification match rate?

This guide deliberately quotes no benchmark, because published figures rarely state their denominator, geography, or false-positive adjustment — and because the decision-relevant number is whether your usable rate on your high-intent traffic clears the threshold you set for your workflow. Define the threshold first, then measure.

Why is my match rate so much lower than the vendor's quoted number?

Usually three compounding reasons: the vendor's figure used a friendlier denominator (often something like D3 on US business traffic), your raw rate includes false positives the quote ignored, and your traffic mix includes segments — international, mobile, remote-work — that match worse. Compute the four denominators and the gap generally explains itself.

How do I measure false positives without auditing everything?

Sample. Fifty random identified sessions a week, scored against ground truth you already own — known form-fillers, customer and opportunity lists, your own employee traffic — gives you a workable precision estimate within a month. The match-quality audit worksheet is the structured version of this scoring.

Should match rate decide which vendor we buy?

It should be one measured input, computed identically for each tool on the same weeks of your traffic during a parallel test. A higher raw rate with worse precision is a worse tool. Fold the worksheet into the full decision method in the comparison grid and the vendor due-diligence checklist.

How often should we recompute it?

Weekly during the first quarter, then monthly, and immediately after any tag change, site migration, exclusion-rule update, or vendor "improvement" announcement. Match rate is a monitored metric, not a one-time acceptance test.