Identity resolution is the operation that turns Data Cloud from a data warehouse into a customer data platform. It takes records from many sources — CRM, e-commerce, mobile app, loyalty program, support tickets, marketing automation — and resolves them into unified customer profiles. It is also one of the heaviest credit consumers in the platform, and one of the operations where buyers most consistently misforecast their consumption. This guide breaks down how identity resolution is priced, what drives its cost, and how to negotiate protection against the volatility it creates.
Across more than 80 Data Cloud engagements, our team has analyzed identity resolution consumption patterns for organizations ranging from regional B2B vendors to global B2C retailers. The patterns are consistent enough to share. Identity resolution accounts for between 15% and 35% of total Data Cloud credit consumption in mature deployments, and is the largest single source of consumption surprise in the first twelve months.
How Data Cloud meters identity resolution
Identity resolution in Data Cloud runs as a set of jobs that evaluate the unified profile dataset against configured matching rules — deterministic, probabilistic, or rules-driven combinations of email, phone, address, and identifier matches. The platform charges credits per resolution job, with the credit cost scaling against the dataset size being resolved and the complexity of the rules.
Two characteristics of the metering matter. First, identity resolution is typically run on the full unified dataset, not on the incremental records added since the last run. A full re-run on a 100-million-profile dataset costs more than a full re-run on a 25-million-profile dataset. Second, the platform supports both scheduled re-runs (typically daily or weekly) and on-demand re-runs triggered by data quality fixes, schema changes, or new source onboarding. Both consume against the same credit pool.
| Driver | Effect on credit cost | Buyer mitigation |
|---|---|---|
| Unified profile count | Scales roughly linearly | Source filtering before ingestion |
| Matching rule complexity | Multiplier on base cost | Simpler rules where business allows |
| Re-run frequency | Direct multiplier | Cadence aligned to business need |
| On-demand triggers | Unpredictable | Change control on rule edits |
| Source onboarding | One-time spike per source | Batch onboarding into single re-run |
Where the forecast goes wrong
The Salesforce-built identity resolution forecast typically assumes a single resolution rule set, a static profile count, and a fixed cadence. Real deployments depart from this baseline in three ways that drive cost above plan.
Profile growth is non-linear
New sources, new data quality work, and improved ingestion typically expand the addressable profile count faster than initial planning anticipated. We see profile counts grow 30-80% in the first twelve months as more sources come online. Each percentage point of growth scales identity resolution cost linearly.
Rule changes trigger full re-runs
As the marketing and data teams refine matching logic — adding probabilistic email matching, tightening address normalization, adjusting tie-breaking rules — each rule change triggers a full re-run to apply the new logic. A team in early operation can run a dozen rule changes in a quarter, each of which costs a full re-run.
Data quality work generates churn
Identity resolution depends on data quality. Quality fixes — deduplication, standardization, source reconciliation — typically require resolution re-runs to take effect. Organizations in the first year of Data Cloud operation often run more resolution cycles for data quality than for ongoing operations.
Designing for identity resolution efficiency
Most identity resolution waste is structural and can be reduced through deployment choices that do not affect business outcomes.
Resolution cadence by source
Not every source needs to participate in every resolution cycle. High-velocity sources (e-commerce transactions, mobile app events) benefit from frequent re-runs. Slow-changing sources (loyalty program enrollment, legacy CRM extracts) do not. Configuring resolution cadence by source class, where the platform allows, materially reduces consumption.
Incremental matching where supported
Where the platform supports incremental matching, configure it. The platform's re-run cost on incremental records is much lower than a full re-run, and for steady-state operations the incremental output is functionally equivalent.
Change control on resolution rules
Treat resolution rule changes the way you would treat production schema changes. Require a change ticket, an estimated credit impact, and an explicit go-ahead. The cost of one well-considered rule change is much less than the cost of ten exploratory rule changes.
Source onboarding batching
If multiple new sources are coming online in the same quarter, onboard them into a single resolution re-run rather than triggering a re-run per source. The credit savings on this single discipline are often material.
Negotiation levers for identity-heavy deployments
For deployments where identity resolution will be a major share of consumption, several contract clauses are worth pursuing specifically.
Resolution job rate cap
Lock the credit-per-resolution-job rate to a dated rate card, with explicit language preventing mid-term repricing. Identity resolution rates have been adjusted by Salesforce mid-cycle in prior platform updates; the lock prevents repeat.
Re-run allowance for source onboarding
Negotiate a defined number of free or reduced-rate re-runs tied to new source onboarding events. This converts a buyer-unfriendly cost pattern into a known, bounded one.
Data quality re-run pool
For organizations in the first year of Data Cloud operation, negotiate a separate data quality re-run pool that does not draw against the main credit block. Salesforce can usually accommodate this because they understand that year-one data quality work is part of the platform's intended use.
Profile count true-down rights
If your profile count is expected to decline over time — through consolidation, customer lifecycle, or deliberate cleanup — negotiate true-down rights tied to addressable profile count. This protects against shelfware as the underlying dataset shrinks.
An operating model that holds identity cost in check
The contract sets the ceiling. The operating model determines where consumption actually lands. Three disciplines we recommend:
- Monthly resolution cost review — track resolution credit consumption by trigger (scheduled, rule change, source onboarding, data quality, ad-hoc) and review monthly. Drift is detectable early.
- Resolution rule change board — require a small standing group to approve rule changes. This prevents exploratory changes from accumulating into expensive re-run patterns.
- Source onboarding calendar — schedule new source onboarding in defined waves, with resolution re-runs aligned. This consolidates spikes rather than spreading them.
What good looks like
A mature Data Cloud deployment with disciplined identity resolution operations typically exhibits the following characteristics:
- Scheduled resolution cadence aligned to source class, not a single global cadence.
- Resolution rule changes batched into quarterly release cycles rather than continuous deployment.
- Data quality re-runs accounted for separately in the credit pool structure.
- Profile count audited quarterly, with archival of inactive profiles to control the resolution base.
- A rate-card lock and re-run allowance in the master commercial agreement.
- Monthly consumption reporting with a defined drift threshold that triggers a review.
The savings from these practices, on top of a well-negotiated contract, typically run another 15-25% beyond what the contract alone delivers. Combined with the 34% average reduction we generate at the contract layer, the cumulative effect on identity-heavy deployments is significant.
Bringing it together
Identity resolution is the operation that defines Data Cloud as a customer data platform. It is also the operation where the gap between forecast and actual consumption is widest, where the contract structure most needs to anticipate change, and where the operating discipline most directly determines cost. Buyers who treat identity resolution as a strategic line item — not a back-office data engineering task — capture the largest share of available savings.
The combination of a properly structured contract (rate card lock, re-run allowance, data quality pool, true-down rights) and a disciplined operating model (cadence by source, change control on rules, batched onboarding) keeps identity resolution from becoming the year-one cost shock it routinely is for unprepared deployments.
Frequently asked buyer questions on identity resolution cost
Should we run identity resolution as frequently as the vendor recommends?
Not necessarily. The vendor recommendation is calibrated for marketing freshness, which favors more frequent resolution. The right cadence depends on how stale a profile can be before downstream campaigns see degraded performance. For many use cases, daily resolution is sufficient. For real-time personalization on logged-in profiles, the resolution can often be deferred to the next scheduled cycle without impact.
How do we estimate identity resolution credits before signing?
Build a model that captures unified profile count by source, expected matching rule complexity, scheduled cadence, and expected rule-change frequency. Add a buffer for data quality reprocessing in year one. The model produces a defensible forecast that the negotiation can be sized to.
What happens if our identity resolution rules need to change mid-term?
Rule changes typically trigger a full re-run, which consumes credits at the standard resolution rate. A change-control discipline keeps this manageable. A negotiated data quality re-run pool absorbs the year-one volatility.
Can we use a third-party identity resolution tool with Data Cloud?
Architecturally possible, but operationally rare. Most enterprises use Data Cloud's native identity resolution because of the deep integration with the rest of the platform. Third-party identity is more common when the customer already has a heavy investment in another identity platform that they do not want to retire.
The cost shape we typically see over a three-year term
Identity resolution cost follows a recognizable arc across a typical three-year deployment. Year one runs heavy as data quality work, source onboarding, and rule refinement drive reprocessing. Year two stabilizes as the dataset and rules settle. Year three drops further if the operating model includes consolidation, archival, and cadence discipline.
This arc has implications for contract structure. Buyers who sign for a flat year-three credit block end up with shelfware unless true-down rights are in the contract. Buyers who sign for a tapered block — heaviest in year one, lighter in years two and three — capture the natural cost decline and avoid the shelfware. The tapered structure is rare in default contracts but achievable through negotiation when the buyer presents the cost arc credibly.
A worked example: identity resolution at a mid-size B2C retailer
To make the cost shape concrete: a retailer with 30 million addressable customers, daily resolution, four sources contributing, and standard deterministic-plus-probabilistic matching rules. Year one consumption is dominated by the initial full resolution against historical data, three rule refinement cycles each triggering full re-runs, and two source onboarding events each triggering full re-runs. Year two consumption is roughly half of year one as the dataset stabilizes. Year three consumption is another 15-25% lower if the operating model includes archival of long-inactive profiles.
The three-year credit total ends up lower than three years at the year-one rate by 30-45%. Buyers who model this arc and sign a tapered contract capture that savings. Buyers who sign flat blocks based on year-one experience pay for the arc that never materializes.