First-Party Data

First-party data entered restaurant vocabulary from digital advertising, where the contrast was with third-party cookies and purchased audience lists. In hospitality the contrast is different and more concrete: it is the difference between a guest relationship the restaurant can reach directly and one that lives inside somebody else’s app. That distinction is what a restaurant CRM is assembled from, and it is also the term most likely to be treated as a guarantee of quality it does not provide.

Is data from OpenTable or Resy first-party data?

Mostly yes, and the useful question is not who wrote the software. A guest who books a table and eats dinner transacted with the restaurant, so the record of that visit belongs to the restaurant even though it was created inside a reservation platform. The reservation platform is a system the restaurant operates, in the same way the point of sale is.

Where it gets less clean is what actually reaches you. Platforms differ in what guest contact detail they pass through with a booking, and some hand over a forwarding address instead of the guest’s own email. Bookings that originate on a platform’s own marketplace can carry less detail than bookings taken through the restaurant’s widget. Delivery marketplaces vary widely, and it is worth checking rather than assuming: some do pass usable guest contact back to the restaurant, and others hand over a relay address or nothing at all. A venue doing heavy delivery volume can therefore hold a solid first-party record of those guests or almost none, depending entirely on which channels it runs.

So the working test for an operator is possession rather than origin. If a guest identifier reaches your systems and stays there when a campaign or a contract ends, it is first-party. If reaching that guest requires going back through an intermediary each time, it is not, whatever the marketing material calls it.

Why isn’t first-party data automatically clean?

Because provenance says nothing about quality. First-party guest data is entered by people mid-service, arrives from several systems that never compare notes, and describes an audience that changes its phone number and surname. The usual state of a restaurant guestbook is a large number of accurate records and a large number of near-duplicates of them.

Four things drive most of the mess. The same guest books with a work email on one platform and a personal one on another. Forwarded and relayed addresses produce records that look like two people. Only the booker gets named, so a six-top enters the system as one guest and five unnamed covers. And free-text notes typed at the host stand hold real information in a form nothing can query. Cleaning this up is matching work, and it is the reason a guest data platform exists at all rather than a folder of exports.

Does owning guest data mean I can market to it?

No. Holding a record and having permission to message the person are separate questions, and they are governed separately. A phone number a guest gave to hold a Friday table was given for that purpose. Using it for a promotional text is a different act, and marketing SMS in the United States requires prior express written consent under the Telephone Consumer Protection Act. Email is looser but not free: the FTC’s CAN-SPAM guidance requires accurate header information, a visible opt-out, and that opt-outs are honoured promptly.

The practical consequence for a guestbook is that consent has to be a field on the record rather than a policy in someone’s head. Which channel the guest agreed to, when they agreed, and where the opt-in was captured all need to travel with the profile, because a group running six venues and three booking platforms cannot reconstruct that later. Suppression then has to apply at the moment of sending rather than per campaign, so an unsubscribe taken at one venue is not undone by a list built at another.

What happens to your guest data if you change platforms?

You keep less than you expect, and this is the sharpest test of whether guest data is really yours. Most reservation platforms will give you a guest list on the way out. What tends not to survive the move is the join: visit history matched to spend, notes accumulated over years, tags, and the sequence of when a guest came and what they did. A list of names and emails is not a guestbook.

A restaurant that holds its own copy of the record is in a different position, because the history sits outside the system it might one day replace. Most operators appreciate that argument for a guest data platform exactly once, usually in the middle of switching books. It is worth asking any platform what an export actually contains before you need one, since the answer varies a great deal between products and is rarely on a feature page.