Booking Reviews Scraper By Traveller Type & Stay Season

Booking Reviews Scraper By Traveller Type & Stay Season

Scrapes Booking.com hotel guest reviews, exactly like the base Booking Reviews Scraper, and adds two server-side filters: which kind of guest wrote the review (business travellers, families, couples, solo travellers, groups of friends) and which part of the year the stay falls in (Booking's own Mar–May / Jun–Aug / Sep–Nov / Dec–Feb windows).

Why this exists

Booking's own review data separates why someone travelled (business vs. leisure) from who they travelled with (alone / as a couple / with family) — and only the second is printed on the review itself. A hotel's commercial manager wants the first one: the reviews written by business travellers, a segment the base actor cannot isolate at any maxItems setting. This variant asks Booking's own GraphQL server for that segment directly, server-side, at no extra request cost.

New inputs

Field	Type	Default	What it does
🧳 travellerTypes	array (select)	["Business travellers"]	Keep only reviews from the chosen guest type(s). Values: Business travellers, Families, Couples, Solo travellers, Groups of friends. Empty = every guest type (base behaviour).
📅 staySeasons	array (select)	[]	Keep only reviews inside Booking's own season window(s): Mar–May, Jun–Aug, Sep–Nov, Dec–Feb. Empty = whole year (base behaviour).

Both map to variables.input.filters.customerTypes / filters.timesOfYear on Booking's existing ReviewList GraphQL query — no new endpoint, no extra request. Unrecognised values are silently dropped, never sent to Booking.

New outputs (appended after startUrl, base's 25 fields unchanged)

Field	Meaning
travellerTypeFilter	The travellerTypes selection this request used (request provenance, not a per-row confirmation). "" when unfiltered.
travellerTypeCode	bookingDetails.customerType off the wire — party composition only (e.g. SOLO_TRAVELLERS), never the trip-purpose you filtered on. Booking records purpose and party composition separately; this field is the latter.
staySeasonFilter	The staySeasons selection this request used. "" when unfiltered.
matchingReviewsCount	Booking's own reviewsCount on the filtered call — the only number that reflects your filter set.
travellerTypeCounts	Booking's own customerTypeFilter[] facet, verbatim (ALL row dropped). This is the property's whole-corpus breakdown and does NOT narrow with your filters — it is identical regardless of what you selected.

Honest limits

• travellerTypeCode is not proof your filter worked. On a business-traveller run, most/all rows will still read SOLO_TRAVELLERS, COUPLES, FAMILIES or GROUP_OF_FRIENDS in this field — that is expected. Booking's party-composition field and its trip-purpose filter are two separate things; only travellerTypeFilter (and the fact that the row came back at all) proves the filter matched.
• travellerTypeCounts never changes with your filters. It is the property's total segment breakdown, read once per hotel, always the same regardless of travellerTypes/staySeasons.
• staySeasonFilter describes Booking's own window, not a guaranteed check-in month. Evidence points to Booking keying the season off the review-posted date, not check-in — do not promise "stays in month X."
• Selecting more than one value in an axis returns Booking's union of that axis, not a per-row attribution — travellerTypeFilter/staySeasonFilter record the filter set used, joined with , , not which member of that set produced any individual row.
• Every base defect is preserved unchanged and not silently fixed here: the mislabelled-timezone reviewDate, the 16-char-hash id, the "xu"/"xb" placeholder reviewLanguage on ~72% of rows, the declared-but-inert reviewScores filter and its reviewsScoreFilter output echo, and the four hard-coded request-fingerprint constants (ufi, hotelCountryCode, hotelScore, searchFeatures). These are the base actor's own long-standing behaviour, not introduced by this variant.

What did not change

Same Playwright + NONE → DATACENTER → RESIDENTIAL proxy ladder, same GraphQL endpoint and query, same one-flat-row-per-review dataset shape, same output.json key-value-store write. REVIEWS_PER_PAGE was raised from 10 to 25 (Booking silently clamps limit to 25 anyway) purely as an internal efficiency fix — it is not a feature and is not user-configurable.