Measure from the day you changed the price, not from the first of the month

Two correct numbers, opposite decisions

This morning, 12 September, our own outreach system reported its hard-bounce rate twice, minutes apart. The first read: 8 hard bounces across 160 emails ever sent, 5.0%, flagged critical against a 5% ceiling. The second: 1 hard bounce across the 60 emails sent since a configuration change stamped 10 September at 14:22 UTC, 1.67%, comfortably clear. Seven of those eight bounces predate the change. Both numbers are arithmetically correct. One says shut the channel down, the other says carry on. Nothing separates them except the window they were measured on.

That is our email plumbing, not your front desk, and I am not asking you to care about it. I am asking you to notice the shape of the mistake, because it is the same shape as the one that has you dropping a dorm rate that did not need dropping.

The version of this that costs you beds

Same problem, now on the pricing engine that runs my own property, Maka Hostel in Oaxaca. Every morning it rewrites five lead-time rate bands and learns how deep the near-term discount should go, in three-point steps. That learning produced a number that looks like a finding and is not one.

The engine's own elasticity read, from the 5 September run: at a -8% offset on the same-day and 1-3 day bands, average tonight-occupancy was 33.7% across 23 days. At a 0% offset, 42.0% across 5 days. Delta: -8.3 percentage points, in the direction that says the discount lost us occupancy.

Read it straight and you raise prices tomorrow. Read it honestly and it says almost nothing. Twenty-three days against five is not a comparison; five days can be a long weekend, or a week a festival moved. There is no day-of-week control and no seasonal control. All of those days sit in low season, where the engine's target is 75% and actual tonight-occupancy ranged from 11% to 47%. The code's own comment on the calculation says it is not a real regression, just enough to flag a direction.

What matters is what the engine did with it. That read exists for exactly one decision: whether to let the learned discount cap expand past 8 percentage points, toward a ceiling of 25. The evidence did not justify going deeper, so it held at 8 and stopped digging. It did not conclude that raising price fills beds. A weak number answered the one narrow question it could answer, and nothing else.

Why 32 runs is really 22 days

Between 14 August and 5 September that engine logged 32 runs. Those 32 runs cover 22 calendar dates. Four dates - 14, 15, 20 and 22 August - were run between two and six times each, because I was editing the formula between runs. The move tally across the log is 19 deepen, 13 hold, 0 lift, and that is a tally of runs, not of days.

So any rate computed with 32 in the denominator carries the same Tuesday four times. Not a rounding problem, a wrong question. Your PMS does this to you in less obvious ways: a month holding three days of a double-counted group booking, a week the building was half closed for plumbing, a channel that reposted a reservation. An average over the period includes all of it, quietly.

Three windows, and what each one is for

Since the change

The only window that can tell you whether a price move worked, and it starts at the timestamp of the move. Our send gate does this by construction: it carries the exact moment its window opens and computes only on what came after. Do it by hand. Write down the date and hour you changed a band, and refuse to read those dates from any earlier point.

Like-for-like

Same weekday, same lead time, same season. A 1-3 day band on a Saturday and the same band on a Wednesday are two different products. If you only have a few weeks of data you have very few valid pairs, and admitting that is cheaper than acting on a fake comparison.

Lifetime

Useful as a baseline, useless as a decision. Monthly revenue at my property went from about USD 3,100 in August 2025 to about USD 12,800 in August 2026, running on this system. Real figure; it tells you nothing about which of the fifty changes that year did the work - pricing, the bar, the listings, the photos, the season. A lifetime number sets context. It never settles an argument about last Tuesday's rate.

The rolling average that refuses to answer too early

The same engine tracks ancillary margin per occupied bed: margin-weighted bar and activities income divided by beds actually filled. Over the last eight logged days that rolling average moved from 34 to 27 MXN per bed, against a 32 MXN baseline taken from the 2025 P&L. Worth watching. Not yet a conclusion.

The reason is the spread underneath: the daily figure ranged from 3 to 123 MXN per bed across the log. On that spread, one day tells you which day it was and nothing else. The code reports no rolling average until it has three days or more, and eight days of drift is something to watch, not a new baseline. If a number swings 40-fold day to day, decide its minimum sample before you look at it.

Do not blend two kinds of bad

Our send gate evaluates 1.67% hard bounces against a 5% ceiling, and separately 8.33% hard-and-soft combined against a 20% ceiling. Two rates, two thresholds, because a dead address and a full mailbox call for different actions.

We blend constantly. One cancellation rate mixing non-refundable OTA cancellations with free-cancellation holds. One occupancy figure covering dorms and privates when only the dorms are soft. One market price when the competitors you track sit in a range - mine reads a floor between 168 and 206 MXN across three named Hostelworld properties, probed three days out, one guest, one night. If two things need different responses, they need different numbers.

What to write down before your next price change

• The date and hour the change goes live, and which lead-time bands and which dates it affects.
• The minimum sample you will wait for before reading the result, chosen in advance.
• The like-for-like comparison you intend to make: which weekdays against which.
• The number that would make you revert, written as a number and not as a feeling.
• Anything that makes those dates abnormal: a festival, a closure, a group, a re-run.

None of this requires software. It requires that "occupancy is up since we changed the price" carry a start date. Every measurement above comes from one owner-operated property in Oaxaca and our own outreach logs - one property proving a mechanism, in low season, not a validated result across many. Nightfill is independently operated, and what any of this does at your property depends on your market, your season and your channel mix.

If this sounds like your property, see the three Nightfill tiers and start a free 14-day pilot on your own data: view pricing.