What Airbnb data really contains once you scrape it — prose prices, fused city fields, compressed ratings — and how to clean it. Explore 465K+ listings live.
Most people who go looking for Airbnb data expect a clean table: a price column, a bedroom count, a city, a rating. What a scrape actually returns is closer to a page of marketing copy that happens to be comma-separated. The price is a sentence. The capacity is prose. The city is glued to the stay type inside a single field. None of that makes the data less useful — but it does mean the first hour with any Airbnb dataset is spent parsing, not analysing.
This is a walkthrough of what one snapshot really holds, which fields lie about their type, and what the data simply cannot tell you. You can follow along against the live Airbnb data dashboard, which runs the same 190K+ listings described here.
Here's a single listing from a real crawl, field by field:
Field | Value |
|---|---|
| 782102547563500637 |
| The Explorer House *Dogs Welcome* |
| Home in Alabaster |
| 4.9 |
| 83 |
| $1,058 for 5 nights, originally $1,149 |
| 211.60 |
| 3 bedrooms / 5 beds / 2 baths |
| 33.24894 / -86.80906 |
| Guest favorite |
| 2026-08-26 01:49:49+00 |
Nothing here is wrong. But only three of those fields — the ID, the coordinates and the timestamp — arrive as the type they represent.
price_display reads "$1,058 for 5 nights, originally $1,149". Two numbers and a stay length live in one string, and the stay length isn't constant across rows. Divide the wrong figure and your nightly rate is off by a factor of five. Worse, the visible total is the discounted one — the originally figure is the anchor. Any Airbnb data analysis that ignores this reports a market as cheaper than it is and loses the discount signal entirely, which is one of the more interesting variables in the set. The pricing view treats discount depth as a first-class dimension for exactly that reason.
property_type is "Home in Alabaster" — stay type and city fused. There is no state column, no clean city column. Splitting on " in " gets you most of the way there and then breaks on names that contain the word. The reliable geography in Airbnb data is the coordinate pair, which is why the map view derives location from latitude and longitude rather than from text.
3 bedrooms, 5 beds, 2.5 baths. Strip the noun, keep the decimal, and remember that studios say something other than a number. Beds and bedrooms diverge often enough that per-bed pricing is a genuinely different metric from per-bedroom pricing — and per-bed is usually the more honest comparison across a mixed supply.
The sample above shows 4.9, 5.0, 5.0, 4.9, 4.9. That's not a lucky draw; it's the whole distribution. Airbnb ratings compress into the top tenth of the scale, so avg_rating on its own separates almost nothing. Review count does the work instead — it proxies tenure and booking volume, and it's the variable worth weighting by. The trust view pairs the two rather than ranking on stars alone.
Guest favorite and Superhost are real signals, but their fill rate shifts between crawls. Compare two snapshots naively and you'll conclude that half the market lost a badge overnight. It didn't. Badge deltas are the single easiest way to generate a confident, wrong finding from Airbnb data.
One scrape is a still photograph. It answers structural questions well:
What does supply look like here — whole homes or rooms inside someone's house?
What's the median nightly rate, and per bed?
How deep are the discounts, and who is discounting?
How concentrated is the review volume? The stay-type and room-share splits on the demand view are built on precisely these questions, and they're answerable from a single file.
What one snapshot cannot answer is anything with a direction: is this market getting more expensive, is inventory growing, did that host cut their rate. For that you need two crawls and an ID match — which is what the movers view and its comparison export exist for. That matched file is worth calling out: rebuilding it from two separate downloads means redoing the join and re-deriving every delta yourself, including the clamps for review counts that occasionally tick downward.
Scraped listing data is supply-side only. It does not include:
Occupancy or bookings. Calendar availability isn't in a search result, and inferring occupancy from blocked dates is an estimate, not an observation.
Revenue. Rate multiplied by an assumed occupancy is a model, and it should be labelled as one.
Host identity. A badge is not a portfolio, and there's no operator key to group listings by.
Stay dates. In this dataset checkin and checkout are empty on every row, so the dates behind a quoted rate are unknown. They're excluded from the export rather than shipped empty, because a present-but-blank column implies it carries something. Being clear about these gaps is more useful than papering over them. A dataset that quietly imputes occupancy is harder to trust than one that says it doesn't have it.
The practical shape of a clean Airbnb data pipeline is short:
Parse price_display into total, original total, nights and a true nightly rate.
Split property_type into stay type and city — then verify the city against coordinates.
Cast capacity strings to numbers, keeping half-baths.
Derive per-bed rate and discount percentage.
Weight ratings by review count before comparing anything.
Key on listing_id and scraped_at so snapshots can be joined later. Every one of those steps is already computed in the Airbnb Data — 465K+ Scraped Listings with Nightly Rates, Ratings, Badges & Coordinates
If you'd rather see the shape of it before downloading anything, start with the Airbnb data dashboard and filter your way to the slice you care about.
What is Airbnb data? In this context, structured records of live Airbnb listings — nightly rate, original rate, rating, review count, stay type, capacity, badge and coordinates — captured at a specific timestamp from public search results.
Is scraped Airbnb data accurate? It's accurate to the moment of capture, which is why every row carries scraped_at. Rates shift with dates, demand and discounts, so a snapshot should be read as an observation, not a permanent price.
What format does the Airbnb dataset come in? CSV, JSON or NDJSON, up to 25,000 rows per download, with a column picker and a separate cross-snapshot comparison export.
Can I get occupancy or revenue figures? Not from listing-side data. Those require booking-side signals or modelling, and anything presented as occupancy in a scraped Airbnb dataset is an estimate.