Hotel Points vs Cash Prices: Collecting Comparable Rate Data

Introduction

Most points-versus-cash comparisons are invalid, and the reason is procedural rather than analytical. The two sides were collected under different conditions.

The cash rate came from a non-refundable advance-purchase plan. The award rate came from a standard flexible booking. The cash rate excluded a resort fee that the award path charges anyway. The two observations were taken six hours apart, during which the cash rate moved.

Divide one by the other and you get a cents-per-point figure that looks authoritative and means nothing.

This post is about the collection discipline that makes the comparison hold: what has to be identical on both sides, how to pin a rate plan, how to handle fees, and what cadence reveals rate movement before a stay date.

The comparability problem

For a points-versus-cash observation to be valid, seven things must match across both sides:

The last row is the one most often ignored. A cash rate is a live quote. Collecting the award side in the morning and the cash side in the evening introduces a gap larger than many of the differences being studied.

Practical rule: collect both sides inside the same request window, and store a shared observation_group_id so the pair is provable, not assumed.

Rate-plan proliferation and how to pin one

A single property on a single date routinely exposes many rate plans:

• Standard flexible rate
• Member or loyalty-program rate
• Advance purchase, non-refundable
• Breakfast-included package
• Longer-stay or multi-night discounted rate
• Corporate or negotiated rate, where publicly quotable
• Promotional rate tied to a campaign window

These are not variations of one price. They are different products. A series that takes "the cheapest available rate" each day will jump whenever the plan mix changes, and the jump will be read as a rate movement.

The fix is to pin a plan definition and hold it for the life of the series. A workable default:

Baseline plan: lowest publicly available rate that is fully refundable, room-only, standard base room category, double occupancy, no loyalty membership required.

Then run a second series for the member rate if that comparison matters. Two clean series beat one contaminated one.

Record the plan you actually captured in rate_plan_label and rate_plan_normalised, along with the attributes that define it. When a property stops offering the pinned plan on a date, record a null with a reason code rather than substituting a different plan.

Taxes, resort fees and the paths that differ

This is where the comparison most often quietly breaks.

On the cash path, the quoted nightly rate frequently excludes taxes and a mandatory property fee, both added later in the flow. On the award path, the points cover the room but the mandatory fee may still be payable in cash, and taxes may be handled differently.

So the correct comparison is not points versus nightly rate. It is:

Points required plus cash payable on the award path, against total cash payable on the cash path.

That means capturing, on both sides:

• Nightly rate or points, per night
• Taxes, itemised where the source itemises them
• Mandatory property or resort fee, and whether it is per night or per stay
• Any other non-optional charge
• A derived total for the full stay

If a source does not expose the fee at the quote stage, record fee_disclosed_at_quote = false and mark the total as incomplete. An incomplete total labelled as incomplete is useful. An incomplete total labelled as a total is a defect.

Award availability as a separate signal

Award price and award availability are two different things, and conflating them produces bad conclusions.

A property may show no award nights on a date because the award bucket is closed, while cash rooms remain plentiful. That is an availability event, not a pricing event. A property may also show award nights at a high points level, which is a pricing event.

Store them separately:

• award_available — boolean
• award_points_per_night — integer, null when unavailable
• award_unavailable_reason — enum where the source gives one

Availability alone answers a useful question about the share of sampled property-nights with award availability, by market and booking window. That figure is often more actionable than any cents-per-point number, because it tells a traveller whether the redemption is even possible.

The field schema

Deriving cents per point, and its caveats

The derivation is simple:

value_per_point = (total_cash_for_stay_cash_path − award_cash_component) / total_points_required

The caveats are not simple, and any published figure should carry them:

• It is a single-observation figure, valid for one property, one date, one plan, one occupancy. It does not generalise to a program.
• It is sensitive to the cash plan pinned. A refundable baseline yields a higher figure than a non-refundable one. Say which you used.
• It ignores earning forgone. An award stay usually earns no points and may not count toward status. That is a real cost the ratio omits.
• It is undefined when award availability is closed. Excluding unavailable nights biases the distribution upward, because the nights that disappear are often the high-demand ones.
• Report a distribution, not a mean. The useful output is percentiles across sampled property-nights, not a single headline number.

Point five is the one that changes decisions. A mean hides the cases where redemption is clearly worthwhile.

Collection cadence

Rate movement before a stay date is the phenomenon most people actually want to see, and it requires cadence rather than coverage.

A defensible pattern for each property-date cell:

Hold the weekday constant on the sparse tiers. Weekday and weekend rates differ enough that a shifting weekday will generate a fake trend.

What the cadence actually reveals

Cadence is not just refresh hygiene. Each tier answers a different question, and knowing which one you are answering prevents overclaiming.

The daily near-term tier shows closeout behaviour. As a stay date approaches, a property either drops its rate to fill remaining rooms or holds firm and lets them go empty. That decision is visible only if you are sampling every day in the final week, and it is the single most commercially interesting pattern in hotel rate data.

The two-day tier over the 8-to-30-day window shows the main repricing zone. Most revenue-management adjustments land here, and this is where a points-versus-cash gap typically widens or closes.

The weekly and monthly tiers are anchors, not trend data. Their job is to establish where a property started, so that near-term movement can be measured against something. Do not attempt to read week-to-week volatility from a monthly series.

One more reason cadence matters: award availability is not static either. A property with award nights open at 90 days out can have them closed at 10 days out, or the reverse. Without a cadence that spans booking windows, you cannot tell whether a closed award night was always closed or closed recently — and those are very different findings for anyone deciding when to book.

Finally, keep the collection time of day consistent within each tier. Rates move intraday, and a series that drifts from morning collection to evening collection over several weeks will show a trend that is an artefact of your own scheduler.

Sampling design across properties and markets

You cannot cover every property. Choose a panel and keep it stable.

• Stratify by market, with a fixed property count per market so no market dominates.
• Stratify by tier within market: upper-upscale, upscale, midscale, as the program defines them.
• Include control properties in low-demand markets, where a rate change is more likely programmatic than demand-driven.
• Hold the panel fixed across periods. Adding properties mid-series changes the composition and breaks period comparisons.
• Track panel attrition. Properties leave programs and change brands; record the exit rather than silently dropping the row.

Common failure modes: substituting a different room category when the base room sells out; letting a promotional plan enter the pinned series; collecting the two paths hours apart; and reporting a mean cents-per-point across a panel with heavy availability gaps.

Actowiz Solutions builds paired award-and-cash hotel rate collection with rate-plan pinning, shared observation grouping across both paths, fee and tax capture, and availability recorded as a distinct field. Feeds are delivered on a defined cadence per booking-window tier, through scheduled delivery or API.

We collect public-facing published rates and record the conditions of each observation, so the comparison you publish is one you can defend.

Frequently Asked Questions

Why do points and cash rates have to be collected at the same moment?

Because cash rates are live quotes that move intraday. If the award side is captured hours after the cash side, part of the measured gap is elapsed time rather than a real difference. Pairing both observations under a shared identifier makes the comparison provable.

What is rate-plan pinning and why does it matter?

Pinning means fixing one plan definition, such as the lowest publicly available refundable room-only rate at double occupancy, and holding it across the whole series. Without it, the plan mix changes between collections and the resulting jumps are misread as genuine rate movement.

Why report a distribution of cents-per-point rather than an average?

Because the figure varies widely by property, date and booking window, and nights with closed award availability drop out of the calculation entirely. An average hides both the variance and the selection effect, while percentiles across sampled property-nights show where redemption actually pays off.

You can also reach us for all your mobile app scraping, data collection, web scraping, and instant data scraper service requirements!