A marketer demos a CDP and asks the obvious question: can it give us one view of the customer? The vendor says yes, our identity resolution handles that. Eighteen months later the same marketer is still finding the same person three times in a campaign report, once by email, once by a loyalty number, once by a device. The CDP did exactly what it promised. The problem was that "identity" meant two things in that demo, and only one of them got bought.
Identity stitching and identity resolution are used interchangeably across vendor sites, sales calls, and even analyst writing. They are not the same job. Stitching is mostly a within-source problem: connect a single visitor's anonymous and logged-in activity, across their sessions and devices, into one continuous timeline. Resolution is a cross-source problem: take that person and match them across email, CRM, the mobile app, point of sale, loyalty, and support into one durable profile that survives a changed email and a new phone. Conflating the two is why buyers expect one tool to do both, and why so many are quietly disappointed when it does one well and the other badly. This piece separates them: what each does, what data and keys each uses, where each breaks, and how to tell, for any given problem, which job you are actually looking at.
Where the two ideas came from
Both grew out of the same frustration, that one person looks like many people to a company's systems, but they grew out of different parts of the business.
Stitching is a web analytics idea first. The early problem was narrow and concrete: a person lands on your site, browses for ten minutes, leaves, comes back next week on the same laptop, then finally logs in. That is one human and, to a naive analytics setup, four or five disconnected sessions and at least two identifiers. The behavioral data pipeline world built stitching to fix exactly this. Snowplow, an open-source event pipeline that predates most CDPs, frames it plainly in its own documentation: when a known user identifier appears, it can be linked back to the cookie-based identifier so earlier anonymous sessions are attributed to that user. The keys are digital and the scope is one tracked surface. The job is to make a fragmented clickstream behave like one person's story.
Resolution is older and comes from the data side, specifically from direct mail and offline marketing. Long before cookies, companies had the same customer in a billing file, a catalog mailing list, and a service record, spelled three ways, with two addresses. Matching those records into one identity is a decades-old discipline. LiveRamp's offline recognition technology, AbiliTec, was built to merge separate emails, names, postal addresses, and phone numbers into a single view of one individual, and that lineage runs straight back through the data-hygiene industry. Resolution was always about reconciling many systems of record, not cleaning up one website's traffic.
So the two words carry two histories. Stitching came from "make this clickstream coherent." Resolution came from "make these databases agree." A CDP has to do both, which is precisely why the words collapsed into one and the distinction got lost.
Stitching: the within-source, anonymous-to-known job
Stitching answers one question. Is this activity the same visitor I have seen before, and is that visitor the person who just logged in?
The raw material is identifiers a digital surface generates on its own. On the web that is a first-party cookie value, in Snowplow's vocabulary the domain_userid, which is the default web user identifier. On a mobile app it is a device-scoped ID such as Apple's IDFV or Android's advertising ID. Every session also carries a session ID. None of these tells you who the person is. They are anonymous handles. The known identifier, an authenticated user_id or a hashed email, appears only at the moment someone signs up, logs in, or clicks a personalized email link.
Stitching is the act of linking the anonymous handle to the known one. It runs in two directions, and the difference matters in practice. Forward stitching carries a known identity forward: once you know the cookie on this browser belongs to a logged-in user, you can recognize them on the next visit even before they log in again. Backstitching, the harder and more valuable move, runs the other way. The instant a visitor identifies themselves, every earlier anonymous session tied to that cookie is retroactively reattributed to the now-known person. Snowplow's identity package does exactly this: when a mapping from anonymous identifier to logged-in user_id exists, it backdates the stitched user identifier to that user's earlier sessions. The pre-login browsing and the post-login purchase become one timeline.
Where stitching breaks is well documented because it has been a known problem for over a decade. The anonymous handle is fragile. If a cookie expires or is cleared before the person ever logs in, the early behavioral signal is simply orphaned, with no key to attach it to. Shared devices are the classic failure: a family laptop or a library machine where several people use one cookie, and the system happily stitches strangers into one tangled profile. Snowplow's own documentation warns that if users do not clear cookies between logins on a shared device, multiple users can be wrongly associated with a single cookie. And stitching is confined to surfaces you instrument. It connects the web visit to the app session to the login, all of which you tracked. It does not reach the call center, the store till, or a partner system. That is not stitching's failure. It is simply not stitching's job.
Resolution: the cross-source, durable-profile job
Resolution answers a bigger question. Across every system this company runs, which records are the same human being, and what is the single profile that represents them?
The inputs are not anonymous web handles. They are the identity-bearing fields scattered through the business: email addresses, phone numbers, names, postal addresses, loyalty IDs, CRM contact IDs, account numbers, in-store transaction records. Redpoint Global describes the discipline as finding, cleaning, matching, merging, and relating every disparate signal about a customer into one accurate, current view of an individual, a household, or an entity. The operative words are cleaning and merging. Resolution assumes the inputs are messy, conflicting, and spread across systems that were never designed to agree.
The mechanism is match rules and an identity graph. A match rule is an explicit statement of when two records are the same person: if two records share an email, treat them as one; if two records share a phone and a last name, treat them as one. Apply those rules across every source and you build an identity graph, a map of all the identifiers that belong to a single customer, behind a stable persistent ID that does not change when one email does. That persistent ID is what makes the profile durable. It is the thing the rest of the stack can rely on.
Resolution also has to make a confidence call that stitching mostly does not. Two records sharing a verified email is a deterministic match: exact, high-confidence, low risk of a false join. But people change emails, share a household address, mistype a name, and appear in one source with data another lacks. Probabilistic matching estimates the likelihood that two records are the same person from softer signals, weaker but able to reach cases deterministic rules miss. Resolution lives on that trade-off between match rate and match accuracy. It is a judgment system, not just a join.
Resolution's failure modes are different from stitching's, and worse when they happen. A wrong merge fuses two real customers into one profile, and many CDPs offer no clean unmerge: practitioners describe fixing a bad merge as effectively rebuilding the instance. Resolution is also only as good as its inputs. If offline purchases, loyalty history, and service records never reach the system, the graph is missing edges and the "single profile" is single in name only. And because resolution depends on changeable real-world data, it is never finished. New records arrive, attributes drift, and the graph needs continuous reconciliation. Treating it as a one-time setup is a recurring and expensive mistake.
Why the conflation costs real money
The two jobs use different keys, run at different moments, fail in different ways, and need different governance. Treating them as one word produces specific, repeatable damage.
The buying mistake comes first. A team that needs cross-source resolution, the offline purchase joined to the email profile, watches a demo of slick anonymous-to-known stitching and believes the cross-source problem is solved too. It is not. Most CDP identity resolution, as LiveRamp puts it, is built for first-party data inside the platform and for internal use, not for reconciling every system a company runs. The CDP genuinely does stitching well. The buyer assumed that competence transferred to a job the tool was never strong at.
Then the scoping mistake. Stitching depends on instrumentation: tracking code, SDKs, consistent identifiers across web and app. Resolution depends on data modeling: match rules, deduplication logic, governed pipelines from CRM and point of sale. A project plan that treats "identity" as one work item staffs one and starves the other. Usually it staffs stitching, because that ships with the CDP, and underinvests in the resolution data work, which is unglamorous and needs data engineering most marketing teams do not have.
The damage shows up in operations. A marketer runs several journeys against several partly overlapping lists from different source systems. Without true resolution there is no single entity for a person, so no way to enforce a frequency cap across journeys. The same customer gets hit by three campaigns that cannot see each other. The report double counts. Attribution misfires. And nobody can point to the cause, because everyone believed the CDP was already handling "identity."
Schema rigidity makes it sharper. Traditional CDPs are built around a person and their events, and resolution often needs to model accounts, households, or stores. A B2B team that needs an account-level identity, or a retailer that needs a household, finds the stitching-grade person model cannot express it without ugly workarounds. The tool that nailed the within-source job has no clean shape for the cross-source one.
How they fit together in a CDP, and where this is heading
The two are not rivals. They are a sequence. Stitching is upstream, resolving the anonymous-to-known problem on each digital surface so behavioral data is correctly attributed to a person. Resolution is downstream, taking that person plus every other system's records and producing one durable, cross-source profile. Stitching feeds resolution. Resolution gives the company a profile worth activating. A CDP that does only the first gives you coherent web behavior and a fractured customer. One that does only the second resolves your databases but loses the pre-login journey. You need both, in that order, and you should be able to name which one any given problem belongs to.
The architecture debate now turns on the second job. The composable, or warehouse-native, CDP argument is essentially that resolution belongs in the data warehouse, where every system's data already lands and where match logic can be transparent, auditable, and fully under your control, rather than locked inside a vendor's identity engine with no export. GrowthLoop and Hightouch both press a version of this: real resolution needs all the customer data and custom merge logic, and the warehouse is where both live. Stitching, the real-time anonymous-to-known capture, still fits naturally close to the digital event stream. Several vendors are moving resolution earlier and making it continuous: Snowplow now offers graph-based identity resolution that runs in the pipeline as events flow, rather than as a nightly batch job in the warehouse. The pattern is the same in different clothes: capture and stitch at the edge, resolve against everything, keep both running rather than treating either as done.
AI agents raise the stakes on getting this right. As the 2026 Gartner Magic Quadrant for Customer Data Platforms describes, the market is splitting between CDPs as broad application platforms and CDPs as thin data layers feeding autonomous agents. An agent that decides and acts on a customer cannot tolerate a fuzzy profile. If stitching missed the pre-login intent, the agent acts on half a story. If resolution merged two people, the agent acts on a person who does not exist, and it does so faster and more often than a human ever would. The agentic CDP makes the stitching-versus-resolution distinction more load-bearing, not less, because both jobs now feed a system that will not pause to sanity-check the profile before it acts.
The takeaway is small and durable. When an identity problem lands on your desk, ask one question first. Is this within a source, joining one visitor's anonymous and known activity on surfaces I already track? That is stitching. Or is this across sources, reconciling a person across systems that were never built to agree? That is resolution. They are two jobs. Name the one in front of you, and you will scope it, staff it, and buy for it correctly, instead of discovering eighteen months in that you solved the easier half.
Council summary
This post argues that identity stitching and identity resolution are two distinct jobs that one word hides, and that buying a CDP as if a single feature does both is a quiet, expensive mistake. Stitching is the within-source job of joining one visitor's anonymous and known activity; resolution is the cross-source job of reconciling a person across every system into one durable profile. The council verified the technical claims against primary sources: Snowplow's documentation confirms domain_userid as the default web identifier, the backstitching behavior, and the shared-device cookie warning; LiveRamp's own materials confirm AbiliTec as patented offline recognition technology that resolves name, address, email, and phone to one individual; and the 2026 Gartner Magic Quadrant for Customer Data Platforms confirms the platformization-versus-agentification split the closing section describes. No invented figures or misattributions were found. The reader takeaway is a single diagnostic question: ask whether an identity problem is within a source or across sources, and you will scope, staff, and buy for it correctly.
Comments