TL;DR
- Keep people, product workspaces, commercial accounts, legal billing entities and subscriptions as separate entity types.
- Prefer authenticated identifiers and explicit membership records. Use domains and names as candidate evidence, with confidence and provenance.
- RudderStack Profiles suits warehouse teams that want identity logic in a version-controlled data model. Segment Unify suits teams already collecting customer events through Segment and needing a managed profile graph.
- Hightouch suits organisations that want warehouse identity and activation together. LiveRamp deserves consideration when external identity connectivity and partner activation are central to the purchase.
- Evaluate false merges, unmatched records and correction propagation separately. High match coverage alone is a dangerous success measure.
Define the graph before choosing a platform
A useful identity model answers different questions at different levels. Which person used the product? Which workspace did they use? Which account owns that workspace? Which legal entity pays the invoice? Which parent company owns those entities?
Give each entity a stable internal key and retain the original system key alongside it. A billing customer ID is authoritative for that billing system's customer object. It is not automatically the identifier of a person or the whole corporate group. Likewise, a CRM account ID proves the existence of a CRM record, not that its legal hierarchy is correct.
| Entity | Strong starting identifier | Relationship to preserve |
|---|---|---|
| Person | Authenticated product user ID | Membership in one or several workspaces |
| Workspace | Product organisation or tenant ID | Commercial account and subscriptions |
| Commercial account | Governed internal account key | CRM records and legal entities |
| Billing entity | Billing customer ID plus verified legal identity | Invoices, subscriptions and payer relationships |
| Parent organisation | Maintained hierarchy key | Subsidiaries, without erasing them |
An email can change. A consultant can belong to several customer workspaces. A generic finance inbox can receive invoices for several subsidiaries. A domain can be shared by a holding company, university or agency. These are normal relationship patterns, not necessarily duplicate records.
Anonymous device and session identifiers introduce another layer. Associate anonymous activity with a person only when the evidence and collection rules justify it. Logging into a shared computer should not make every previous visitor the same customer. Keep the mechanism for retracting that association.
This foundation supports product-led sales workflows without turning usage by one subsidiary into activity by every account in a corporate group. It also keeps internal identity modelling distinct from the narrower task of assigning a new CRM lead to an account.
Four approaches and their buying fit
These products address overlapping parts of identity infrastructure, but the centre of gravity differs. The descriptions below use public documentation observed on 6 October 2026. They are procurement judgements, not results from a hands-on comparison.
RudderStack Profiles: identity logic in the warehouse
RudderStack Profiles documentation describes a declarative framework that uses configuration to generate warehouse-native SQL for customer profiles. Its appeal is that identity rules, features and cohorts can become part of the data team's maintained modelling workflow.
That is a strong fit when product, CRM and billing data already land in the warehouse and engineers want to inspect the join logic. The buyer can review a rule change alongside the resulting model, rather than treating the customer profile as an unexplained export.
The implementation still needs an owner for entity design, configuration changes and warehouse execution. Profiles is less attractive when nobody can maintain that model or when the real requirement is simply a small, stable mapping table. Ask how corrections affect incremental processing, historical features and downstream audiences before enabling automatic activation.
RudderStack's pricing page presents its product packaging. Obtain a scoped quote covering the Profiles capabilities, source collection and activation you will actually use. Include warehouse compute and the engineering cost of maintaining rules; a platform subscription alone is not the full identity budget.
Segment Unify: a managed graph around customer events
Segment's current identity documentation describes support for custom external identifiers, configurable association rules, merge protection and user-to-account relationships. It lists identity resolution under Business and addon availability, so a basic event-collection subscription should not be assumed to include this scope.
Segment is a sensible shortlist entry when the business already uses its event collection and wants a persistent profile spanning authenticated and anonymous interactions. For B2B use, require a demonstration of multiple account memberships and the exact consequences of a merge. A single customer view is useful only if its account relationships remain meaningful.
A consequential documented behaviour is that identifiers are case insensitive. If an upstream system treats differently cased values as different IDs, resolve that conflict before ingestion. This is a concrete example of why identifier semantics matter more than a feature tick.
Check current Segment pricing and obtain the applicable Unify package and volume definition. Budget migration, event governance and downstream correction work. Segment is a weaker fit when identity must live entirely inside a warehouse model controlled by the data team and a managed profile layer would duplicate that ownership.
Hightouch: resolve in the warehouse, then activate
Hightouch's identity overview describes linking records in the warehouse into a unified identifier. Its product page also presents deterministic and probabilistic resolution capabilities.
This route fits a team that wants identity outputs close to the data used for audiences and operational syncs. It can reduce the gap between defining an account model and sending that model to a destination. It does not remove the need to distinguish a likely relationship from an authoritative financial join.
For CRM and billing operations, begin with deterministic rules based on trusted IDs. If probabilistic matching is proposed, specify where it may suggest a candidate and where it may never trigger an automatic merge. Ask to see the evidence behind a match, a split correction and the resulting destination behaviour.
Use current Hightouch pricing to scope the identity and activation products together. Do not carry over a reverse ETL entry price as the cost of identity resolution. It is less compelling if the business needs no activation layer and a transparent SQL model already satisfies its correction and governance requirements.
LiveRamp: external identity connectivity
LiveRamp's identity documentation distinguishes resolution into AbiliTec IDs and RampIDs, including connectivity across known and pseudonymous identifiers. Its B2B offering extends the buying discussion to business audiences and data connectivity.
Consider LiveRamp when the required outcome includes external audiences, partner connectivity or activation that internal system IDs cannot provide. That is a different purchase from joining a subscription to the product tenant that generated it.
Ask which identifiers, markets, permitted uses and destinations the proposed service covers. Confirm whether the output preserves your internal account hierarchy or needs a separate mapping layer. External identity enrichment should not silently become the authority for which legal entity owes an invoice.
Request a scoped commercial proposal covering resolution, enrichment and activation rights. There is no defensible universal price for the four-provider comparison from the public pages examined. LiveRamp is harder to justify for a team whose entire need is connecting its own authenticated users, CRM accounts and billing records without external connectivity.
Work through 10,000 users and 900 billing records
Assume a company has 10,000 product users, 800 commercial accounts and 900 billing customer records. These are illustrative inputs, not a vendor workload test. The higher billing count may be legitimate: an account can have several payers, currencies or subsidiaries.
Start by checking product workspace memberships and explicit mappings between workspaces and commercial accounts. Suppose 720 of the 800 accounts have a trusted connection across CRM, product and billing. That is 90% account coverage; 80 accounts, or 10%, remain unmatched or ambiguous.
Do not divide 720 by 900 and describe the result as failed identity resolution. That denominator answers a different question about billing records. Nor does 90% account coverage prove that 90% of the 10,000 people are correctly connected. Track coverage separately for each entity type.
Suppose 50 of the 80 unresolved accounts lack an explicit billing-to-workspace key, 20 have conflicting CRM mappings and 10 contain a shared-domain ambiguity. Those categories sum to 80 only because this example assumes they do not overlap. In a real audit, deduplicate the exceptions before reporting the backlog.
The first repair should usually be to collect the missing authoritative relationship. Joining by domain may raise apparent coverage quickly but create a more expensive correction problem. Route the 20 conflicting mappings to the account data owner and the 10 shared-domain cases to evidence review.
If the team resolves 40 of the missing-key cases and 10 conflicts without introducing false merges, coverage becomes 770 ÷ 800 = 96.25%. Thirty accounts remain unresolved. That is a meaningful improvement because the accepted connections have evidence, not because the percentage looks impressive.
Separately inspect billing records for orphaned subscriptions, duplicate customer objects and legitimate many-to-one relationships. Count false merges against reviewed merge decisions, and report the sample size. Zero observed errors in a small sample is not proof that every connection is correct.
The result should feed customer expansion signals at the right account level. A billing entity's growth and a parent company's growth can be useful signals, but they should not be presented as the same event.
Set merge, provenance and correction rules
Use an edge table or equivalent graph representation with source entity, target entity, relationship type, evidence, confidence, rule version and effective dates. Preserve who or what authorised each accepted link. This makes a disputed connection explainable.
Distinguish three actions. A link records a relationship. A merge declares that two records represent the same entity. A roll-up aggregates related entities for a purpose such as reporting. Most account hierarchy work needs links and roll-ups, not destructive merges.
Allow automatic merges only for strong evidence with understood semantics. A shared domain can suggest an account candidate. A verified product tenant ID carried into a billing subscription can establish a much stronger connection. A human override needs an owner and a reason, with protection from the next automated run recreating the rejected edge.
Correction is part of procurement. Give every shortlisted provider a case where two unrelated customers were joined and already activated into the CRM. Require it to show the split, provenance, historical treatment and destination repair. Ask whether a corrected profile invalidates cached audiences and whether external deletion or suppression requests propagate appropriately.
Use the RevOps CRM setup playbook to assign field ownership and operating responsibilities. Add an identity exception queue with the disputed entities, evidence, proposed action and affected systems. Data engineering can own the graph while finance remains responsible for billing authority.
If duplicate CRM records are the underlying problem, resolve that with appropriate CRM data cleaning controls before treating a larger graph as the answer. Identity resolution can preserve a bad source relationship just as efficiently as a good one.
Budget the operating model
Ask vendors to price the same entity and event assumptions, including retained history, refresh frequency, destinations and environment count. Clarify whether the charge depends on profiles, events, records processed, activation products or another contracted unit. These units are not interchangeable.
Model implementation and ongoing ownership explicitly. In an illustrative internal budget, 60 engineering hours at £90 per hour cost £5,400. Four hours of weekly maintenance over 52 weeks cost another £18,720. The combined first-year labour assumption is £24,120 before subscription, warehouse compute and finance or security review. This is a planning calculation, not a market rate or vendor quote.
A cheaper platform may need more exception handling. A more expensive one may still leave hierarchy design to your team. Compare the cost of obtaining trustworthy links and correcting errors, not only the number of profiles the platform can hold.
Keep contracts explicit about exportable identifiers, evidence history, deletion, correction and exit. If the model cannot be reconstructed outside the vendor, migration is a governance issue as well as a technical cost.
Make the buying decision
Choose RudderStack when a warehouse team wants identity rules maintained with its data models. Choose Segment when its collection and managed profile infrastructure already suit the operating model. Shortlist Hightouch when warehouse identity and destination activation should be bought together. Investigate LiveRamp when external connectivity is a necessary part of the outcome.
For the 800-account scenario, a governed mapping model may be sufficient if authenticated identifiers and billing keys already exist. Add a platform when event stitching, correction operations, scale or activation justify the additional ownership and cost.
The decisive evaluation is whether the system can explain and reverse a wrong relationship while preserving legitimate subsidiaries, payers and memberships. Reject a proposal that demonstrates only a higher match rate. The buyer needs a trustworthy customer model that survives correction.
FAQ
Is an email address a reliable customer identifier?
It is useful evidence but should not be the only permanent key. Addresses can change, be shared or be reused. Retain authenticated system identifiers and the history of relationships.
Should every subsidiary share one account profile?
Maintain subsidiary and legal billing identities separately, then roll them up to a parent for a defined reporting purpose. This preserves contracts, ownership and payment responsibility.
Can probabilistic matching connect billing records?
It can suggest candidates, but an inferred similarity should not automatically establish financial authority. Use verified identifiers or an approved evidence process before joining subscriptions and payers.
What should the first identity metric be?
Report trusted coverage by entity type alongside false merges, unresolved conflicts and correction time. A single overall match percentage hides the difference between people, accounts and billing entities.
Do we need a CDP for this?
A maintained warehouse mapping model may meet a small, deterministic requirement. A CDP or identity platform becomes useful when event stitching, managed profiles, activation or correction operations exceed that model's practical capabilities.
