Do Early Bookings Cancel More? A 342,079-Reservation STR Study

Direct answer from the published matrix

Short answer: early bookings do not consistently cancel more often in this IntelliHost cancellation study. Some stay length groups rise as bookings are made earlier. Some flatten. One long stay group spikes and then drops. That means a host should not turn this chart into a simple rule like “far out bookings are worse.” Source

First evidence matters here. The published matrix is from Hospitable and IntelliHost. It reports cancellation percentages by booking lead time and stay length. The footnote says the data is US weighted, covers 342,079 reservations across 8,357 listings, and uses a trailing 12 month window with an unspecified cutoff. The channel mix is not given, and Airbnb only coverage is not established. That limit should stay front and center when anyone tries to generalize the table too far. Source

How to read the table without mixing up the questions

The matrix answers one narrow question: among reservations in each lead time and stay length bucket, what share later canceled? It does not say when those cancellations happened. It does not say how much money the host kept. It does not say whether the canceled nights were rebooked later.

Lead time is about booking creation. Cancellation timing is about how many days before arrival the guest canceled. Revenue retention is about what share of the original booking value stayed with the host after refunds, fees, or other booking terms. Replacement revenue is different again. That is money earned from a new reservation on the same nights after the first one canceled.

Keeping those measures separate prevents a common mistake. A reservation can be made six months ahead and canceled two days before check in. Another can be made five days ahead and cancel the same day. Both affect lead time and cancellation timing in different ways. A single chart cannot answer both unless it shows both fields together, and the Hospitable and IntelliHost chart does not. Source

The full matrix: 30 reported cancellation rates

On a small screen, scroll the table sideways to compare every stay length.

The table has an important hole. A 15 to 29 night stay category is not shown. That missing middle group means you should not imagine a full ladder from short stays to month long stays. The report simply does not provide that missing category. Source

What the same lead time can look like across different stay lengths

One useful way to read the matrix is across a row. Hold lead time constant and compare stay lengths. At 2 to 3 months before check in, the 30+ night bucket shows a 31.9% cancellation rate, while the 3 to 4 night bucket shows 18.7%. The difference is 13.2 percentage points. The ratio is about 1.71 times. That is a real contrast in the displayed table. Source

That comparison is useful because it holds one variable still. The booking was made in the same lead time window. The thing that changes in the row is stay length. Even then, causation is still out of reach. The report does not show per cell counts, cancellation policy mix, channels, listing type mix, market mix, or the exact weighting method. Without those parts, the row difference is an observed pattern, not proof that the extra nights caused the higher rate.

Another reason to stay careful is that 30+ nights is a very broad bucket. A 30 night booking and a much longer reservation both live in that same column. The absent 15 to 29 night category also stops us from checking whether the pattern rises smoothly near the monthly threshold. The chart cannot answer that because the chart does not show it. Source

The 30+ night pattern is the odd part of the study

The longest stay column is the main reason the answer is “not consistently.” Its values are 23.8%, 24.3%, 24.8%, 31.9%, 15.7%, and 17.0% as lead time gets longer. That is not a steady rise. It climbs through 2 to 3 months prior, then drops hard at 3 to 6 months prior, then edges up at 6+ months prior. Source

The sharpest shift is from 31.9% at 2 to 3 months to 15.7% at 3 to 6 months. That is a 16.2 percentage point drop. The next bucket, 6+ months, is 17.0%, still far below the 2 to 3 month spike. A clean “earlier equals more cancellations” story would not bend like that.

Other stay length columns also resist a simple ladder. Four of the five displayed stay length columns have at least one downward step as lead time increases. Only the 3 to 4 night column is nondecreasing across the shown lead time buckets. That count is about columns, not reservations. It just shows that the visual pattern is mixed. Source

Mixed shape does not mean the report is wrong. It means the report is descriptive. Real booking behavior can vary across channels, markets, seasons, booking rules, and guest trip types. Since those factors are not broken out here, the safe reading is narrow: the published matrix contains a nonmonotonic pattern, especially for 30+ night stays, so a simple early booking rule is not supported by the displayed evidence.

Why does the IntelliHost matrix fall short of proving causation?

Observed rates are not causes. The matrix does not include raw reservation rows, cell counts, policy strata, exact channel composition, or exact cohort inclusion and censoring method. Without those, you cannot test whether one group differs from another because of lead time itself or because the groups contain different types of reservations. Source

One simple example shows the problem. A long stay booked far out may come from a different market, a different listing type, or a different booking channel than a short weekend stay booked close in. If those hidden factors differ, the final cancellation rates can differ too. The chart does not isolate lead time the way a controlled test would.

Another missing piece is maturation. A still active future reservation is not a completed paid stay. If a host pulls a fresh export and counts future bookings that have not had time to cancel yet, the apparent cancellation rate can be biased. That is why an observation cutoff and cohorts with enough follow-up matter when you build your own comparison set.

Avoid mixing booking lead time with cancellation timing

The Hospitable and IntelliHost table is about when a booking was made. A separate Key Data article is about when cancellations happened before arrival in a Q4 2024 US Airbnb cancellation sample. The article says 16% of cancellations happened 7 to 14 days before check in and 23% happened 14 to 30 days before check in, for a combined 39% of cancellations in the 7 to 30 day window. That denominator is cancellations, not all bookings. Source

Those two datasets should not be merged. One speaks to booking creation lead time by stay length. The other speaks to cancellation timing before arrival in a different population. You cannot multiply them, pool them, or use one to fill missing fields in the other. The sources measure different things.

The day 14 boundary convention is also not supplied in the Key Data note. That means even the 7 to 14 and 14 to 30 day split should be read exactly as published, without adding hidden precision. Useful signal is still there, but the signal is narrow. A sizable share of cancellations in that sample happened in the 7 to 30 day period before check in. It does not tell you the cancellation rate among all reservations. Source

What Key Data’s 2025 booking window snapshot shows

Key Data also published a regional booking window snapshot for 2025 versus 2024 as of November 20, 2025. The reported year over year changes were Rocky Mountains +3%, New England +2%, Southeast -3%, Mid Atlantic -3%, and Southwest -5%. The spread between Rocky Mountains and Southwest is 8 percentage points in reported year over year change. Source

The percentages above describe changes in regional average booking window, not booking-window lengths in days. It is also a partial year pacing snapshot, not finalized full year performance and not a live 2026 update. So the right use here is modest. Regional booking windows can move in different directions at the same time, which is another reason not to force one universal booking rule from a broad national aggregate. Source

How can hosts compare cancellation outcomes in their own records?

The published matrix can help a host frame a local comparison. The following is a proposed measurement workflow for that comparison, with a clear cutoff and visible denominators. It has not been run on private host records here.

Start with an observation cutoff. For example, choose a date after which no reservation activity is counted for the study period. Choose eligibility rules in advance, using original scheduled arrival dates whose follow-up is complete by that cutoff, and retain every eligible reservation regardless of whether it canceled or stayed. Future bookings that are still active should not be called completed because they still have time to cancel, modify, or stay.

Next, deduplicate reservations. Reservation systems often keep status changes, date changes, or altered booking terms as separate records or logs. Your analysis needs one reservation level record per original reservation identifier, with linked change history if available. Otherwise, one booking can be counted more than once.

Then make the denominator visible. If you report a cancellation rate, show the count of reservations in each cohort and the count canceled in each cohort. Without those counts, a rate can look stable or unstable for reasons the reader cannot inspect.

Comparable cohorts with enough follow-up need the same listing type, channel, stay length bucket, booking lead time bucket, and booking period. A cancellation question can also depend on whether booking terms were recorded at creation. A reservation that changed policy later is not the same as one that started under different terms. The key is to compare like with like as much as your records allow.

A practical field checklist for host records

For a clean cohort file, keep anonymous reservation and listing identifiers. No personal guest identifiers are needed for this workflow.

Useful fields include channel, reservation creation date, cancellation date if canceled, check in date, check out date, and stay length. Add the booking terms as recorded at creation, not just current terms after later edits. Add original rental amount, retained charges or refunds, and any final status field that marks stayed, canceled, or other end state.

For replacement booking analysis, add a way to match later reservations to the same listing and nights. You also need final rental revenue for the replacement booking record. That allows two different questions. One question is how much original booking revenue was retained after cancellation. Another question is how much new revenue was later recovered on the same canceled dates. Those are separate measures.

Missing cancellation dates block timing analysis. If you do not know when a cancellation happened, you cannot place it in a 7 to 14 day or 14 to 30 day window. Missing original booking terms block policy level comparisons. Missing listing identifiers block same listing matching. Missing check in and check out dates block night level overlap checks.

Night overlap matters because replacement revenue can be overstated if overlapping nights are counted twice. A canceled five night booking and a later three night replacement on part of the same window should not be treated as if all eight nights were recovered. Match by listing and night, then avoid double counting the same night across original and replacement records.

Freeze the denominator before looking at the result

Write down which reservations belong in the comparison before calculating a rate. A useful starting definition is all eligible reservations originally scheduled to arrive in a fixed period, for the selected listings and channels. Include reservations that canceled as well as those that stayed. An export containing only completed stays has already removed the canceled reservations, so it cannot supply the denominator for this question. Keep unresolved records visible as a separate count rather than quietly dropping them from the file.

Use the original creation timestamp and original scheduled arrival date to assign booking lead time. Preserve the original booked stay length too. Keep subsequent date changes in a linked history. Otherwise a guest who moves an arrival date may appear to have booked earlier or later than the guest actually did under the original agreement. State whether your question concerns the original booking decision or the amended stay. Both can be useful, but they need different field definitions and should not share an unlabeled rate.

Check how the system records a cancellation followed by a new booking. A new confirmation number may represent a separate purchase, while an amendment may retain the original reservation identifier. Document the rule used to distinguish those events. Do not merge records because the dates look similar, and do not count a status log entry as another reservation. If an identifier cannot be reconciled, show the affected count and leave that part of the comparison unresolved until the records can support it.

Keep the reservation view and the money view separate

Build a reservation summary first: eligible reservations, canceled reservations, completed stays, and unresolved outcomes in each comparable group. Show the denominator beside every reported rate. Then build a separate payment view for the same reservation identifiers. Use the same definition of rental revenue on both sides of the comparison. If cleaning charges, taxes, or platform fees are excluded from the original amount, do not add them into the replacement amount. Record the currency and payment status so pending money is not presented as settled income.

For replacement analysis, match later bookings to the same listing and the actual nights released by the cancellation. Separate overlapping nights from any additional nights in the replacement stay. If the system supplies only a total booking amount, document how that amount is allocated across nights; do not silently assume that each night had the same price. Keep an unmatched category when the nightly allocation cannot be supported. This makes the limits visible and prevents a long replacement stay from being credited entirely to a shorter canceled stay.

Before interpreting a difference between groups, check whether the mix of listings, channels, arrival seasons, and booking terms changed. Report those differences alongside the counts. A local comparison can identify where closer review is worthwhile; it does not by itself establish that a booking rule caused the outcome. If original terms, cancellation dates, or settled payment records are missing, narrow the question to what the available fields can answer. The next useful step may be improving the export rather than changing the booking rule.

Revenue retained versus revenue recovered

The cancellation rate in the Hospitable and IntelliHost table is a reservation count measure. It tells you what share of reservations canceled in each bucket. It does not tell you how much rental cash a host kept. The source does not provide dollar retention, refunds, or rebooking data. Source

Original booking revenue retention answers one question: after a cancellation, how much of the original rental amount remained with the host under the booking terms? Replacement revenue answers another question: after the canceled nights opened up, how much new rental revenue came from a later reservation on those same nights? A host may retain some original revenue, recover some nights with a new booking, both, or neither.

Hypothetical example only: one canceled reservation had an original rental amount recorded at creation, a later refund amount, and a matched replacement stay on some of the same nights. In that case, the retained share of original revenue and the recovered revenue from replacement nights are different outputs from different records. No actual retention number should be inferred from the published sources because the needed fields are absent.

Next steps for a host cancellation review

The useful lesson is not “accept fewer early bookings” or “change your rules now.” The useful lesson is narrower. The published matrix shows that cancellation risk can vary by both lead time and stay length, and the longest stay bucket does not follow a neat rising line. So any host decision should be tested against a matched local cohort rather than copied from a broad aggregate.

Good local review starts with the right question. If you want to know whether early bookings cancel more, compare eligible reservations, including cancellations and completed stays, by booking creation lead time and original stay length. If you want to know when cancellations hit before arrival, you need cancellation dates. If you want to know the money effect, you need retained charges, refunds, and replacement revenue records. Different records answer different questions.

That distinction sounds simple, but it prevents many bad reads of industry charts. A host can look at one benchmark table, one timing note, and one regional pacing snapshot and think they fit together like puzzle pieces. They do not. Each source uses its own measure and population. Read each one on its own terms first.

If you want help applying this guide to your operation, Book a strategy session.