Our methodology.

Basket spec: the standardized hotel night.

The Rewardopedia Cost Index is one number per destination per month: the Nth percentile of hotels-only inventory inside the city's central-area polygon. The target cadence is once per calendar month (ideally the 1st); today the refresh is still a manual command and the first public index run is pending during calibration.

The construct: the typical published room rate for hotels in the central area. We compute the Nth percentile of the basket samples in USD, with FX snapped on the first of the month. A mid-tier / mid-market filter is planned as post-launch calibration; today the pipeline uses all hotel-typed properties in the polygon.

Currently N is a placeholder (57.5) and is being calibrated against the first 2–3 months of live pipeline data. While N is provisional, figures that meet the sample-size floor ship with the Calibrating confidence label; under-floor samples still ship as Low-sample.

What's fixed (not calibrated): length of stay = 2 nights; refundable rate; taxes included; USD denomination; first-of-month FX snapshot; hotels-only filter applied to SerpApi google_hotels results after the response (property type == hotel), not as a request parameter.

What's calibrated post-launch: the percentile slice value, the minimum sample size for Sampled confidence, the number of sample dates, the lead time, and the midweek/weekend mix.

Polygon protocol: inventory-density model.

Each destination has a single fixed central-area polygon. We do not redraw it every month, only when underlying hotel inventory composition shifts materially.

Construction: an unconstrained Google Hotels pull yields a lat/lng cloud. We fit a convex hull around the densest 70% of those points, then subtract a 5 km exclusion zone around any major airport in the destination.

Floor: a polygon must contain ≥ 30 unique hotels after airport exclusion. Destinations that cannot clear that floor are not bootstrapped into the public registry today. A default centroid-plus-1.5km fallback polygon is planned but not yet generated by the pipeline.

Validation: each polygon file is schema-validated before use, so its geometry, slug, source, and fit metadata all have to check out. An automated cross-family LLM rubric check and a random spot-audit of approved polygons are planned but not yet in place.

Polygons live as GeoJSON in apps/api/polygon_registry/<slug>.geojson in the repo. Every change goes through PR review. Most polygons are inventory-density fits; a polygon may also be committed as an editorial_override under the same review path when a fit is not yet available. Published basket values are computed by the pipeline from the sampled rates, not hand-edited.

Sample design: when and what we sample.

Cadence: designed to run once per calendar month. Today the refresh is a manual command, not yet wired to an automated schedule, and the first public index run is still pending during the calibration period.

Per destination: a SerpApi google_hotels query for the city returns mixed property types; we keep hotel-typed results and filter them to points inside the polygon. We compute the Nth percentile of rate_per_night across that basket.

Lead time, length of stay, occupancy: all fixed across destinations to keep the basket comparable. Length of stay is currently 2 nights, refundable rate, taxes included.

Cross-source telemetry was originally planned via Amadeus but dropped at launch. Amadeus's chain-bias makes naive averaging wrong, and the methodological discipline is stronger than the math gain. Instead we intend to manually cross-check a handful of random cities each quarter once the index is live.

Confidence labels: a 5-state ladder.

Every published Cost Index figure includes a confidence chip (value, label, and as-of date). Destinations with no published figure show a disclosure instead of a chip. The five states, in increasing strength, are:

• ~Low-sample· May 22, 2026Sample below N_min OR polygon below 30-hotel floor OR last sample older than current month.
• ⏱Calibrating· May 22, 2026Methodology v1.0 placeholder period. Backfills to `Sampled` on parameter freeze.
• ⛓Composite· May 22, 2026Derived from multiple inputs of different epistemic states (e.g., trip-cost calculator: measured hotel basket + user daily-spend).
• ✎Editorial· May 22, 2026Judgment calls, not measurements (best card to bring, why this destination is undervalued).
• ✓Sampled· May 22, 2026Current monthly window, sample size ≥ N_min, polygon meets ≥30-hotel floor. The strongest label.

Change log.

Every material methodology change is versioned and documented here. We log the date, what changed, and why, so anyone citing the index knows exactly which methodology produced a given figure.

v1.0.2 · 2026-07-19

Documentation honesty pass: demoted unimplemented mechanisms (LLM polygon judge, Temporal-scheduled refresh, quarterly screenshot audits, centroid fallback) to planned/intent language; clarified manual refresh cadence, hotels-only post-filter,editorial_override polygons, and the Low-sample vs Calibrating precedence. Documentation-only; published methodology_version remains v1.0.

v1.0.1 · 2026-07-18

Corrected the documented minimum sample size from N_min=15 to N_min=12 to match the threshold the index pipeline has used in implementation. Documentation-only correction; published methodology_version remains v1.0. Source of truth: the methodology payload field basket_spec.n_min (N_MIN_PLACEHOLDER).

v1.0 · 2026-05-22

Initial methodology published. Placeholder N=57.5 percentile, N_min=12 sample size, 2-night refundable LOS, USD with FOM FX snap, inventory-density polygons with ≥30-hotel floor and 5km airport exclusion. The first public index run remains pending during the calibration period. Figures that meet N_min ship as Calibrating while methodology is unfrozen; under-floor samples ship as Low-sample.

Why you can trust this index.

Anyone can post a price. We publish a standardized, sourced, dated one. Affiliate commissions never change our editorial inclusion, rankings, or verdicts.