Zero-Party Data

Restaurants have been collecting zero-party data since long before anyone in marketing named it. The special-requests box on a booking, the allergy a host writes down, the line in a regular’s file about the corner table: all of it is information a guest volunteered rather than something the restaurant worked out. The term is useful anyway, because it separates the highest-value material in a guestbook from the rest, and because it is the category most likely to be captured and then lost.

Where does a restaurant actually get zero-party data?

From five ordinary places, and only one of them is a marketing channel.

• The booking itself. Special-request fields, occasion pickers, and dietary notes entered by the guest when they reserve.
• The floor. What a guest tells a host, a server, or a manager during a visit, which is the richest source and the one least likely to be written down anywhere durable.
• A pre-visit message. A confirmation email or text that asks whether there is an occasion or a restriction the kitchen should know about.
• A post-visit survey. One or two questions after a meal, which is also where preferences surface that a guest would not have volunteered at the table.
• A signup form. A birthday field on a loyalty or mailing-list signup, given knowingly in exchange for something.

Volume is not the point with any of these. A restaurant might hold thousands of observed visits and a few hundred stated facts, and the stated facts will do more work in service.

What is the difference between zero-party and first-party data?

Zero-party data is declared and first-party data is observed. Both belong to the restaurant, and both were collected directly, so the difference is not one of ownership. A guest ordering the Barolo three visits running is behaviour the restaurant noticed. The same guest saying they are allergic to shellfish is a statement they made, and it commits the restaurant to something the observed data does not.

That is why the distinction earns a name. Observed data supports a probability, so a wine tag derived from spend is a reasonable inference that can be wrong without much cost. A stated fact carries an obligation, and getting it wrong is a visible failure in the room. A guest who mentioned an allergy at their last visit and is asked again from scratch has learned something about how the restaurant keeps records, and a volunteered anniversary that goes unacknowledged is worse than never having asked.

Why does volunteered guest data get lost?

Because it arrives as prose and gets stored as prose. “Wife’s birthday, first time here, would love a quiet table” is three separable facts typed into one free-text box on one booking. A person reading that booking can act on it. Nothing else can. The guestbook cannot list every guest with a quiet-table preference, the kitchen never sees the birthday unless somebody carries it across, and next year nothing remembers the date.

Three further leaks compound it. The note sits on a single booking rather than on the guest, so it does not reappear at the next visit. It sits in one venue’s book, so a group with several restaurants keeps the same guest’s preferences in several places. And it sits in one platform, so changing systems loses it. Turning stated facts into structured fields is the only fix that survives all three: a dietary restriction as a flag, a seating preference as a tag from a fixed list, an anniversary as a date, and the prose kept alongside for the specifics that resist structure.

Which volunteered facts expire?

Some are permanent, some are seasonal, and some are true for one night, and a guestbook that treats them alike will embarrass you. This is the distinction most tagging schemes miss.

Standing facts persist until the guest changes them. Allergies, dietary practice, a preference for the banquette, a dislike of the back room. These belong on the profile indefinitely and should be surfaced on every booking.

Recurring facts fire on a date. Birthdays and anniversaries are the whole category, and their value is that they come round again, so they need to be stored as dates rather than as a note that says “celebrating tonight.”

One-off facts expire the moment the visit ends. Celebrating a promotion, in town for a conference, hosting a client, bringing parents who are visiting. Left on a profile as a permanent tag, these accumulate into a record that describes a guest who no longer exists. The honest treatment is to attach them to the visit rather than to the person, so the history reads correctly later without steering the next reservation.

Consent runs alongside all of it. A guest handing over a phone number so the kitchen can ask about an allergy has not agreed to receive a marketing text. Those are two separate permissions, and the record has to store them separately or the restaurant will eventually use one as though it were the other.