CDP (Customer Data Platform)

CDPs came out of digital retail. A shopper browses, adds to a cart, abandons it, opens an email, and buys three days later, and all of that happens on a website and an app the retailer owns. The CDP Institute, the industry body for the category, describes a CDP as packaged software that builds a persistent, unified customer database and makes it accessible to other systems. Hospitality wanted the same thing and found the model did not transfer cleanly, which is why the guest data platform exists as a separate category rather than as a vertical skin on a CDP.

What is the difference between a CDP and a guest data platform?

The difference is where the hard work sits. A CDP is built as an ingestion and activation layer, and it assumes clean events are already being produced somewhere upstream. Its own contribution is to unify, segment, and distribute them. In ecommerce that assumption holds, because a snippet on your own site emits every page view and every purchase in a consistent shape.

A guest data platform has to produce the events itself, and it has to do it from systems it does not control. There is no snippet on a dining room. The record of a meal is split between a reservation platform that knows who booked and a point of sale that knows what a table spent, and joining those two is guesswork constrained by table names and timestamps. That reconciliation is the whole of the difficulty in hospitality guest data, and it happens entirely before the part a CDP considers its job.

Activation differs too. A CDP’s outputs are ad platforms, email tools, and a data warehouse. A guest data platform’s most important output is the reservation book itself, since a tag that never reaches the host stand cannot change a greeting.

Why doesn’t a restaurant have the data a CDP expects?

Because the events are physical and the systems belong to somebody else. Three specific gaps come up every time.

There is no login. Ecommerce identity is anchored on an account and a device, so a returning shopper is recognised before they do anything. A guest walks in, gives a first name at the host stand, and pays with a card. Identity has to be inferred after the fact from a phone number, an email, a card token, or a table at a time, and often it cannot be inferred at all.

The behaviour is offline. Nothing emits a signal when a guest lingers at the bar, orders the tasting menu, or brings a party of eight. Those facts only exist as a check and a booking, and only if both systems recorded them and something later joins them up.

The systems are third-party. A retailer instruments its own storefront. A restaurant’s guest data is created inside Resy, OpenTable, Toast, Square, Tripleseat, and a reviews platform, each with its own API, its own fields, and its own rules about what it will hand over. What a platform can know about a guest is capped by what those systems pass through, and that varies more than any vendor implies.

Can a restaurant group run a general-purpose CDP?

Technically yes, and a handful of large groups do, usually alongside a data team. What you take on is the part the CDP does not do: building and maintaining a connector for every reservation platform and point of sale in the estate, writing the logic that matches checks to bookings, resolving duplicate guests, and then building the path back into the book so the floor sees any of it. That is a multi-year engineering commitment rather than an implementation.

The comparison people usually reach for is a general CRM, and it lands the same way. HubSpot has no native connection to a reservation platform, so bridging it means commissioning custom work, and the connectors that exist tend to import bookings as marketing contacts. The data then flows one way. A contact record that came from a reservation can be emailed, but it cannot be reconciled against the check the guest paid or pushed back onto tonight’s booking as a note for the host.

What does the CDP model get right for restaurants?

More than the differences suggest, and the borrowing goes in one direction for good reason. The core CDP structure of a persistent profile with an event stream attached is exactly right for a guest, because a guest is a slow sequence of visits rather than a row in a list. So is the discipline of holding consent on the profile instead of in each sending tool, the practice of building segments from behaviour rather than from static lists, and the principle that the profile should be readable by any system that needs it.

Hospitality’s version keeps that architecture and replaces the vocabulary underneath it. Sessions and carts become visits and checks. Products become menu items and categories. Lifetime value stops being an order history and becomes dining spend plus events, catering, retail, and hotel stays where a group runs them. The plumbing is recognisable to anyone who has worked with a CDP, and the join at the bottom of it is the part with no ecommerce equivalent.