Airbnb NYC Dataset - Demand Proxy Rationale

Google Colab notebook: Open in Google Colab · Raw Notebook: Download .ipynb

The Airbnb NYC 2019 dataset is useful for exploring listing-level patterns, but it has one important limitation: it does not contain direct demand measures. There are no actual booking counts, occupancy rates, revenue figures, or guest ratings that can be used as a clean target variable.

The notebook therefore tests whether reviews_per_month can act as a practical proxy for guest demand. It does not treat reviews as equivalent to bookings; the question is whether review activity behaves like a meaningful demand-related signal that can support later modelling work.

Why a proxy was needed

A machine learning model needs a target variable. Here, the business question is whether Airbnb listing features can help identify listings that appear to attract stronger guest activity. However, the dataset only provides indirect indicators of activity, such as:

• number_of_reviews
• last_review
• reviews_per_month
• availability_365

Of these, reviews_per_month is the most useful starting point because it provides a normalised measure of ongoing review activity. Listings with no monthly review activity were assigned a value of zero, which keeps the proxy measurable across the full dataset.

Creating the review-activity proxy

I created a new binary flag called review_activity_proxy.

I calculated it by:

1. Filling missing reviews_per_month values with zero.
2. Calculating the 75th percentile of the filled review-rate distribution.
3. Flagging listings at or above that threshold as proxy-positive.

The resulting proxy identifies listings with relatively high review activity compared with the rest of the dataset. It creates a reproducible success flag that can later be used as a classification target.

This is still only a proxy. A listing may receive more reviews because it has more bookings, but reviews are also affected by guest behaviour, host practices, listing age, and other factors. For that reason, the notebook treats the proxy as a preliminary demand-related signal rather than a direct measure of true demand.

Checking whether the proxy makes business sense

I then checked whether the proxy behaved in a plausible way. A useful proxy should not look random or disconnected from the rest of the dataset.

I checked this in two ways.

The spatial plot uses longitude and latitude to show whether proxy-positive listings appear within recognisable Airbnb market areas across New York City rather than being distributed without structure.

I also explored listing-title length by cleaning the name field, calculating title length, grouping titles into bands, and comparing proxy-positive rates across those bands. This tests whether the proxy relates to listing presentation as well as location.

Neither check validates demand on its own. Their purpose is to see whether the proxy has interpretable relationships with other listing fields rather than behaving like an arbitrary review count.

Why this matters for later modelling

The later modelling task depends on the credibility of the target variable. If that target were arbitrary, even a technically strong model would have limited business value.

By showing that the proxy is:

• derived from an existing numeric field,
• consistently reproducible,
• linked to spatial listing patterns,
• related to title-length patterns, and
• interpretable within the Airbnb business context,

the notebook provides a stronger rationale for using reviews_per_month as a preliminary demand-related success flag.

Key takeaway

Without confirmed booking or occupancy data, the notebook cannot prove true Airbnb demand. However, reviews_per_month is measurable, reproducible and connected to observable listing characteristics, making it a defensible preliminary target for this exploratory project. Any later model should still describe it as a proxy rather than evidence of confirmed demand.