Airbnb data methodology: how snapshot datasets are built

Every figure in a scraped Airbnb dataset traces back to one decision: someone ran a scraper on a given day and saved what the site showed. This page walks through that pipeline. It covers how Inside Airbnb collects its snapshots, what the availability and review columns actually record, where a one-day capture breaks down, and how researchers squeeze bookings estimates out of two snapshots of the same city. All numbers below come from the files shipped with the Airbnb Listings, 6 US Cities pack and its free sample.

How a snapshot gets made

Inside Airbnb runs scrapes on a periodic schedule, one collection per city per cycle. A run walks the public listing pages, captures one row per visible listing, and writes the result to per-city files published under CC BY 4.0. Three properties of that process shape everything downstream:

• One date per run. Every row in a city file was true on the same day. The file is a photo of the market, not a video.
• Only public pages. A scraper sees what a visitor sees: listing descriptions, nightly calendars going forward, and review history. It never sees bookings, revenue, or host calendars after they changed.
• Privacy scrubbing built in. Summary files blur coordinates by about 11 meters and drop host names, which is what makes the data safe to redistribute.

The 6-city pack takes those per-city snapshot files and normalizes them into one shared 12-column schema. The six cities were captured between 2026-06-22 (Austin) and 2026-08-10 (New York City), a 49-day spread. Airbnb data by city lists the exact date and row count per city.

The columns that carry time

Four of the twelve columns record anything about activity over time: availability_365, number_of_reviews, reviews_per_month, and last_review. availability_365 counts the nights a listing shows as bookable in the 365 days after the snapshot date. The three review fields are cumulative: total reviews, reviews per month averaged over the listing's lifetime, and the most recent review date.

Here is what those values look like in practice, computed from the free 20-row Austin sample (snapshot 2026-06-22):

Half the sample shows 300 or more open nights, which is what an open calendar with light bookings looks like. The tail below 30 nights is where bookings, host blocks, and regulation pile up, and the snapshot cannot tell them apart. Run the same computation on any city file and you get that market's supply-tightness profile for its scrape date.

Where a snapshot breaks down

A one-day capture carries four limits worth planning around:

• Staleness. Listings change daily. A file from 2026-06-22 describes a market that no longer exists in exactly that form, and the gap grows with every week after the scrape.
• Seasonal bias. The six cities here were scraped between late June and mid-August, the peak season for US short-term rentals. Availability counts from a July snapshot read differently than the same market scraped in February. Cross-city comparisons should account for the 49-day spread between the earliest and latest capture.
• Churn. The snapshot sees only listings live that day. Listings created after the scrape and listings delisted before it are invisible, so row counts measure the market's surface on one date, not its total population.
• Unlabeled closed nights. A closed night can be a booking, a host block, a regulatory hold, or a stale listing. availability_365 gives you the count, never the reason. Airbnb occupancy data covers what that means for occupancy estimates in detail.

The two-snapshot diff: a bookings proxy

Scrape the same city twice, d days apart, and diff availability_365 per listing ID. The two windows overlap for 365−d days, so most of the difference comes from what changed inside d days of the first scrape. Booked nights in that window come out as:

booked_nights ≈ (A1 − A2) + d

where A1 is availability_365 at the first snapshot and A2 at the second. The logic: shifting the window forward by d days would add roughly d open nights if nothing was booked, so whatever ate into that shift is consumption. Clamp the result to between 0 and d, then read the edges: A2 below A1 means more nights disappeared than the window shift explains, which signals heavy bookings or host blocks. A2 above A1 plus d means the host pulled nights from the far end of the calendar.

A worked example from the sample: the listing "Close to UT Austin + Rooftop Pool" shows availability_365 of 157 on 2026-06-22. Say a re-scrape 30 days later shows 167. That is (157 − 167) + 30 = 20 booked nights in the window, about two-thirds of the 30 days. If the re-scrape instead showed 150, the diff would be 37, which exceeds the window and gets clamped or flagged, because availability fell by more than the shift can absorb.

Three things to know before running this:

• It needs the same city twice. The 6-city pack ships one snapshot per city, six dates between 2026-06-22 and 2026-08-10. To diff, pair it with a second capture of the same city, from Inside Airbnb's archive or your own scraper, and match on listing id.
• It is a proxy, not a ledger. Cancellations, price-driven calendar changes, and far-tail blocks all land in the same number. Published validations of this method put its error well above what a real booking ledger would show.
• It still beats the alternatives available publicly. Reviews-based models rest on an assumed booking-per-review rate; the diff at least observes something that actually changed between two dates.

The free sample CSV carries the full 12-column schema if you want to prototype the diff logic on real rows before pulling larger files.

Get the snapshot data

90,169 rows across 6 city files, one snapshot date each, plus cities-index.csv, a data dictionary, and source checksums. Data from Inside Airbnb, CC BY 4.0.

More from the catalog

• Airbnb occupancy data: what a listings snapshot can and cannot tell you about occupancy, and the proxies that work
• Airbnb data by city: rows, snapshot dates, and room mix for all six markets
• Inside Airbnb alternative: what the 6-city pack adds over the raw per-city files
• Airbnb data download guide: the 12 columns explained, with MCP query examples
• For agents: endpoint docs and worked examples

FAQ

How does Inside Airbnb collect its data?

Inside Airbnb runs periodic scrapes of Airbnb's public listing pages, one run per city per collection cycle. Each run captures one row per visible listing at that moment, cleans the fields, and publishes the result as per-city files under CC BY 4.0. A snapshot is one run's output: the market as seen on the scrape date, not a continuous feed.

What does availability_365 record in a snapshot?

The number of nights the listing shows as bookable in the 365 days after the snapshot date. In the 20-row Austin sample from the 2026-06-22 snapshot, values run from 10 to 365 with a median of 285, and half the listings show 300 or more open nights. It is one counter per listing: no per-night detail and no label for why a night is closed.

How do you estimate bookings from two snapshots?

Scrape the same city twice, d days apart, and diff availability_365 per listing ID. Booked nights in that window are roughly (availability at the first snapshot minus availability at the second) plus d, clamped to between 0 and d. It is a proxy with real error bars: host blocks, cancellations, and nights pulled from the far end of the calendar all shift the diff, so treat results as ranges.