Design: Similar Listings for Holiday Rentals

Staybook, a made-up holiday-rental marketplace, shows a row of similar homes on each listing page. Clarify:

• catalogue: about 5,000,000 active listings worldwide, each unique (no two homes are the same item);
• context: the guest has a destination, dates and number of guests;
• goal: help guests who are not sure about this home find one they book; more bookings from the row;
• latency: the row loads with the page, within about 100 ms;
• constraints: every suggestion must be available for the guest's dates and fit the group; and in the same area as the home they are viewing.

Similarity here is subtle.

• Two flats with identical bedroom counts can feel completely different (a beach hut and a city loft).
• What guests consider similar is best learned from what they browse together, not from listed attributes alone.

Learn a vector for each listing from browsing sessions, the way word2vec learns word vectors from sentences:

• a session is the sequence of listings one guest clicks while searching (split when there is a long gap, for example 30 minutes);
• listings that appear close together in many sessions get similar vectors;
• the skip-gram objective: for each listing, predict the listings near it in the session.

Guests implicitly label similarity every time they compare homes.

• Millions of sessions capture subtle shared qualities (houseboats with houseboats, treehouses with treehouses) that no attribute field records.
• The resulting vectors make 'similar' a nearest-neighbour lookup (module 13).

A click shows interest; a booking shows a decision. Use it:

• for sessions that end in a booking, add the booked listing as a context for every listing in the session, not just its neighbours;
• this pulls all the homes the guest compared towards the one they finally chose;
• sessions without a booking still contribute through ordinary neighbours.

Embeddings learned only from clicks capture what looks similar; adding bookings captures what guests treat as alternatives to book.

• That is exactly what a 'similar listings' row should show.

Skip-gram also needs negatives: listings that should be pushed apart. Two kinds:

• random negatives from the whole catalogue: mostly in other cities, so the model easily learns 'different city, different listing' and little else;
• same-market negatives: random listings from the same destination as the target, so the model must learn what distinguishes homes within a place.

Sessions are almost always within one destination, so positives are always local.

• With only global negatives, the model mostly learns geography.
• Same-market negatives force it to learn style, size and price differences within a city, which is the similarity guests care about.

A listing created yesterday has no sessions, so no learned vector. Give it one from similar existing listings:

• find listings nearby (for example within a few kilometres), of the same type (entire home, private room) and similar price;
• set the new listing's vector to the average of a few of their vectors;
• replace it with a learned vector once it appears in enough sessions.

New hosts need visibility to get first bookings and reviews; a reasonable vector puts them in similar rows from day one.

• Location, type and price explain a large part of what guests compare.

At page load, for the listing being viewed:

• look up its vector;
• find nearest neighbours in the same market (a per-market index keeps the search small and local);
• filter by availability for the guest's dates, guest capacity, and any hard search filters the guest set;
• keep the top few hundred for ranking.

Similarity without availability is useless: the most similar home is often booked for those dates.

• Fetching extra neighbours before filtering ensures enough remain (module 13's post-filtering trap).

A ranking model (boosted trees or a small neural network) orders the filtered neighbours, using:

• similarity to the viewed listing (embedding cosine);
• similarity to the guest's session: average similarity to listings they clicked, and dissimilarity to listings they skipped;
• listing quality: reviews, response rate, past booking rate;
• price and location relative to the viewed listing and the guest's search;
• label: booked (strongest), clicked, shown only.

Pure similarity can show near-duplicates of a listing the guest is hesitant about.

• Session features personalise in real time: if the guest keeps clicking homes with pools, the row leans towards pools.

The system has offline and online parts:

• daily: retrain embeddings on recent sessions; rebuild per-market indexes; initialise vectors for new listings;
• precompute: top few hundred neighbours per listing per market, refreshed daily;
• online: availability and capacity filter on the precomputed list, then rank with session features;
• live: the guest's clicks and skips in this session update their session features.

Precomputing neighbours makes the row a fast lookup plus filtering and ranking.

• Daily retraining keeps embeddings current as new listings and seasons change behaviour.

Offline and online:

• offline: for sessions that ended in a booking, take a clicked listing, rank candidate listings by similarity to it, and measure how high the eventually booked listing ranks (the earlier in the session, the harder);
• sanity checks: do nearest neighbours share type, price band and location? do unusual homes (treehouses, boats) cluster together?
• online: click-through and bookings from the row; share of guests who book a listing first seen in the row;
• guardrails: overall bookings, cancellations, host concentration.

The offline test mirrors the product question: does similarity to what a guest looked at predict what they will book?

• Sanity checks catch embeddings that have learned only geography.

Public work this design draws on:

• Grbovic and Cheng, 'Real-time Personalization using Embeddings for Search Ranking at Airbnb', KDD 2018: session-based listing embeddings, booked-listing context, market negatives, cold start;
• Mikolov et al., 'Distributed Representations of Words and Phrases and their Compositionality', 2013: skip-gram with negative sampling;
• Grbovic et al., 'E-commerce in Your Inbox: Product Recommendations at Scale', KDD 2015: item embeddings from purchase sequences ('prod2vec');
• Airbnb's engineering blog posts on embedding-based retrieval for search.

This is one of the clearest public case studies of learning item embeddings from behaviour, and interviewers often know it.

The questions interviewers ask about the similar listings design, from the first screening call to the senior round. Cover the answer, say yours aloud, then compare.

Reading an idea and explaining it are different skills.

• Each answer below is the two or three sentences an interviewer is listening for.
• The reasoning behind each one is in the cards above. If an answer surprises you, go back to that card.

A short build that uses this module's ideas. Write it yourself before looking anything up; the checks at the end tell you whether it works.

An idea you have only read fades in a week.

• Building it once, even in fifty lines, is what makes it yours.
• Interviewers can tell the difference between someone who has read about a loop and someone who has debugged one.