Identity Resolution Pricing: How to Compare Cost per Usable Match

Who is this for?

This guide is for B2B data leaders, RevOps teams, growth operators, procurement teams, and agencies comparing identity resolution for visitor identification, account matching, enrichment, CRM cleanup, or signal activation. It provides a controlled evaluation method, cost waterfall, calculator logic, quote checklist, and service-packaging model. It is not a provider accuracy ranking, a claim that every anonymous visitor can be identified, or legal advice about a particular data use.

1. Define a usable match before comparing prices

Pricing comparisons fail when one provider counts any linked record while the buyer needs a current, routeable, unique entity. Write the acceptance definition before requesting quotes or samples.

A person or company match is usable only when it passes all applicable gates:

1. Correct observation unit: person, household, device, domain, or account matches the intended decision.
2. Confidence: the method and score meet a documented threshold.
3. Entity accuracy: the proposed record is the right entity, not merely similar.
4. Uniqueness: duplicates and conflicting merges are resolved.
5. Freshness: time-sensitive fields are within the buyer’s valid window.
6. Fit: geography, firmographics, role, account status, or other eligibility rules pass.
7. Contactability: required channel fields validate when outreach is part of the use case.
8. Suppression and permitted use: exclusions, deletion requests, rights, contract terms, and destination policies pass.
9. Completeness: the required fields and provenance exist.
10. Destination acceptance: the CRM, workflow, report, or approved activation accepts the record without destructive errors.

Create separate definitions for company matches and person matches. Reverse IP may support a company inference without identifying an individual. A separately resolved contact should not be described as the person who generated an account-level or shared-network event unless independent evidence proves it.

2. Run a controlled sample-to-invoice workflow

Use the same representative sample, fields, rules, and acceptance tests for every option. The workflow is:

1. Define the use case, observation unit, required fields, confidence threshold, and allowed destination.
2. Build a truth set containing easy, ambiguous, missing, shared, stale, and duplicate cases.
3. Normalize the sample without improving one provider’s input unfairly.
4. Submit identical eligible fields and processing rules.
5. Collect provider record IDs, match method, confidence, provenance, timestamps, and billable events.
6. Blind-review a sample of proposed matches and record reasons for acceptance or rejection.
7. Deduplicate and test merge behavior, including false merges and missed merges.
8. Send accepted records through a non-destructive destination test.
9. Reconcile processed units, matches, retries, add-ons, and invoice logic.
10. Repeat a drift sample after implementation.

Assign distinct roles. Data engineering owns normalization and reproducibility. RevOps owns schema, deduplication, and destination behavior. The business owner defines value and acceptance. Privacy and security review rights, access, retention, and risk. Finance or procurement normalizes the quote and invoice. The activation owner confirms that an accepted record can actually support the intended play.

Do not let a provider choose the only evaluation sample or label its own output as ground truth. Preserve rejected results as well as accepted ones so precision, recall, and failure patterns remain visible.

3. Use a calculator, truth set, QA log, and quote checklist

The most useful operational resources are platform-neutral:

• Representative truth set and sampling plan
• Field dictionary with observation unit and freshness rules
• Match-decision rubric and confidence bands
• Duplicate, split, and merge audit
• QA log with reviewer and rejection reason
• Destination-acceptance runbook
• Cost waterfall and scenario calculator
• Usage and invoice reconciliation sheet
• Privacy, suppression, retention, and deletion checklist
• Written-quote checklist and change log

The calculator should accept attempted records, billable processed units, raw matches, unique matches, QA-accepted matches, destination-accepted records, implementation cost, recurring fees, usage fees, add-ons, storage, egress, QA labor, reprocessing, and support. Display conversion rates between each stage and the cost per output.

Treat platforms as inputs to the test, not substitutes for it. AWS entity-resolution services, Twilio identity products, BrandWell, and other providers use different scopes, pricing units, confidence concepts, and implementation assumptions. A low posted unit price may exclude identity data, connectors, implementation, or downstream acceptance. A custom quote may combine capabilities that must be unbundled for a fair comparison.

4. Use the narrowest resolution method that meets the decision

Deterministic single-field matching is efficient when a stable, unique identifier exists. It becomes brittle when emails change, domains are shared, phone formats vary, or fields are absent.

Reverse-IP matching can help associate traffic with a company, especially on business networks. It should not be treated as person identification, and shared networks, remote work, privacy infrastructure, and mobile traffic create ambiguity.

Manual reconciliation works for small, high-value samples, complex exceptions, and validation. It provides context but does not scale consistently, and reviewer judgment must be documented.

Multi-identifier or probabilistic resolution can join fragmented emails, phones, devices, addresses, domains, account records, and other identifiers. It may improve coverage but adds model opacity, false-merge risk, implementation work, and governance requirements.

Compare methods on the observation unit, precision, recall, latency, coverage, explainability, auditability, freshness, merge reversibility, permitted use, and fully loaded cost. Start with a deterministic key when it meets the workflow. Add broader resolution only when the incremental accepted matches justify the added cost and risk.

5. Calculate fully loaded cost and normalize the pricing unit

Use this primary formula:

Cost per usable match = total fully loaded cost ÷ unique destination-accepted usable matches

Total fully loaded cost can include subscription or contract minimums, processed records, monthly tracked users, profiles stored, match or API calls, identity-data licenses, enrichment, add-ons, implementation, connectors, storage, egress, QA labor, retries, reprocessing, support, security, and governance. Some services bill processed records even when no match is returned; others meter profiles, events, requests, or active users. Record the exact unit rather than translating the marketing label by intuition.

Suppose a program costs $12,000 fully loaded for a test period, processes 100,000 records, reports 35,000 matches, produces 28,000 unique records, passes 22,000 through QA, and lands 20,000 accepted records in the destination. The relevant cost is $0.60 per usable match, not $0.12 per attempted record or about $0.34 per raw match. If only 8,000 accepted records fit the commercial use case, also report $1.50 per fit-and-usable match.

Run low, expected, and high scenarios for volume, match acceptance, duplicates, reprocessing, analyst time, and destination failure. Reconcile the first real invoice against the quote before expanding volume.

6. Tie identity-resolution unit economics to accepted pipeline stages

Track a cost ladder: processed record, provider-reported match, unique match, QA-accepted match, destination-accepted record, activated record, sales-accepted lead or account, qualified opportunity, pipeline, and closed outcome. The ladder reveals where apparent efficiency disappears.

A cheaper match can be more expensive downstream if it creates false merges, stale contacts, irrelevant accounts, CRM cleanup, sales distrust, or policy-ineligible activation. Conversely, a higher match price may be economical when it reduces analyst review and produces more accepted, actionable records.

Keep business assumptions explicit. Calculate expected value from accepted output volume, activation rate, sales acceptance, opportunity rate, win rate, and contribution margin. Use a baseline or holdout where feasible. Do not convert attributed or influenced pipeline into a causal claim without an appropriate design. Google’s description of Conversion Lift explains the use of treatment and control groups for incremental measurement.

Margin should be calculated after rework and exceptions. If an agency earns revenue per client but absorbs unmetered retries, custom mappings, and manual review, the raw-match price conceals the actual economics.

7. Use identity resolution where fragmented identifiers block a valuable workflow

The strongest fit is a team with multiple identifiers or disconnected systems, meaningful anonymous-to-known or account-stitching journeys, enough volume to evaluate quality, high-value decisions, a defined destination, and operators able to act on accepted records.

Useful cases include resolving website activity to eligible companies, joining duplicate CRM records, connecting approved lead sources, enriching a qualified queue, mapping account research to CRM accounts, and supporting a controlled signal-to-action workflow.

It is a weak fit when a reliable deterministic key already solves the problem, source data is too sparse, match error would be costly, rights are unclear, the required destination disallows the use, or no one owns follow-up. A tiny high-value dataset may be better served by manual reconciliation. A low-value, high-volume workflow may not tolerate expensive review.

Qualify fit before buying coverage. Ask what decision changes when a match is accepted, how quickly it must occur, what error costs, and whether a company-level result is sufficient. More identity is not automatically more value.

8. Keep intent, identity, freshness, fit, and activation as separate gates

An intent signal says behavior occurred at some observation unit. Identity resolution proposes which person, company, device, or record it belongs to. Freshness determines whether the evidence remains timely. Fit determines commercial relevance. Suppression, permission, contracts, and destination rules determine allowed use. Downstream outcomes test business value.

Store these as separate fields and decisions:

raw observation → observation unit → proposed entity → match method and confidence → freshness → fit → suppression and permitted use → activation → outcome

Never let a single “intent score” erase that lineage. A strong company match does not identify the employee. A validated email does not prove the person expressed intent. A fresh research signal does not create consent. A permitted report does not imply a permitted ad-audience upload.

For covered Google personalized-ad surfaces, current policy says third-party data cannot be used to create targeting audiences. Review the official data-use policy before modeling that destination. Hashing does not change the source category or create consent.

9. Price error, privacy, and drift – not only successful matches

The principal risks are ambiguous identifiers, shared devices or domains, false merges, missed merges, stale records, duplicates, opaque confidence, duplicate charges, hidden add-ons, uncontrolled reprocessing, unclear rights, excessive retention, exposed credentials, cross-client leakage, and policy-ineligible activation.

Include the cost of sampling, rejection, correction, deletion, suppression, access reviews, incident response, and periodic retesting. Require the quote and operating agreement to state billable units, no-match treatment, duplicate treatment, retry treatment, confidence fields, data retention, export and deletion, support, overages, price changes, and termination.

The FTC’s security guidance recommends keeping only necessary data, restricting access, protecting retained information, and preparing for incidents. The NIST Privacy Framework can help structure privacy-risk management. Apply these principles to the actual identifiers, transfers, operators, and destinations in the workflow.

Monitor drift with recurring truth-set samples. Provider coverage, source quality, client data, market composition, match rules, and destinations change. A strong pilot result is not a permanent quality guarantee.

10. Package identity resolution as a measured service component

An agency should package the governed workflow rather than mark up raw matches invisibly. Include use-case design, source and quote normalization, implementation, field mapping, QA sampling, exception handling, destination acceptance, reporting, invoice reconciliation, drift tests, and client review. Show the client the acceptance definition and cost waterfall.

BrandWell can be evaluated as a configured intent-to-action option that may include person- and company-level records where coverage exists, TrafficID, enrichment, qualification, routing, dashboards, and workflow design. BrandWell agency plans range from $2,500 to $5,000 per month, depending on topic count, term, and available contractually scoped topic exclusivity. The current written quote and Order Form control. This is not a public list price or universal quote; BrandWell pricing is custom scoped. Confirm coverage, billable units, modules, destinations, term, any exclusivity, white-label rights, wholesale terms, and final pricing in a current written quote.

Treat the new BrandWell intent-data offer as a separate agency-reseller product from the legacy BrandWell SEO writer. Agencies can purchase BrandWell’s $70 seven-day reseller pilot. It includes agency-branded topic reports and the complete sales playbook under the current written pilot terms. Other product capabilities and any topic exclusivity remain subject to their separate current written scope. The same applies to agent-ready workflow instructions for Claude or ChatGPT, or direct browser execution through Moxby, a separate product: confirm supported actions, permissions, and approval boundaries before selling the workflow. Require human approval for consequential data use, activation, outreach, material system writes, and client-facing claims.

Treat intent, identity, and match signals as probabilistic evidence – not proof of identity, need, authority, consent, or purchase intent. Before deployment, require human, product, pricing, privacy, security, compliance, legal, and platform-policy review of the configured offer and workflow.

The best buying decision is not the lowest price displayed by a provider. It is the lowest governed cost for a record that survives quality, fit, rights, and destination acceptance and contributes to a decision the client values.