Case Study: RentHop Hot Listings

The original RentHop exercise asks students to upload a CSV, parse messy amenities, cluster latitude and longitude into neighborhood-like groups, compare logistic regression, a decision tree, and a random forest, then rank the top listings. This case study turns that prompt into a worked article inside the predictive-models section.

The important lesson is not that a random forest is magic. It is that feature engineering plus held-out ranking turns raw marketplace rows into an operating queue.

The Executive Question

Which apartment listings should RentHop move to the front of the experience, and what evidence says those listings are more likely to be Hot?

That wording matters. "Predict Hot apartments" sounds like a modelling task. "Move listings to the front" is the business task. The model earns its keep only if its scores can support that ranking decision.

The Task Contract Comes First

Before touching algorithms, write the predictive task contract. In this case the target is already labelled, but the unit, features, and action still need to be explicit.

Two feature-engineering moves carry the case:

1. Coordinates become segments. Raw latitude and longitude are too granular for a manager to reason about and too continuous for a simple categorical story. K-means turns them into 18 neighborhood-like segments.
2. Amenities become indicators. The features column is text. Parsing the common amenities into yes/no flags lets the model learn that "no fee," "hardwood floors," and laundry-related signals carry demand information.

These are not decorations before the model. They are the model's business vocabulary.

Location Does Most of the Storytelling

The segment map shows why location clustering is more than a technical preprocessing step. It creates a market map a product team can reason about: high-rate value zones, central expensive zones, and small segments that may deserve manual review before becoming rules.

The highest-rate segments are not simply the priciest parts of Manhattan. The top queue leans toward lower-rent Brooklyn, Queens, and upper-Manhattan/Bronx-adjacent segments where a listing can look like strong value. That does not mean those areas are "better" markets. It means the Hot label in this data rewards a price-location-amenity balance.

Amenities and Price Turn Messy Rows Into Signals

Amenities are a good feature-engineering lesson because the raw field looks like prose but behaves like a feature catalog once parsed. The strongest amenity association is no fee: listings with that flag are materially more likely to be labelled Hot than the average listing.

The price pattern is equally important. Hot does not mean expensive. The value bands below the luxury tail carry stronger Hot rates, especially when paired with favorable locations. That is exactly why a listing score should be multivariate: price alone misses the segment context, and segment alone misses the rent/value position.

Model Comparison: A Narrow Win for the Forest

The random forest is the best held-out model in this run, with AUC 0.793. But the logistic regression baseline is close at AUC 0.788. That is a useful result. It says the engineered features are doing much of the work, and the more flexible model adds incremental lift rather than rescuing a weak setup.

For a marketplace, the score-decile chart is usually easier to act on than the ROC curve. The top decile of random-forest scores has a Hot rate of 72.8%, compared with 30.9% overall. That means the model is useful as a ranking system even though no threshold is morally special.

What the Model Leaned On

The winning model leans first on price and value features, then location, then amenities and unit mix. That ranking is inspection, not causation. It says what sorted listings in the historical labels. It does not prove that lowering rent, adding an amenity, or moving a unit to another segment would create a Hot listing.

The managerial use is disciplined: if price/value and location dominate, RentHop should make sure those features are stable, refreshed, and monitored. If a single amenity unexpectedly dominated, that would be a reason to audit the parsing logic and label definition before shipping.

The Deployment Artifact Is the Queue

The model becomes useful when it produces a queue. In the held-out test set, the top 50 predicted listings have an actual Hot rate of 80% and a median rent of $1,500. This is the concrete product output: "here are the listings the platform should consider featuring first."

This queue should not be fully automated on day one. A reasonable deployment path is:

1. Use the score to create a daily candidate list for editorial or marketplace operations review.
2. Track whether featured model-ranked listings get faster renter engagement than comparable non-featured listings.
3. Add a threshold-profit or capacity curve once RentHop knows the value of a true positive placement and the cost of a false positive.

What This Case Teaches

The RentHop case connects five ideas from Part IV:

1. Task design. The model predicts a listing label so RentHop can rank listings.
2. Feature engineering. Coordinates and text become business-readable features.
3. Generalization. A 70/30 held-out split grades the ranking before the queue is trusted.
4. Model comparison. The random forest wins narrowly, which keeps the baseline honest.
5. Deployment framing. The score must turn into a queue, a threshold, and a monitoring loop.