バケーションレンタル向けアナリティクスダッシュボードをYellowfinで構築する
バケーションレンタル（民泊、貸し別荘）の運営は、非常に手間のかかる仕事です。
ゲストとのコミュニケーション、清掃スタッフの管理、価格戦略の策定……。いずれも時間を要する業務です。
さらに難しくしているのは、多くの意思決定が不完全な情報に基づいて行われていることです。「今月は忙しかった気がする」「価格が少し安すぎるかもしれない」「ある予約チャネルが徐々に主流になってきているようだ」といった感覚です。こうして、いつの間にか直感が根拠に取って代わってしまいます。
目次
バケーションレンタル向けアナリティクスが真価を発揮します
アナリティクスは、ビジネスで実際に何が起きているのかを客観的に示してくれます。推測に費やす時間を減らし、行動に集中できるようになります。さらに重要なのは、ゲストが再び利用したくなるような、一貫して質の高い体験を提供できるようになることです。
課題は、真実が予約プラットフォームやスプレッドシート、そして勘に分散していることです。優れたダッシュボードは、それらを一か所に集約し、パフォーマンスを迅速かつ率直に把握できるようにします。そして、何か異常や想定外に良い結果が見えた瞬間に、さらに深く掘り下げられる機能も備えています。では、今回構築する内容はこちらです。
ステップごとに解説：バケーションレンタルダッシュボードの構築方法
アプリを構築する際の目標は、単にチャートを提供することではありません。ユーザーが日常的に利用しているワークフローの中で、確信を持って判断できるようにすることです。そのためにあるのが組み込みアナリティクスです。ダッシュボードはアプリ内に配置され、製品の言語で語り、ユーザーがすでに抱いている問いに答えます。スプレッドシートや別のプラットフォームへ移動させる必要はありません。
このブログ記事では、実際の組み込みシナリオで使用するのと同じ基盤を構築します。
- PostgreSQLに保存された予約データセット
- Yellowfinでのクリーンなデータソース接続
- ダッシュボードおよびNLQ向けに設計されたビュー
- そして、製品の成長に合わせて拡張できるダッシュボード
ステップ1：PostgreSQLデータベースの作成方法
まず、予約データをPostgreSQLに保存します。各予約が1行となり、予約日、宿泊日数、1泊あたりの料金などの変数を含めます。PowerShellからpsqlを開き、デモ用のデータベースを作成します。
CREATE DATABASE hotel_demo;
\c hotel_demo
予約テーブルの作成
次に、物件オーナーが自然に抱くような質問をサポートできるよう設計された、フラットな bookings テーブルを作成します。
DROP TABLE IF EXISTS bookings_flat;
CREATE TABLE bookings_flat (
booking_id INTEGER PRIMARY KEY,
booking_date DATE,
nights_booked INTEGER,
guests INTEGER,
apartment_capacity INTEGER,
guest_country TEXT,
channel_type TEXT,
device TEXT,
nightly_rate_eur NUMERIC(10,2),
total_booking_value_eur NUMERIC(12,2)
);この構造は意図的にシンプルに設計されています。実際の予約システムの仕組みを反映し、データの粒度（1行＝1予約）を明確に保ちます。その結果、後続のアナリティクスが説明しやすくなり、拡張もしやすくなります。
CSVファイルからPostgreSQLテーブルへデータを読み込む
テーブルの準備ができたら、CSVファイルを読み込みます。
\copy bookings_flat
FROM 'C:\Users\YourUser\Desktop\bookings_flat.csv'
DELIMITER ','
CSV HEADER;
簡単な確認を行い、すべてのデータが正しく取り込まれているかを確認します。
SELECT COUNT(*) FROM bookings_flat;
この時点で、予約単位のクリーンなデータセットが整い、アナリティクス層に公開できる状態になりました。
次のステップでは、このデータベースをYellowfinに接続し、最初のビューを作成して、エンドユーザーが製品内で直接探索できる形へとデータを整えていきます。
ステップ2：PostgreSQLをYellowfinに接続し、安全にデータを公開する
次に行うのは、データベースを制御された形でアナリティクス層に公開することです。
ここで登場するのがYellowfinです。
プロダクトチームにとって、このステップは非常に重要です。単にデータベースへ接続するのではありません。エンドユーザーがアプリケーション内で「何を見ることができるのか」「何を質問できるのか」「どのようなインサイトを構築できるのか」を決める工程なのです。
YellowfinでPostgreSQLデータソースを作成する
Yellowfinの管理画面（Admin Interface）から、新しいデータソースを作成し、PostgreSQLインスタンスに接続します。
必要な情報は以下の通りです。
host
port
database name
username
password
接続が成功すると、Yellowfinはデータベースのスキーマを認識します。ただし、この段階ではまだユーザーに何も公開されていません。この分離が重要です。テーブルは自動的にレポート可能になるわけではありません。
bookingsテーブルに基づくビューの作成
次に、bookings_flatテーブルを基にViewを作成します。
Yellowfin内で：
新しいビューを作成
ベーステーブルとして bookings_flat を選択
ビューの内部では、各フィールドを適切に設定します。
このステップは管理作業のように見えるかもしれませんが、ユーザー体験に直接影響します。適切に定義されたビューは、ダッシュボードの構築を容易にし、NLQの質問精度を大きく向上させます。
この時点で可能になること
1つのビューを用意するだけで、次のことが同時に実現します。
SQLに触れることなくダッシュボードを構築できる
NLQが何をカウント・平均・グループ化できるかを正しく理解できる
データベースを変更せずにプロダクトチームがアナリティクスを進化させられる
最も重要なのは、明確な境界を作れたことです。PostgreSQLは引き続き唯一の正しいデータソース（source of truth）として機能します。そしてYellowfinはストーリーテリングのレイヤーとなります。
次のステップでは、このビューを使ってダッシュボードの最初のチャートを作成し、NLQがどのように自然に組み込まれるかを示します。
ステップ3：最初のチャートを構築し、NLQの強みを活かす
bookingsビューの準備ができたので、いよいよプロダクトチームにとって最も重要な問いに答えます。
エンドユーザーにとって有用なアナリティクス体験とは何か？
ここでの目的は、考えられるすべてのチャートを作ることではありません。適切なチャートを表に出すことです。ひと目で状況を理解でき、自然に次の質問を生み出すようなチャートです。
ここからYellowfinの強みが発揮されます。
探索ではなく、成果から始める
まずは成果レベルの問いに答えるチャートを構築します。これらは、特別なガイドがなくても物件オーナーが自然に抱く質問です。
売上の推移（Revenue over time）
これはダッシュボードのアンカーとなるチャートです。ビジネスが正しい方向に進んでいるかどうかを示し、他のすべての指標の文脈を与えます。
このチャート単体では、なぜ売上が増減したのかまでは説明しません。しかし、「どこを次に見るべきか」を示してくれます。
月別平均宿泊単価（Average nightly rate by month）
このチャートは、売上変動に意味を与えます。パフォーマンスが価格によるものなのか、それとも予約件数（ボリューム）によるものなのかを示します。
売上が上昇し、宿泊単価が安定している場合、需要が増加している可能性が高いと言えます。
一方で、単価が下がっているのに予約数が伸びていない場合は、価格戦略を見直す必要があるかもしれません。
この2つのチャートだけでも、推測は大きく減ります。曖昧な印象が、測定可能な事実へと変わります。
行動データを重ねる
成果が見えるようになったら、次に行動データを重ねます。
予約件数（Number of bookings）
予約件数は、価格とは独立した需要を示します。
予約件数が増えているのに売上が横ばいであれば、価格に下方圧力がかかっている可能性があります。
予約件数が減っているのに売上が安定している場合は、宿泊日数が長い、または単価の高いゲストが増えていることを意味するかもしれません。
平均宿泊日数（Average length of stay）
ここで、運営上の現実が見えてきます。
宿泊日数が長いほど、清掃回数は減り、オペレーションは安定します。
宿泊日数が短い場合、業務負荷は増え、予約件数が多く見えても実際の需要が弱い可能性があります。
これらのチャートは、「何が起きたか」だけでなく、「どのように起きたか」を理解する助けになります。
戦略を可視化する
最後に、長期的な意思決定に影響を与えるチャートを表示します。
チャネル別売上（Revenue by channel）
このチャートは、Booking.com、Airbnb、Expedia、直接予約、ウォークインなど、どのチャネルにどれだけ依存しているかを示します。
OTAへの依存度が高いと、集客は増えますが利益率に影響します。
直接予約の増加は、健全な需要やブランド認知の向上を示すことが多いです。
これにより、単なる日々のパフォーマンス確認を超えて、戦略的な意思決定が可能になります。
ゲストの出身国（Guest origin）
ゲストの国情報は、数値だけでは見えない文脈を与えます。
このチャートを継続的に確認することで、マーケティングの重点地域や季節ごとの価格戦略に活かすことができます。
NLQが自然に組み込まれる場所
これらのチャートがそろうと、NLQは単なる目新しい機能ではなく、ダッシュボードの自然な延長として機能します。
ユーザーは次のような追加質問をそのまま入力できます。
先月のチャネル別予約数
直接予約の平均宿泊単価
ドイツからのゲストによる売上
デバイス別の平均宿泊日数
ビューが適切に設計されているため、これらの質問は特別な説明なしに妥当な回答を返します。NLQは、データモデルがユーザーの思考構造を反映しているときに最も効果を発揮します。
プロダクトチームにとっての意味
もはや静的なレポートを見せているのではありません。ユーザーに提供しているのは次の3つです。
パフォーマンスに関する共通の可視化基盤
自分自身で質問できる能力
すべてが同じ唯一の正しいデータソースに基づいているという信頼
そして最大の利点は、データベースに新しいデータが入るたびに、Yellowfinのチャートが自動的に更新されることです。つまり、ユーザーはビジネスの状況をリアルタイムで把握できます。
自分自身のダッシュボードを構築する準備はできましたか？
プライベートプレイグラウンドに登録すれば、Yellowfinの機能をフルに体験できます。さらに、アプリにアナリティクスを組み込むためのコードサンプルも用意されています。
