PRD: Member Personalization

Product Principle: Outcome Over Features

The requirements, ideas, examples, and proposed features in this PRD are not mandatory implementation instructions.

They should be treated as hypotheses or possible solutions to achieve the product goals. Some ideas may be incorrect, incomplete, too complex, or less effective than alternative approaches.

The most important requirement is to improve the actual goal metrics, such as engagement, CTR, booking conversion, repeat booking, coverage, and recommendation relevance.

The team should not implement a feature only because it is written in the PRD. Each feature should be evaluated based on expected impact, feasibility, data availability, user value, and measurable contribution to the success metrics.

If there is a simpler, faster, or more effective solution that can better improve the goal metrics, the team should propose and prioritize that solution instead.

1. Overview

We are building a dynamic personalization system for logged-in members.

The system will personalize homepage sections, section titles, restaurant recommendations, destination recommendations, and section ordering based on member profile data, booking history, browsing behavior, preferences, location, and segmentation.

The goal is to help members discover restaurants, destinations, and experiences that match their past behavior and preferences.

Example: A Korean member who previously booked Audrey and often books Japanese restaurants may see:

Because You Dined at Audrey
Top Picks for Japanese Lovers in Bangkok
Korean-Loved in Bangkok
Re-book Your Favorites
New Omakase & Sushi Since Your Last Visit

2. Goals

Primary Goals

Increase member engagement.
Improve recommendation relevance for logged-in users.
Drive repeat bookings.
Help members discover new restaurants based on past behavior.
Personalize homepage sections using booking history, browsing history, preferences, and profile data.
Support dynamic section ordering and personalized section titles.
Support scalable member segmentation across countries, cities, cuisines, price tiers, group sizes, and activity levels.

Business Goals

Increase booking conversion from logged-in members.
Increase repeat booking rate.
Increase cross-sell and upsell opportunities.
Improve retention for active users.
Reactivate churn-risk users.
Support campaign targeting for member segments.

3. User Type

Members are logged-in users.

Member personalization may use both anonymous signals and member-specific signals.

Examples of member-specific signals:

Profile country
Preferred language
Booking history
Browsing history
Saved restaurants
Favorite restaurants
Cuisine preferences
Price preferences
Group size behavior
Loyalty status
Last booking
Most-booked restaurants
Viewed but not booked restaurants

4. Scope

In Scope

Personalized homepage sections for logged-in members.
Dynamic section titles.
Dynamic section ordering.
Dynamic restaurant and destination recommendations.
Booking-history-based recommendations.
Browsing-history-based recommendations.
Preference-based recommendations.
Content-based filtering.
Collaborative filtering.
Rebooking recommendations.
Cuisine affinity recommendations.
Price sensitivity recommendations.
Group size recommendations.
Activity and churn-risk segmentation.
Manual segmentation from CMS.
Automatic segmentation using rules and machine learning.
Admin controls to enable, disable, and prioritize member sections.

Out of Scope

Guest-only personalization without member data.
Anonymous-only recommendation flows.
Full loyalty program design.
Full CRM campaign execution.
Restaurant inventory management outside recommendation eligibility.

5. Key Member Personalization Features

5.1 Behavioral Personalization

The system should personalize content based on member behavior.

Behavioral signals include:

Past bookings
Restaurant views
Search history
Saved restaurants
Favorite restaurants
Clicked sections
Viewed but not booked restaurants
Last booking city
Last booking area

Example: If a member dined at Audrey, the system may show: “Because You Dined at Audrey.”

5.2 Content-Based Filtering

The system should recommend restaurants similar to restaurants the member previously booked, viewed, saved, or liked.

Restaurant similarity may use:

Cuisine
Location
Price tier
Ambience
Dining occasion
Menu type
Tags
Popularity
Restaurant category
User interaction history

Example: If a member frequently books Japanese restaurants, the system may show: “Top Picks for Japanese Lovers in Bangkok.”

5.3 Collaborative Filtering

The system should recommend restaurants based on behavior from similar members.

Example: If members who booked Audrey also booked After You Dessert, Greyhound Cafe, and Kub Kao’ Kub Pla, these restaurants may appear in “Because You Dined at Audrey.”

5.4 Rebooking Recommendations

The system should recommend restaurants the member has booked before.

Example section: “Re-book Your Favorites”

Eligible restaurants may include:

Most-booked restaurants
Recently booked restaurants
Favorite restaurants
Restaurants with new promotions
Restaurants with new availability

5.5 Recovery Recommendations

The system should recommend restaurants the member viewed but did not book.

Example section: “Still Interested?”

This section may include:

Restaurants viewed but not booked
Restaurants added to favorites but not booked
Restaurants searched multiple times
Restaurants with newly available slots
Restaurants with active promotions

5.6 Location-Based Personalization

The system should personalize recommendations based on member location and booking areas.

Examples:

Near your last booking area
Popular near EmQuartier
Restaurants near Thonglor
Bangkok picks for Korean members

5.7 Manual Member Segmentation

Admins should be able to create manual member segments in CMS.

Example segments:

vip_gold
korean_members_browsing_bangkok
bangkok_anniversary_promo_members
active_members_in_bangkok
churn_risk_members
japanese_lovers
budget_friendly_members
luxury_diners
couple_diners
group_diners

Manual segmentation rules may include:

Profile country
Current browsing city
Login status = member
Loyalty status
Booking count
Last booking date
Cuisine preference
Price tier
Campaign eligibility
Promo eligibility

5.8 Automatic Member Segmentation

The system should automatically detect member segments using rules and machine learning.

Example automatic segments:

Cuisine Affinity

Rule: If a member booked at least 3 restaurants with cuisine = Japanese in the last 90 days, assign segment = loves_japanese.

Variants:

loves_thai
loves_seafood
loves_bbq
loves_buffet

Use: Prioritize sections such as “Top Picks for Japanese Lovers in Bangkok.”

Price Sensitivity

Rule: If at least 70% of bookings are in the lowest price tier, assign segment = budget_friendly.

If at least 70% of bookings are in the highest price tier, assign segment = luxury_diner.

Use: Show “Pocket-Friendly Today” or “Premium Dining Experiences.”

Group Size

Rule: If median covers per booking is 4 or more, assign segment = group_diner.

If median covers per booking is 2 or less, assign segment = couple_diner.

Use: Show “Family & Group Dining” or “Date Night Picks.”

Location / Traveler Segment

Rule: If member profile country is different from browsing city country, assign segment = traveler_from_[country].

Example: Profile country = Korea and browsing city = Bangkok -> traveler_from_KR.

Use: Show “Korean-Loved in Bangkok.”

Recency / Activeness

Rule: If last booking was within 30 days, assign segment = active_user.

If no booking for 90 days, assign segment = churn_risk.

Use: Active users receive fresh recommendations. Churn-risk users receive reactivation deals.

Device / Platform

Rule: Device = iOS -> segment = ios_user. Device = Android -> segment = android_user.

Use: Support A/B testing for ordering, layout, and content.

6. Member Segmentation Inputs

The system should support the following member segmentation inputs:

Profile Inputs

Member ID
Profile country
Preferred language
Loyalty status
Saved preferences
Declared city or country
Account age

Booking Inputs

Past bookings
Last booking
Most-booked restaurants
Booking frequency
Booking city
Booking area
Cuisine booked
Price tier booked
Group size
Dining occasion
Booking recency

Browsing Inputs

Viewed restaurants
Viewed destinations
Search keywords
Clicked sections
Viewed but not booked restaurants
Saved restaurants
Favorite restaurants
Time spent on pages

Location Inputs

IP country
Current city being browsed
Latitude/longitude if available
Last booking area
Country-to-city mismatch

Device Inputs

iOS
Android
Desktop
Tablet
Browser type

7. Member Segmentation Outputs

Member segmentation should produce:

Personalized section list.
Personalized section titles.
Personalized restaurant recommendations.
Personalized destination recommendations.
Personalized section order.
Rebooking sections.
Recovery sections.
Cuisine affinity sections.
Price sensitivity sections.
Group size sections.
Loyalty or campaign sections.
Churn-risk or reactivation sections.

8. CMS and Admin Requirements

Admins should be able to:

Create member segments.
Edit member segment rules.
Enable or disable member segments.
Assign sections to member segments.
Configure section priority.
Configure fixed and dynamic sections.
Configure fixed and dynamic section ordering.
Preview homepage output by member segment.
Preview output for a specific member ID.
Set campaign start and end dates.
Set promo eligibility.
Configure loyalty-based content.
Monitor section performance.

9. Section Configuration Rules

Each section should support the following configuration:

Section Type

Fixed section
Dynamic section

Fixed section: The section must always appear for the selected segment.

Dynamic section: The section may be replaced by another section depending on ranking logic.

Section Order

Fixed order
Dynamic order

Fixed order: The section must remain in the configured position.

Dynamic order: The section position may change depending on relevance score.

Example

For logged-in members:

“Because You Dined at Audrey” is a dynamic personalized section.
It may appear in position 1 if the recommendation confidence is high.
“Re-book Your Favorites” is a fixed member section.
It may appear in position 2 or 3.
“Top Picks for Japanese Lovers” may appear if the member belongs to the loves_japanese segment.
“Deals Ending Soon” may move up if the member is price-sensitive or churn-risk.

10. Recommendation Ranking Logic

Member recommendation ranking should consider:

Past booking relevance
Restaurant similarity
Cuisine affinity
Price preference
Group size preference
Location relevance
Browsing behavior
Collaborative filtering score
Content-based filtering score
Promotion relevance
Availability
Freshness
Loyalty or campaign priority
CMS priority
Churn-risk status

Example ranking formula:

Member Recommendation Score =
Booking History Score
+ Content-Based Similarity Score
+ Collaborative Filtering Score
+ Cuisine Affinity Score
+ Price Preference Score
+ Location Score
+ Browsing Recovery Score
+ Promo Score
+ Availability Score
+ CMS Priority Score

11. Example Member Scenario

Scenario: Logged-in Member

User context:

Profile country: Korea
Browsing city: Bangkok
Segment: loves_japanese
Last booked restaurant: Audrey
Logged-in status: Member

Recommended homepage sections:

Because You Dined at Audrey
- After You Dessert
- Greyhound Cafe
- Kub Kao’ Kub Pla
- Khao
Top Picks for Japanese Lovers in Bangkok
- Gyu-Kaku
- Sushi Hiro
- Izakaya Teppen
- Ootoya
Korean-Loved in Bangkok
- Bar-B-Q Plaza
- Savoey
- Goji Kitchen
- MK Restaurants
Re-book Your Favorites
- Audrey
- After You
- Greyhound Cafe
- Savoey
New Omakase & Sushi Since Your Last Visit
- Sushi Masato
- Sushi Zo
- TsuNami
- Sushi Niwa
Near Your Last Booking Area
- EmQuartier
- Phrom Phong
- Thonglor
Deals Ending Soon
- Citywide time-boxed promos
Still Interested?
- Restaurants viewed but not booked

12. Functional Requirements

FR1: Detect Member Context

The system must detect logged-in member context using member profile data, booking history, browsing behavior, location, device, and preferences.

FR2: Assign Member Segments

The system must assign one or more member segments.

Example:

member
traveler_from_KR
loves_japanese
active_user
couple_diner
ios_user

Member ID
Profile country
Preferred language
Loyalty status
Booking history
Browsing history
Saved restaurants
Favorite restaurants
Search events
Click events
IP address
Geo lookup
Device metadata
Restaurant metadata
Cuisine metadata
Price tier metadata
Availability data
Promo data
CMS section configuration

System Components

The system should include:

Segmentation Engine
- Assigns member segments using rules and ML.
Recommendation Engine
- Generates restaurant and destination recommendations.
Content-Based Filtering Model
- Finds restaurants similar to those the member interacted with.
Collaborative Filtering Model
- Finds recommendations based on similar members.
Ranking Engine
- Scores and orders sections and cards.
CMS
- Manages sections, rules, priorities, campaigns, and overrides.
Tracking System
- Collects member behavior events.
API Layer
- Serves personalized homepage content.

Performance Requirements

API response time should be less than 200ms.
System should support 1,000+ dynamic segments.
System should support real-time or near-real-time recommendation updates.
System should support high traffic from logged-in members.
Recommendation logic should degrade gracefully if some member signals are missing.

14. Success Metrics

Engagement Metrics

Increase CTR on personalized member sections by 20%.
Increase member session time.
Increase number of restaurant card clicks.
Increase interaction with personalized sections.

Conversion Metrics

Increase member booking conversion rate by 15%.
Increase repeat booking rate.
Increase conversion from “Because You Dined At” sections.
Increase conversion from “Re-book Your Favorites.”
Increase conversion from “Still Interested?”

Retention Metrics

Increase active member repeat visits.
Reduce churn-risk member drop-off.
Increase reactivation bookings from inactive members.

Coverage Metrics

90% of logged-in members receive at least one personalized section.
90% of members with booking history receive booking-based recommendations.
90% of members with browsing history receive recovery or similarity-based recommendations.

System Metrics

API response time below 200ms.
Support 1,000+ member segments.
Recommendation fallback available when signals are missing.
CMS rules applied correctly.

15. Fallback Logic

If member signals are limited, the system should fall back in this order:

Member booking history.
Member browsing history.
Member profile country.
Current browsing city.
IP country.
Browser language.
Device type.
Trending in selected city.
Global popular restaurants.
Editor’s picks.

Example: If the member has no booking history but is browsing Bangkok, show:

Recommended for You
Popular in Bangkok
Trending This Week in Bangkok
Editor’s Picks in Bangkok

16. Open Questions

Which member profile fields are currently available?
Which booking history fields are currently available?
How should restaurant similarity be calculated?
Should rebooking sections be fixed or dynamic?
How should churn-risk thresholds be configured?
How should loyalty status influence ranking?
What is the minimum data required before showing “Because You Dined At”?
Should members be able to hide or dismiss personalized sections?

Keyboard shortcuts

HungryHub Knowledge Base