Identity Resolution Pricing: Calculate Cost per Usable Match

BrandWell: MarketPulse intent data and connected growth automation

BrandWell MarketPulse: intent data starting at $500/mo. Find people researching topics relevant to what you sell, apply saved ICP filters, and review available contact details before taking action.

MarketPulse plans are starting at $500/mo. Verify current package scope and offers on the product page.

MarketPulse standard monthly plans

Plan	Topics and refreshes	Monthly exports
Starter	1 topic, weekly	25,000 contacts
Growth	3 topics, daily	100,000 contacts
Scale	10 topics, daily	Unlimited contacts

Swipe the table to see all columns.

A pull retrieves available data from the previous 24 hours for one topic. Daily use across all included topics provides 90 Growth pulls or 300 Scale pulls in a 30-day month. Weekly Starter pulls vary by calendar month. Available audience size and contact fields vary, and audiences may overlap. Refreshes stop at the plan limit without overage charges.

• Find and qualify: search the topic catalog, save your ICP, and review the people and companies that match.
• Act on the research: export qualified contacts or prepare an Outreach or Direct Mail workflow. Connected products, channel usage, and fulfillment may cost extra.
• Get help from AIMEE: Growth and Scale include AIMEE for the initial user to research accounts and prepare the next step through connected tools.

Agencies and other service businesses can build client deliverables around their available Intent Scans and exports. Keep each client’s scope, permissions, and service fees clear. A subscription is not a promise of a white-label platform or exclusive access to a market.

Explore MarketPulse and watch the demo or compare plans starting at $500/mo. Any early-access discount is a separate, time-limited offer shown to an eligible recipient.

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.

Compare the actual use case, billing units, fields, confidence definitions and implementation scope. A low posted price may exclude data, connectors, implementation or destination acceptance. Unbundle a quote before comparing it.

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.

In a fictional test period, a program costs $12,000 fully loaded. It attempts 100,000 records, reports 35,000 matches, yields 28,000 unique records, passes 22,000 through QA and delivers 20,000 destination-accepted records. If all 20,000 satisfy the defined usable-match rules, cost per usable match is $0.60. Cost per attempted record is $0.12 and per raw match about $0.34, which answer different questions. If only 8,000 are also commercially fit, cost per fit-and-usable match is $1.50. A destination receipt alone does not establish identity quality or permitted use.

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. Model accepted output, activation, sales acceptance, opportunity rate, win rate and contribution on consistent cohorts and time horizons. A descriptive baseline is not automatically a causal comparison. Use a suitable experiment when estimating incremental effects; otherwise state the uncertainty and avoid presenting attributed pipeline as incremental return.

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.

Google’s data-use policy prohibits third-party data for creating targeting audiences and permits it for segmenting first-party audiences on covered personalized-ad surfaces. Check the actual destination’s requirements; hashing does not change source or grant permission.

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.

Review necessary fields, permitted purposes, access, retention, correction, suppression, deletion, contracts and incident handling for the actual identifiers and workflow. Obtain qualified advice on jurisdiction-specific requirements. A framework or template does not establish compliance.

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.

Use MarketPulse for relevant topic research and available matching people and company fields. TrafficID separately reviews eligible visitors to your own website. AIMEE can prepare a review brief through configured connected tools; validate the output and actual destination before action. Define additional identity-resolution implementation and agency service scope separately.

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.