# 値下げが元を取れたかを RevPAR で判定する（宿泊・OTA運用） 「稼働率が上がった／下がった」だけを見ると値下げの評価を必ず間違える。 単価×稼働＝RevPAR で見ると逆の結論になることがある。実測でそれが起きた事例をもとに、 **予約明細だけから機械判定まで持っていく手順**をまとめる。 外部APIを新たに叩かない。手元にある予約明細（1件1レコード）だけで完結する。 ## 0. 前提: 必要なフィールド チャネルマネージャ／PMS の予約エクスポートに次があれば足りる。 | 用途 | フィールド | |---|---| | 有効判定 | ステータス、キャンセル日時、予約日時 | | 期間 | チェックイン日、チェックアウト日 | | 金額 | 滞在合計金額（**グロス＝客が払う額**）、手数料 | | 切り分け | チャネル名（OTA名） | | 対象絞り | 部屋ID | **注意: 金額は「滞在合計」であって1泊単価ではないことが多い。** 泊数で割る前に必ず確認する。 ## 1. 泊単位に展開する（ここを間違えると全部狂う） 1予約を `泊数 = チェックアウト − チェックイン` に展開し、 **金額と手数料を泊数で等分**して各泊に配る。泊が属する月は **その泊の日付**で決める（チェックイン日で決めると月境をまたぐ連泊が全部前月に寄る）。 日付演算は必ず UTC で行う。`new Date('2026-09-16T00:00:00Z')` と `+ i*86400000`。 ローカルタイムゾーンで足すと夏時間・タイムゾーン跨ぎで1泊ずれる。 **除外するもの** - セット販売用の仮想部屋（複数部屋を1商品として売るための架空の部屋ID）。 実部屋IDのホワイトリストで絞る。仮想部屋を混ぜると単価が数倍に化ける。 - キャンセル済み・仮予約・金額0。 **落とした件数を理由別・年別に必ず出力する。** 「有効N件」だけ出すと、 片方の年だけフィルタで大量に落ちていても気付けない。 ## 2. 3つの指標を必ず並べる | 指標 | 式 | 分母 | |---|---|---| | 稼働率 | 売れた室泊 ÷ capacity | capacity = 部屋数 × 日数 | | ADR | 収益 ÷ **売れた室泊** | 売れた室泊 | | **RevPAR** | 収益 ÷ **capacity** | capacity | **RevPAR の分母は売れた室泊ではなく capacity。** ここを間違えると ADR と同じ数字になる。 グロス（客が払う額）とネット（手数料を引いた手残り）の**両方**を出す。 チャネルごとに手数料率が違うので、構成が変わるとグロスとネットで前年比がずれる。 ## 3. 比較の窓を先に決める（ここで結論が変わる） ### 3-1. 未完了月を除外する **月末が今日より前の月だけ**を前年比に使う。当月・未来月はまだ予約が積み上がる途中で、 入れると必ず「今年は激減」に見える。**除外した月を明示的に出力する**。 ### 3-2. 前年側がイベントで汚染されていないか確かめる 万博・オリンピック・大型国際会議のような一過性の需要イベントは、 **前年の ADR を1.3〜1.8倍に膨らませる**。その期間と比べると自動的に「今年は半減」になる。 やること: **イベント期間にかかる月を前年側から外した窓をもう1本作り、両方の結果を並べる。** 片方だけ出すと結論を選んでいるのと同じ。 実例: 前年ADRが 14,000〜18,255 の月はすべてイベント期間内で、 イベント外の月は 9,944〜11,652 だった。**前年比 −40% が −28% になった**（が符号は変わらなかった）。 ## 4. チャネル構成の変化を分離する（shift-share） 「単価が落ちたのは高単価チャネルが消えたからだ」を検証する。 `s_c` = チャネル c の室泊シェア（Σ=1）、`a_c` = チャネル c の ADR。 ``` 総変化 total = Σ s'_c·a'_c − Σ s_c·a_c 構成効果 mix = Σ (s'_c − s_c) · a_c ← 構成が変わったことによる分 単価効果 rate = Σ s_c · (a'_c − a_c) ← 各チャネルの自単価が動いた分 交差項 inter = Σ (s'_c − s_c) · (a'_c − a_c) ``` **`mix + rate + inter === total` を ±1 で assert する。** 合わなければ実装が間違っている （片方の年に存在しないチャネルの扱いが典型的な原因）。合わなかったら異常終了させる。 **片方の年に0泊のチャネル**は、ADR を 0 にすると mix 効果が暴れる。 **相手年の ADR を流用**して「純粋なシェア移動だけ」を mix に載せる。 ### 説明力の計算で符号を間違えない `「低下のうち構成変化で説明できる割合」= mix / total`。 **絶対値の比 `|mix|/|total|` にしてはいけない。** 構成変化が単価を*押し上げていた*場合 （mix と total が逆符号）、絶対値比が 50% を超えて「構成変化で説明できる」と誤判定する。 逆符号なら説明力は 0% と数える。符号付きの生の比も併記して隠さない。 反実仮想も1本出す: `Σ s_c(前年の構成) · a'_c(今年の単価)` ＝「構成が変わっていなければ今年の ADR はいくらだったか」。 ## 5. RevPAR を単価要因と稼働要因に分ける `RevPAR = ADR × 稼働率` なので同じ形で分解できる。 ``` ADR効果 = (a' − a) · o 稼働効果 = a · (o' − o) 交差項 = (a' − a) · (o' − o) ``` ここでも和が ΔRevPAR と一致することを assert する。 出力は「**RevPAR低下のうち単価由来 X% / 稼働由来 Y%**」の1行にする。 ## 6. 値下げの取引レートを出す（これが判定の核心） 値下げは「単価を売って稼働を買う」取引。**レートで評価する。** ``` ADR 1% 下げあたり獲得できた稼働pt = 稼働の前年差pt ÷ (−ADR前年比%) RevPAR中立に必要だった稼働% = 前年稼働% × (前年ADR ÷ 今年ADR) 不足pt = 必要稼働% − 実際の稼働% ``` **必要稼働が 100% を超えたら、その価格帯では構造的に取り返せない。** 値下げ幅を議論する前にこれを出す。 実例: ADR −34.4% に対して稼働は +6.6pt しか動かず（1%下げあたり 0.2pt）、 RevPAR 中立に必要な稼働は **128.1%** ＝ 満室でも不可能だった。 ## 7. exit code で機械判定する 人が表を読んで解釈すると、見たい結論が出る。**判定を式にして終了コードに落とす。** ``` mix / total >= 50% → チャネル構成変化で説明できる → exit 0 mix / total < 50% → 自社の値付け由来が主因 → exit 1 整合性 assert 失敗 → exit 2 ``` **イベント汚染を外した窓の判定を採用し、汚染込みの窓と食い違ったら警告を出す。** 両方の数字を出力してから、採用した窓を1行で宣言する。 `--json` を付けたら全指標を JSON で出す（表は出さない）。終了コードは同じにする。 これで日次バッチから叩ける。 ## 8. 結論を書くときの限界（誠実さの担保） この手順で確定できるのは次の2点だけ。 - 構成変化では説明できない - 獲得した稼働が RevPAR 中立に足りていない **「自社が値下げしたから単価が落ちた」と「市場全体の単価が落ちた」は自社データでは分離できない。** 分離するには対照群（同エリアの他施設の公開情報など）が要る。 ただし**どちらであっても「現行価格は volume で正当化できない」は変わらない**ので、 打ち手の判断はこの手順だけで下せる。 **値下げの適用日と単価低下の開始日を必ず突き合わせる。** 実例では値下げ施策の適用は8月末で、 単価低下は同年1月から始まっていた。**施策は原因ではなく、値付け体制全体の問題だった。** 日付が合わなければその仮説はそこで終わり。 ## 9. 落とし穴チェックリスト - [ ] 金額は滞在合計か1泊単価か確認したか - [ ] 泊が属する月をチェックイン日でなく泊の日付で決めたか - [ ] 日付演算を UTC でやったか - [ ] 仮想部屋を除外したか - [ ] 落ちた件数を理由別・年別に出力したか - [ ] 未完了月を除外し、除外した月を出力したか - [ ] 前年側のイベント汚染を外した窓を並べたか - [ ] RevPAR の分母を capacity にしたか（売れた室泊ではない） - [ ] グロスとネットを両方出したか - [ ] shift-share の和を assert したか - [ ] 説明力を絶対値比にしていないか - [ ] 月別の予約件数（サンプル数）を出したか - [ ] 判定を exit code に落としたか ---