Hotel CDP vs guest identity layer: what the two terms actually mean

Most hotels do not need another marketing suite. They need the record underneath the one they already have to stop belonging to it. A customer data platform and a guest identity layer look almost identical on a slide, and they differ in what they are for, what the resolved data is coupled to, and what survives when you change vendors.

This page defines both, shows where a packaged marketing suite and an identity layer diverge by design, and gives you a way to work out which you actually need. We are not neutral: we build an identity layer. The argument only works if the case for a CDP is put properly, so it is put properly.

What a CDP is, precisely

David Raab coined the term in 2013, and the CDP Institute he founded has maintained the definition since. Most articles you will read quote the old one, about packaged software creating a persistent, unified customer database. That wording has been retired. As the Institute states it in 2026, a CDP is “software that creates and maintains a persistent, unified customer record that is accessible to other systems”, and it goes on: “The CDP assumes primary responsibility for defining and maintaining customer identity and customer record structure over time.”

Read that second sentence again, because it is the whole argument and it comes from the category’s own standards body rather than from us. A CDP is defined by taking responsibility for who your customers are. Not storing data about them. Deciding, and continuing to decide, which records are the same person and what shape that person’s record has.

That is an enormous responsibility to hand a vendor, and it is a perfectly reasonable one to hand a good vendor. The question this page is about is not whether the responsibility should exist. It is whether you can take it back.

A packaged suite and a thin layer

Most hotel CDPs are marketing suites with a data engine attached. The unified profile exists to feed email, upsell and reputation modules sold by the same vendor. Useful, and not yet a unified guest profile in the group sense: one person across properties and systems, rather than a campaign object inside one suite. Suites like this are easy to buy and quick to show a return on, because everything is already wired to everything else. It is also why the guest record and the marketing tool share a fate. You cannot usually keep one and replace the other.

A guest identity layer optimises for the record instead. Its job is to resolve fragmented guest data from the PMS, the POS, the booking engine, the spa and the restaurant into one record that belongs to no application, and to expose that record through open interfaces so anything can read it, including tools the vendor does not sell and has never heard of. Activation is somebody else’s job. The layer stays deliberately thin.

This is not better against worse. It is coupled against decoupled. A coupled suite is simpler if you are happy running guest marketing inside one vendor for years, which plenty of groups are. A decoupled layer starts to matter the moment you expect to change your email tool, your PMS or your upsell engine and keep the guest record intact through it.

Identity graph and golden record

These two get used interchangeably and they are not the same thing.

An identity graph is the web of identifiers and the links between them: this email, that phone number, this loyalty ID, that folio, all judged to belong to one person, with the evidence for each link kept alongside it. A golden record is the single reconciled profile you get when you collapse that graph and let rules decide which value wins wherever two fields disagree.

Resolution builds the graph two ways. Deterministic matching joins records on an exact shared identifier, a hashed email address or a loyalty number, which is high confidence and explainable: you can always say why two records were merged. Probabilistic matching infers that two records are the same person from weaker signals combined, which extends reach at the cost of certainty. Serious systems run deterministic matching as the backbone and probabilistic matching to widen coverage, with the confidence threshold set high enough that two different guests never collapse into one. Merging two people is a worse failure than missing a link, because the guest who inherits somebody else’s allergy note finds out the hard way.

Here is why the distinction decides the CDP question. A golden record is portable as a flat snapshot: a file of profiles, which any system can load. The graph is where the value compounds, because it holds the match keys and the evidence. A vendor can hand you a complete export of golden records on the day you leave and still keep the thing you spent five years paying for, which is the resolution logic and the keys that made it work. Ask any platform whether you can export the graph, not just the record. Most cannot, and the honest ones will say so.

The API and MCP question

An identity layer is only worth as much as its interfaces. Two matter right now.

A public REST API lets your other systems read and write the guest record programmatically, in bulk, without asking anybody. That is the difference between having the data and being shown it. Several hotel CDPs offer one, though often as a paid add-on, and often read-limited in ways that only become clear once you are using it.

The Model Context Protocol is newer and widely misunderstood. Anthropic introduced it in November 2024 as an open standard for connecting AI models to external tools and data. The other major model providers adopted it through 2025, and on 9 December 2025 Anthropic donated it to the Linux Foundation’s Agentic AI Foundation, alongside projects contributed by Block and OpenAI, by which point there were more than 10,000 active public MCP servers. It is now the ordinary way an agent reaches a data source, which is exactly why “we support MCP” has stopped being informative on its own.

In hospitality it is being used for three quite different things, and the difference is the point.

The first is pushing rates and inventory out to public AI assistants. Cendyn’s AI Connect, announced in November 2025 as an invite-only beta, sends availability, rates and inventory into ChatGPT, Claude and Gemini over MCP so that a traveller planning a trip sees the hotel’s direct rate. That is distribution. The audience is the public’s assistants, and the subject is rooms.

The second is exposing hotel systems to the hotel’s own staff. Apaleo shipped what it described as hospitality’s first PMS MCP server in September 2025, turning its API endpoints into tools an agent can call to check availability, modify bookings and build profiles. dailypoint added MCP support in June 2026 so hotel teams can query selected guest data through an AI assistant. That is operations.

The third is what an identity layer does: exposing the resolved guest identity to the hotel’s own agents, so a revenue agent or a front desk assistant reasons over one guest record rather than five system logins. Telling your own house who the guest is and telling the open internet which rooms are free are different acts with different risks. Both are legitimate. They are not substitutes, and a group should know which one it is being sold.

The composable CDP argument, and whether it has reached hotels

Outside hospitality, the CDP category split some years ago. Packaged CDPs store and process data in their own systems. Composable, warehouse-native CDPs leave the data in the customer’s own warehouse and push it out to the tools that need it. The pitch is control: your data never leaves infrastructure you already own.

The counter, which the people selling it will tell you themselves if you ask, is that composable mostly moves the assembly work onto you. You still need ingestion, resolution, activation and messaging, now spread across four or five contracts and four or five vendors to chase when something breaks. Warehouse query latency can also make real-time activation harder rather than easier.

This debate has barely touched hospitality, and for a good reason. Hotels do not run cloud data warehouses. They run a PMS and a stack of point solutions, usually with nobody in-house whose job is data. The composable model as built for enterprise marketing teams with data engineers does not transplant. Its underlying insight does: the layer that resolves and holds your customer identity should be a layer you can point any tool at, rather than a room inside one vendor’s house. An identity layer that sits outside every application is that idea in a shape a hotel group can actually run, without asking anyone to operate a warehouse.

Which one you need

You want a packaged marketing suite if your first problem is sending better guest email and running upsell and reputation campaigns, you want one vendor accountable for that whole workflow, you are comfortable with the guest record living inside it, and you do not expect to separate the record from the marketing tool for several years. That is a real and common position, and a mature suite will serve it well.

You want a guest identity layer if you want the resolved record to stand independently of any marketing, PMS or upsell tool; if you expect to change one of those and keep the record; if you want your own agents reading one guest identity; or if you care about being able to prove, contractually and technically, what happens to the full record and its match keys when you leave. A layer sits beneath the CDP, the PMS and the agent platforms. It is infrastructure rather than an application.

Plenty of groups will end up wanting both: a thin layer underneath, and a marketing tool on top they can change when it stops suiting them. The mistake is buying a suite and assuming the record came with it. What came with it was access.

When hospitality CDP identity resolution is enough

A packaged suite is enough when one vendor already runs email, upsell and reputation, the group is on one PMS, and nobody expects to separate the record from that suite for years. That is a real position. It outgrows that across more than one PMS, or when CRM, agents and loyalty must read the same person the suite uses. Resolution inside one activation product then leaves every other tool with a partial guest.

Can a hotel group run a CDP and an identity layer together?

Yes. They do different jobs. The layer resolves the person and holds the record above the stack. The CDP, CRM or loyalty tool reads that record and activates it. Plenty of groups keep the suite they already bought and put a thin layer underneath, so a later tool change does not take the graph with it. Two resolvers will fight. Pick one.

The matching work is guest identity resolution. The record it produces is the hotel master profile. A hotel semantic layer then gives those fields a shared meaning.

Ask for the mechanism, not the word

Every hotel vendor now talks about ownership of the guest record. The word has been worn smooth, and we have stopped using it about ourselves: Casa Layer builds the Master Profile and holds it, so it is not yours in any sense a lawyer would recognise. What is true is narrower and testable, so test it, and test the vendor sitting next to us, against four things that either work or do not.

Can you read the full record from the tools you already run, rather than only from inside the vendor’s own application? Can you see the identity graph and the match keys, or only the collapsed golden record? If you switch your PMS or your marketing tool, does the record survive intact, or does it leave with the vendor? And can you enforce a consent decision or a deletion, and prove afterwards that it happened?

A CDP and an identity layer can both claim ownership, and both will. Ask for the mechanism rather than the word, and ask it of us too, because the obvious objection to everything above is that we hold a record while arguing that vendors should not hold records. The answer is that we sell none of the applications the record feeds, so there is nothing here for it to be locked into, and the third question is where that shows: replace your CRM, your PMS or your upsell tool and the resolved record is untouched, because it never lived inside any of them. Our answer to the first is a control rather than a promise: Casa Layer runs on credentials you issue, scoped per system, so what we can reach inside your PMS, your POS and your booking engine is set by you and closed by you. Note the shape of that. It is not a pledge about what we would never do, which costs a vendor nothing to make and nothing to break. What changing vendors costs you is the resolution work, not the underlying data, which is why the question above about the graph matters more than the one about the profiles.

Buying-committee questions

The four tests already on this page, as a list a buying committee can score. Ask them of the vendor sitting next to us as well.

1. Can you read the full record from the tools you already run, rather than only from inside the vendor’s own application?
2. Can you see the identity graph and the match keys, or only the collapsed golden record?
3. If you switch your PMS or your marketing tool, does the record survive intact, or does it leave with the vendor?
4. Can you enforce a consent decision or a deletion, and prove afterwards that it happened?

Golden record export versus keeping the graph

On the day you leave, a file of profiles is the easy gift. It is also the cheap one. The graph is the match keys, the evidence, and the logic that joined an OTA folio to a direct stay. Without those, the next system starts resolution from scratch. Ask for the graph, not only the golden record, and ask it of any vendor, including us. A complete profile export can still leave the expensive part behind.

Frequently asked questions