ADR & Market Intelligence

What you asked for

Competitor and market data for comparable Airbnb properties, combined with your own occupancy, booking pace, seasonality and days-until-check-in, producing a simple output:

Current ADR:        ¥25,000
Comparable Market:  ¥28,000
Recommended ADR:    ¥27,000

And — the important part — the competitor data behind the recommendation must be visible. Not a black box that emits a number. Later, moving to Booking.com / Trip.com / Agoda data as the portfolio shifts toward hotels and resorts.

You are right that this is the easiest place to start. It is read-only, it touches nothing operational, and it can be proven or disproven with a few months of history. Build it first.

What is actually possible

The uncomfortable fact underneath this whole chapter: Airbnb does not sell you competitor data, and it does not let you read it through an API. Every product in this space is either aggregating licensed/scraped data or is a pricing tool that scrapes for its own engine. So the real question is not "can I get comp data" but "from whom, at what granularity, and can I see the individual listings."

That last distinction sorts the market cleanly:

Two things follow from this table.

First: you do not need to scrape to get what you asked for. PriceLabs, Beyond and Wheelhouse all expose an inspectable comp set through a documented API. That is precisely the anti-black-box property you want, and it comes with the vendor having done the ToS diligence. Start there.

Second: use the pricing vendors as a data layer, not as an autopilot. All three can push prices, and all three will happily run your rates automatically. Don't let them, initially. The architecture is: pull the comp set and the vendor's suggested price via API → run your own explainable scoring on top → present current / market / recommended with the evidence → a human approves → push the approved rate back through the same API. You keep the vendor's data collection and the certified price-push plumbing, and you keep the judgement.

On scraping, honestly

You will be tempted, because raw scraping is cheap and unlimited. A calibrated view:

• Criminal exposure is essentially off the table for public data in the US. hiQ Labs v. LinkedIn (9th Cir. 2022, after Van Buren) held that scraping publicly accessible data with no login wall does not violate the CFAA, even after a cease-and-desist, because the statute concerns unauthorised access, not unauthorised use.
• Contract exposure is real but civil. Airbnb's and Booking.com's terms prohibit automated scraping. Breaching them gets accounts and IPs banned, occasionally a cease-and-desist, and very rarely a contract suit — and those suits target large commercial resellers of scraped data, not an operator building an internal comp tool.
• Europe is stricter on two independent grounds: the sui generis database right can protect a platform's database even where an individual nightly price isn't copyrightable, and GDPR bites the moment host names, photos or named reviews enter your store.
• Japan has no single scraping statute; exposure comes from the Copyright Act (database provisions), the Unfair Competition Prevention Act, ordinary Civil Code contract/tort, and APPI if personal data is captured. Price and availability facts are the low-risk end. Aggressive crawling invites a server-obstruction theory.
• Indonesia: less litigated, general contract law plus UU PDP for any personal data.

Practical posture. Licensed API data for anything commercial, investor-facing, or that the company's 1,000-unit portfolio depends on. If you scrape at all, scrape only public non-personal fields (price, availability, capacity, amenities), respect robots.txt and rate limits, never touch login-walled pages, never republish or resell, and de-identify on ingest. Get written indemnification from any scraping vendor — and understand that the platform's claim runs against you as the data user, not only against Apify. Be pragmatic, not paranoid; but do not build a paid product on unlicensed Airbnb data without a lawyer looking at it.

How the recommendation should be built

The output you sketched is three numbers. The system behind it is five layers, and the whole design goal is that each layer is separately visible and separately overridable.

Layer 1 — Comp-set selection

Start from a radius (1–3 km in urban Tokyo/Osaka/Kyoto; much wider for Bali villas), then filter and weight by:

• Distance, decayed — inverse-distance or a Gaussian kernel, not a hard cut-off.
• Capacity match — ±1 bedroom / guest count. ADR scales non-linearly with capacity, so mismatched comps poison the median.
• Property type — entire home vs private room; villa vs apartment vs machiya vs ryokan-style.
• Rating and review count — a minimum review threshold to exclude unproven listings, and a rating band of roughly ±0.2–0.3 stars.
• Amenity and quality signals — pool, onsen, view, parking, AC. Decisive in Bali, increasingly decisive for premium Japan stock.

Target 8–20 comps. Below about six the index is noise; above about 25 you have diluted your true competitors into the neighbourhood average. Where a thin market (rural Bali, a small Japanese town) cannot produce six, fall back explicitly to a city-level index and say so on the screen rather than silently returning a bad number.

Layer 2 — Quality adjustment

Do not compare your rate to a raw comp average. Fit a simple hedonic model — comp ADR regressed on bedrooms, capacity, rating, amenity count, distance to station or beach — to produce a quality-adjusted market ADR. This is what lets the system say something defensible: "you should sit 12% above the comp median because you have a private pool and a 4.9 rating against a comp mean of 4.6."

Layer 3 — Booking pace and pickup

Snapshot bookings-on-books at fixed days-to-arrival (90 / 60 / 30 / 14 / 7 / 1) and compare against (a) that unit's own historical pickup curve and (b) the comp set's typical pace, inferred from repeated calendar-availability snapshots. Ahead of curve → raise. Behind curve → discount, with the discount growing as arrival approaches.

This requires point-in-time storage from day one. You cannot reconstruct pace retroactively; today's comp calendars tell you nothing about what was available 60 days ago. The single most valuable thing you can do in the first month of this project is start snapshotting comp availability and your own on-books nightly, even before any recommender exists.

Layer 4 — Seasonality and event calendars

A per-micro-market seasonality index, applied multiplicatively, refreshed annually because the lunar and forecast-driven dates move:

• Japan — Golden Week (late Apr–early May), Obon (mid-Aug), New Year (roughly Dec 29–Jan 3), Silver Week, cherry blossom (regional, tracks the JMA forecast, late Mar–mid Apr), plus local events: sumo tournaments, matsuri, conventions. Overlay inbound-demand drivers: flight capacity and the yen.
• Bali — Australian and European school holidays, dry-season peak (Jun–Sep) against wet-season discounting, Galungan/Kuningan, Ramadan/Eid effects on regional travel, and Nyepi, which is not a pricing event at all but a mandatory-closure zero-demand day. The system must model it as unavailable inventory, not as a cheap night.

Layer 5 — Constraints and gap handling

Detect orphan nights — unsellable one- or two-night gaps between bookings — and either relax minimum stay for that gap only or apply a labelled gap-filling discount. Never let gap logic silently move the base rate. The label matters: "orphan-night discount −12% to fill an otherwise unsellable single night" is a decision an approver can evaluate in two seconds.

The screen

Your three-line summary is the headline. Underneath it, per date:

2026-04-04 (Sat)   Kyoto · Machiya 2BR

  Current listed                      ¥25,000
  Comp median (11 comps)              ¥28,000   IQR ¥24,600–¥31,200
  Quality adjustment    +6%           ¥29,680   rating 4.9 vs 4.6, private garden
  Pace adjustment       −4%           ¥28,490   62% on books vs 71% typical at 30d
  Seasonality (sakura)  ×1.00         ¥28,490   already in comp set
  Floor / ceiling                     ¥19,000 / ¥45,000
  ──────────────────────────────────────────────
  RECOMMENDED                         ¥27,500   [Approve] [Edit] [Skip]

  Evidence — 11 comps used                      [view all]
   ¥31,200  2BR machiya, 400m, 4.8★ (214)   82% booked next 30d
   ¥29,500  2BR apt, 650m, 4.9★ (96)        74%
   ¥27,800  2BR machiya, 300m, 4.7★ (338)   91%
   ...

Every line overridable independently — an approver should be able to reject the sakura multiplier without touching comp-set logic. Every recommendation, its inputs, and the human's decision written to an immutable log, because that log is what later proves whether autonomy is warranted.

The hotel and resort phase

When the portfolio moves into hotels and resorts, three things change and it is worth designing with them in mind rather than rebuilding:

1. The data source changes from Airbnb-comp scrapers to OTA rate-shopping (Lighthouse) and STR/CoStar STAR reports. Your comp-set abstraction should not assume Airbnb.
2. The unit changes from a listing to a room type, with rate plans, restrictions and length-of-stay controls. Model "rate plan" as a first-class object early even if every STR unit has exactly one.
3. The methodology becomes indexed. STAR reports express performance as your RevPAR divided by comp-set RevPAR × 100. Adopt that index framing now, for STR, because it is the only way to distinguish your pricing skill from market movement.

Proving it works

This is where most pricing projects quietly fail: they show ADR went up in a rising market and call it a win.

• Track index, not level. Your RevPAR ÷ comp-set RevPAR × 100, monthly. Yen weakness and new local supply will otherwise mask or fake your result.
• Run a holdout. Randomly assign matched properties (same market, size, history) to recommender-driven versus legacy manual pricing. Compare index delta over a full seasonal cycle — 12 months minimum in Japan, to see Golden Week, Obon, New Year and sakura once each.
• Backtest carefully, or not at all. The traps: look-ahead bias (using occupancy or ratings the decision-maker could not have known); survivorship bias in comp sets, since listings delist and relist — which is why point-in-time snapshots are non-negotiable; demand endogeneity, if you are a large share of local supply your own prices move the "market" baseline; small-N noise in thin markets; and currency drift, so normalise IDR and JPY comps for FX before any year-on-year claim.
• Report net of market. Your growth minus comp-set growth, with a confidence interval. A single point estimate presented as certainty is how a pricing tool loses credibility permanently.

Effort and risk

Effort: low to moderate, and by far the best effort-to-insight ratio in this handbook. A read-only recommender over a licensed comp API, with nightly snapshots and an approval screen, is the smallest useful thing you can ship — and it delivers a visible number to management in weeks.

Risk: low. Nothing is pushed without approval; the worst outcome of a bad recommendation is that someone declines it. The only real risks are choosing a data vendor with poor Japan/Bali coverage (verify with a trial on your own units before signing) and failing to start snapshotting early enough.

Decisions for you

1. Which comp-data source? Recommendation: trial PriceLabs first — it has the most inspectable comp data, documented APIs and good Asia coverage — with AirDNA as a market-level sanity check. Validate coverage on three real units in Japan and three in Bali before committing.
2. Do you want the vendor's suggested price shown alongside your own? Recommended: yes. Two independent numbers on one screen build approver confidence far faster than one.
3. Floors and ceilings per unit — who sets them, and how often are they reviewed? The recommender needs hard bounds on day one.
4. Scraping: in or out? Recommendation: out for now. Revisit only if a licensed source proves inadequate for a specific market, and with legal review.
5. Start snapshotting this month, regardless of which vendor wins. The pace data is worthless if it starts late.