ホテルチェーンとBraze 宿泊前後ジャーニーとOTAデータの限界整理（概念）
目次 クリックで開く
ホテル業界において、顧客一人ひとりに最適化されたコミュニケーションを実現する「Braze」の導入が進んでいます。しかし、いざ実務に落とし込もうとすると、避けて通れないのが「OTA（Online Travel Agent）データの限界」です。
自社サイトからの予約（直販）であれば、メールアドレスや氏名、属性情報が完全に取得できますが、楽天トラベル、一休.com、Booking.comといったOTA経由の予約では、顧客データがマスクされたり、不完全な状態でPMS（宿泊管理システム）に届くことが珍しくありません。本記事では、IT実務者の視点から、OTAデータの制約を整理した上で、Brazeを用いて宿泊前後のカスタマージャーニーをどう設計すべきかを具体的に解説します。
1. ホテルCRMにおけるBraze活用の意義と「OTAの壁」
1.1 なぜホテル業界でBrazeが選ばれるのか
ホテル運営において、顧客体験は「予約時」ではなく「宿泊前後」のタッチポイントで決まります。Brazeが選ばれる理由は、単なるメール配信ツールではなく、リアルタイムのイベントトリガーに基づいたマルチチャネル配信（プッシュ通知、LINE、メール、アプリ内メッセージ、SMS）が可能だからです。
- 宿泊前：予約したプランに合わせた周辺観光情報の自動送付
- 宿泊当日：チェックイン時間に合わせて、モバイルキーの案内や混雑状況の通知
- 宿泊中：館内レストランの空き状況や限定クーポンの配信
- 宿泊後：アンケート送付と、次回の直販予約限定オファー
1.2 避けて通れない「OTAデータの壁」
一方で、日本のホテルにおける予約比率の多くを占めるOTA経由の予約には、以下の「データの壁」が存在します。Brazeで高度なシナリオ（Canvas）を組もうとしても、この壁を理解していないと、意図した配信が届かないという事態に陥ります。
- メールアドレスの匿名化：OTA独自の転送用アドレス（例：xxx@guest.booking.com）が割り振られる。
- アプリトークンの不在：自社アプリをインストールしていないため、プッシュ通知が打てない。
- 属性情報の欠如：誕生日や過去の宿泊履歴がOTAからは共有されない。
2. OTAデータの限界整理：Brazeで「できること・できないこと」
実務において、OTAからPMSに流れてくるデータがBrazeでどう扱われるかを正確に把握しておく必要があります。以下の表に、主要な制約を整理しました。
| 項目 | 直販予約（D2C） | OTA予約（楽天/一休/Booking等） | Brazeでの影響 |
|---|---|---|---|
| メールアドレス | 実アドレスを取得可能 | マスク（プロキシ）アドレス | 一定期間後に無効化される。画像表示やリンククリックが制限される場合がある。 |
| プッシュ通知 | アプリ保持者なら可能 | 不可（原則） | メールまたはSMSが唯一の接点となる。 |
| 会員属性 | 完全（誕生日・居住地等） | 氏名・電話番号・性別のみ | パーソナライズされたお祝いメッセージなどが送れない。 |
| 名寄せ（ID連携） | 容易（会員IDで統合） | 困難 | 過去の宿泊実績と紐づけるために、電話番号や氏名でのマッチングが必要。 |
2.1 マスクメールアドレス（プロキシメール）の仕様と寿命
Booking.comやExpediaなどの外資系OTAに多い「マスクメールアドレス」は、宿泊完了から数日〜数週間で送受信ができなくなる仕様です。そのため、「宿泊後の長期的なリレーション構築（数ヶ月後の再訪案内）」には使えません。宿泊中に自社アプリのダウンロードや、LINE友だち登録を促し、永続的なID（External ID）を確保することが必須となります。
このデータ統合の重要性については、以下の記事で解説している「ID連携のアーキテクチャ」が非常に参考になります。
WebトラッキングとID連携の実践ガイド。ITP対策・LINEログインを用いたセキュアな名寄せアーキテクチャ
3. 宿泊サイクル別：Brazeによる理想的なコミュニケーションジャーニー
OTAデータの制約を前提に、Brazeで構築すべき宿泊前後ジャーニーを設計します。
3.1 【宿泊前：Pre-stay】期待感の醸成とアップセル
予約確定（Reservation Confirmed）イベントがPMSからBrazeへ飛んだ瞬間からジャーニーが始まります。
- 3日前：「周辺の観光・グルメマップ」をメールで送付。この際、OTA経由者には「公式サイトでの予約特典（館内利用券など）」をあえて紹介し、次回以降の直販誘導の布石を打ちます。
- 1日前：「オンラインチェックイン」の案内。BrazeのCanvas機能を用いて、未開封者にはSMSで再送するなど、確実に情報が届くように設計します。
3.2 【宿泊中：In-stay】施設体験の最大化
チェックイン完了（Check-in）イベントをトリガーにします。
- 入室後：ホテルのWi-Fi接続画面（キャプティブポータル）とBrazeを連携。Wi-Fi接続をトリガーに、アプリ内メッセージやLINEで「本日のディナー空き状況」を通知します。
- 滞在中：プールの混雑状況、大浴場の利用状況などを、Brazeの「Content Blocks」を活用して動的に表示させます。
3.3 【宿泊後：Post-stay】ファン化と直販誘導
チェックアウト完了（Check-out）をトリガーにします。
重要：OTA顧客のマスクメールアドレスが有効なうちに、自社会員への「コンバージョン」を狙います。
- 当日夜：感謝のメッセージと共に、今回の宿泊で付与されるはずだった「自社ポイント」のシミュレーションを提示し、会員登録を促します。
- 7日後：アンケート送付。ここで取得した回答内容は、Brazeの「User Profile」にカスタム属性として保存し、次回のパーソナライズに活用します。
LINEを主要な接点とする場合、リッチメニューの動的な切り替えも有効です。詳細は以下の記事をご参照ください。
LINE データ基盤から直接駆動する「動的リッチメニューとキャンペーンモジュール」のアーキテクチャ
4. 実践：PMS（宿泊管理システム）とBrazeの連携アーキテクチャ
ホテル実務において最大の難関は、レガシーなPMSからいかにリアルタイムにデータをBrazeへ渡すかです。
4.1 データ連携の3つのパターン
- APIによる直接連携：PMSがWebhooksに対応している場合、予約発生・キャンセル時に直接Brazeの
/users/trackエンドポイントを叩きます。最もリアルタイム性が高い手法です。 - S3経由のファイル連携：多くの国内PMSで採用されています。1日数回、CSVファイルをS3へアップロードし、Brazeの「Cloud Data Ingestion」機能（公式ドキュメント：Braze Cloud Data Ingestion）で取り込みます。
- モダンデータスタック（BigQuery + リバースETL）：複数のPMSや基幹システムが存在する場合、一度BigQuery等のDWHに集約。dbtで名寄せ（クレンジング）を行い、HightouchやCensusといったリバースETLツールでBrazeへ同期します。
特に、高額なCDPを導入せずともBigQueryを活用することで、コストを抑えた柔軟な運用が可能です。この設計思想については、以下の記事が実務に直結します。
高額なCDPは不要？BigQuery・dbt・リバースETLで構築する「モダンデータスタック」ツール選定と公式事例
4.2 OTAデータの「クレンジング」と「名寄せ」のポイント
OTAから流れてくるデータには「外字」や「電話番号のフォーマット不備」が含まれます。Brazeに送る前に、以下の処理が必要です。
- 電話番号の正規化：ハイフンの除去、国番号（+81）の付与。
- 氏名の名寄せ：「漢字氏名」と「カナ氏名」が別々に届く場合、既存ユーザーと一致するかを、正規化した電話番号をキーに照合します。
- OTAフラグの付与：カスタム属性として
reservation_source: "OTA_RAKUTEN"のようにソースを記録し、セグメント分けを可能にします。
5. 主要ツール比較：ホテルCRMにおけるBraze vs 他社製品
| 機能・特性 | Braze | Salesforce Marketing Cloud | 国内向けMA（b-dash等） |
|---|---|---|---|
| リアルタイム性 | ◎（ミリ秒単位のトリガー） | △（バッチ処理が基本） | ○（ツールによる） |
| マルチチャネル統合 | ◎（一つのCanvasで完結） | ○（Journey Builder） | △（LINE連携に外部ツール要） |
| データ処理柔軟性 | ◎（Liquidによる高度な動的表示） | ○（AMPScript） | △（定型テンプレート中心） |
| コスト | 高い（MAU/イベント課金） | 非常に高い | 中程度 |
※料金の詳細は、各公式サイト（Braze公式 / Salesforce公式）の最新情報をご確認ください。
6. OTA顧客を「自社ファン」に変えるための5つのステップ
最後に、現場で実践すべき具体的な導入ステップをまとめます。
- データ監査：現在PMSから出力可能な項目を洗い出し、OTAごとにどのデータが欠損しているかを確認する。
- データマッピング設計：Brazeのカスタム属性とイベントを定義する（例：
stay_start_date,stay_end_date,room_type）。 - 初回来訪時のID獲得シナリオ構築：OTA顧客がチェックインする際、QRコード経由でLINE連携・自社アプリDLを促すインセンティブ（ドリンク無料券等）を設計する。
- Canvas（自動化）の構築：「宿泊3日前」「宿泊後1日」など、タイミングを外さない配信シナリオを組む。
- 継続的なパーソナライズ：宿泊中の行動ログ（Wi-Fi利用、レストラン予約）を蓄積し、次回の宿泊時に「おかえりなさいませ」の一言を添えたパーソナライズメッセージを送る。
ホテル業界におけるDXは、単なるツールの導入ではなく、「不完全なOTAデータ」をいかに「自社の資産」へ変換し、Brazeという強力なエンジンで駆動させるかにかかっています。まずは、現在のデータ基盤を見直し、スモールスタートで宿泊前後のコミュニケーションを自動化することから始めましょう。
7. 実装前に確認すべき「Brazeデータ仕様」の共通の落とし穴
BrazeをホテルCRMとして活用する際、エンジニアやデータ担当者が陥りやすい技術的な制約がいくつかあります。特にOTA経由のデータは、ソースごとにフォーマットが異なるため、以下のチェックリストを事前に確認してください。
7.1 技術的な事前チェックリスト
- タイムゾーンの設定：PMSから出力される時刻データが「JST（日本標準時）」か「UTC」か。Braze内でのセグメント計算や配信トリガーに影響します。
- External IDの設計：OTA顧客は自社会員IDを持たないため、初期値として何をキーにするか（電話番号を正規化した文字列など）のルール決めが必要です。
- レートリミットの考慮：宿泊予約イベント（API）が集中する時間帯に、BrazeのAPI制限（デフォルトでは毎分一定数まで）に抵触しないか確認が必要です。
7.2 公式リソースとドキュメント
実装の詳細や最新の仕様については、以下の公式ドキュメントを必ず参照してください。
- User Track API Reference（公式）：予約・チェックインイベントの送信仕様。
- Canvas Entry Properties（公式）：予約内容（部屋タイプ等）を配信文面に動的に差し込む手法。
8. ホテルCRMにおける「外部ID」の優先順位と移行コスト
OTA経由の「匿名の宿泊者」を、いかに永続的な自社IDへ統合するかが鍵となります。IDの永続性と取得の難易度を整理しました。
| IDの種類 | 永続性 | 取得のハードル | Brazeでの主な用途 |
|---|---|---|---|
| マスクメールアドレス | 低（宿泊後消滅） | なし（自動取得） | 宿泊直後のサンクスメール、アンケート。 |
| LINE User ID | 高 | 中（友だち登録要） | 継続的な再訪促進、リッチメニュー出し分け。 |
| 自社会員ID | 極めて高 | 高（会員登録要） | ポイント連携、宿泊履歴に基づくLTV分析。 |
特にLINEを活用した接点構築は、OTA顧客の離脱を防ぐ最も有効な手段の一つです。具体的な実装アーキテクチャについては、LIFF・LINEミニアプリ活用の本質。Web行動とLINE IDをシームレスに統合する次世代データ基盤の記事が、Brazeとのデータ統合を考える上で非常に役立ちます。
また、宿泊業界特有の「家族予約（代表者1名のみデータがある状態）」への対応など、より高度な名寄せが必要な場合は、【図解】SFA・CRM・MA・Webの違いとデータ連携の全体設計図を参照し、各システムの責務を再定義することをお勧めします。
ご相談・お問い合わせ
本記事の内容を自社の状況に当てはめたい場合や、導入・運用の設計を一緒に整理したい場合は、当社までお気軽にご相談ください。担当より折り返しご連絡いたします。