First-Party Preference Profiles Travelers Actually Trust

A guest books a lodge dinner for two in May and asks for the vegetarian menu. Her sister is vegetarian; she is not. In October she comes back alone, and the kitchen, reading her profile, plans her a tasting menu without the lamb she has been looking forward to since spring.

Nobody did anything wrong, exactly. The system recorded a true fact and then quietly promoted it from “something that happened once” to “who this person is.” That promotion — silent, permanent, unexplained — is how most preference profiles lose trust. Not by collecting too much, but by holding the wrong things too long without remembering where they came from.

This note lays out a design for first-party preference profiles that travelers recognize, agree with and keep feeding. It’s a framework, so it’s opinionated. Take what fits.

First-party is not the same as trusted

“First-party” describes how you got the data: the traveler told you, or you observed it in your own channels. “Trusted” describes whether the traveler would read the profile and nod. The two drift apart quickly.

The stakes are rising because travelers now describe their preferences in full sentences, to software. In an August 2026 study by Mindtrip with Sabre, Sojern and MMGY Travel Intelligence, 54% of U.S. travelers said they had already used AI to plan travel, and 63% said they would use an AI trip planner on a destination’s website. A conversational planner on your own site hears things no booking form ever did: “my husband’s knee is bad,” “we’re celebrating, but quietly,” “the kids get carsick on mountain roads.” That is the richest preference data the industry has ever had. It is also the easiest to misuse.

The design below rests on three properties. Every preference knows where it came from, how far it applies, and when to stop believing it.

The preference ledger

Treat each preference as a ledger entry, not a checkbox. Six fields, every time:

Field	What it records	Example
Value	The preference, in plain language	Prefers to start days after 9 AM
Source	Said, did, or inferred	Said, in a chat on March 4
Scope	This booking, this traveler, or this party	This traveler
Review date	When to confirm it or let it lapse	Before next booking
Sensitivity tier	0–3 (see below)	Tier 1
Visible to	Which roles can see it	Advisor, guide

None of these fields is exotic. Together they let a system answer the three questions a traveler is silently asking: how do you know that, why does it apply now, and who else knows?

Said, did, inferred

Sources are not equal, and the profile should say so. A stated preference (“no early starts”) outranks an observed one (three bookings with late check-in), which outranks an inference (a model guessing the traveler isn’t a morning person because they browse at midnight).

One rule does most of the work: inferences may reorder; only statements may exclude. An inferred interest in food can push a cooking class up the list. It cannot remove the sunrise hike from the options, because the traveler never asked you to. When inferences start excluding things, travelers experience it as being decided about, and they’re right.

Scope is the field everyone forgets

The vegetarian dinner was a party-scoped preference stored as a traveler-scoped one. Most profile errors we see are scope errors: the toddler who was on one trip, the accessible room booked for a parent, the budget set by an employer paying for a work trip.

Default new preferences to the narrowest scope that explains them, then ask before widening: “Keep vegetarian meals for future trips?” One tap, and the profile becomes something the traveler built with you rather than something done to them.

Preferences have half-lives

People change, and so do their trips. A profile that never forgets becomes a portrait of who someone used to be. These are the review intervals we start from; adjust them to your guests.

Preference type	Example	Default review
Logistics	Ground-floor room, aisle seat	3 years
Pace and rhythm	Late starts, two activities a day	18 months
Interests	Pottery, birding, natural wine	2 years
Party composition	Traveling with a toddler	End of trip
Dietary needs	Nut allergy, halal meals	Confirm each booking
Mobility and health	Avoids stairs, needs rest stops	Confirm each trip

Note the last two rows. Dietary and mobility needs are never assumed to persist, and never assumed to have changed. You confirm them each time, briefly, because getting them wrong in either direction is costly.

Sensitivity tiers decide what you may do

Not all preferences carry the same risk. A four-tier scheme keeps staff, models and vendors on the same page.

• Tier 0, operational. Arrival time, room location, preferred contact channel. Use freely to run the trip.
• Tier 1, taste. Food, art, pace, activity level. Use to personalize; always visible to the traveler.
• Tier 2, sensitive. Health and mobility needs, allergies, children’s ages, pregnancy, dietary requirements tied to faith. Collect for a stated purpose, restrict to the roles that need it, and delete after the trip unless the traveler chooses to keep it.
• Tier 3, never infer. Religion, health conditions, sexual orientation, income, ethnicity. You may accept what a traveler tells you; you never derive these from behavior.

The working principle for the top two tiers: store the need, not the identity. Record “halal meals,” not a religion. Record “step-free routes, rest every 45 minutes,” not a diagnosis. The need is what the kitchen and the guide act on; the identity is a liability you never needed to hold. If you are drafting the policy behind these tiers, our responsible AI and traveler data governance work starts from exactly this split.

Earn every question

Long intake forms are the second way profiles lose trust. Travelers can sense when they’re feeding a database rather than shaping a trip. We run a three-part test before any question goes in front of a traveler:

1. It changes a decision. The answer alters at least one choice in the next itinerary.
2. You can show the change. The traveler sees the effect, ideally right away.
3. You can’t already know it. You aren’t asking for something they told you last time.

In a pilot with a small collection of desert lodges, applying that test cut a pre-arrival questionnaire from 19 questions to 6. In our measurement, completion rose from 34% to 71% of guests, and the six answers were actually used, because each one was attached to a decision someone downstream made.

Ask at the moment the answer pays off

The best time to ask about pace is not at sign-up. It’s when you show day two of a proposal and can ask, “Two activities, or three?” The answer reshapes the day on screen. That’s progressive profiling with a visible payoff, and it’s the pattern behind good intent capture in an itinerary builder: every question lands in a draft the traveler can watch change.

Show your work

A trusted profile is one the traveler can read. Give them a plain-language page, not a settings screen, that reads something like this:

What we remember about you You like to start days after 9 AM — you told us in March. You’ve booked two guided hikes, so we’ll suggest more — we noticed this; tap to correct. Vegetarian meals — for your May trip with a companion. Keep for future trips?

Each line carries its source and a way to change or forget it. The same honesty belongs inside the trip. When an in-trip assistant changes a plan because of a stored preference, it should say so: “Because you’d rather not drive after dark, I moved dinner to the lodge.” A travel concierge that names the preference it acted on turns personalization into something the traveler can steer.

The plumbing behind the promise

Profiles fail quietly when they’re copied. The PMS holds one version, the CRM another, the booking system a third, and the messaging channel remembers whatever the last agent typed. Correct one and the others keep the error alive.

The fix is unglamorous: one profile store that every other system reads by reference; consent stored alongside each preference rather than in a separate table; and an identity-resolution step that merges the guest who booked by email with the same guest who later messaged by phone. That’s ordinary travel data engineering, and when we scope this work at Nova Adventure, it usually comes before any model.

AI agents add a wrinkle. When a traveler’s assistant books on their behalf through an agent-facing booking interface and passes preferences along, accept them for that booking and scope them there. Ask the traveler directly before promoting anything an agent told you into the long-term profile.

Measure trust instead of guessing at it

You can watch trust in the data. Five signals worth tracking:

• Correction rate. How often travelers edit a remembered preference. Some editing is healthy; a rising rate means inferences are overreaching.
• Forget rate. Deletions per hundred profile views. A spike usually points at one specific field.
• Keep rate. How often travelers say yes to “keep this for future trips?” A low rate suggests you’re asking to widen scope too eagerly.
• Acceptance of preference-driven changes. When a plan changes because of a stored preference, does the traveler keep the change?
• Unprompted mentions. Support messages containing “how did you know” or “creepy.” Read every one.

Where to start this week

Pull ten guest profiles at random. For each stored preference, try to answer three questions: where did this come from, does it still apply, and who can see it? Wherever you can’t answer, add the missing field. Wherever a Tier 3 inference turns up, delete it today.

Then find one intake question that fails the earned-question test and remove it. Finally, pick one preference a traveler told you and make sure they can see it working in their next itinerary. Small, visible, useful: the profile travelers trust is usually the shorter one.