データ製品のユースケース

  • リリースバージョン: Australia
  • 更新日 2026年03月30日
  • 所要時間：4分

    • データ製品を公開するための一般的なシナリオを確認し、どのパターンがデータとコンシューマーのニーズに合っているかを確認します。

    データ製品は 1 つ以上のデータインターフェイス上にビルドされ、それぞれがソースデータへのアクセス方法と結合方法を決定します。適切なデータインターフェイスのタイプは、データの場所、構造、コンシューマーがそれを使って何をしたいかによって異なります。

    旅行会社のロイヤルティ分析チームは、ゴールドスター会員の飛行機の利用が減っているという明確な傾向を目の当たりにしています。調査の原動力となる中心的な疑問は、ゴールド会員の予約が減っている路線はどれで、状況は悪化しているのかということです。データは、フライトセグメント、ポイント台帳、メンバープロファイルなど、Snowflake に存在します。倉庫に直接アクセスできるアナリストはおらず、データの機密性が高すぎてエクスポートできません。チームは、ServiceNow 内からライブ Snowflake データをクエリし、管理可能なアクセス制御を使用する方法を必要としています。

    チームは調査を 4 つの具体的な質問に分け、それぞれに専用のデータインターフェイスで回答します。

    • どのルートが最も多くのポイント獲得アクティビティを生み出すか?
    • 前四半期に各ルートを予約したゴールド会員数は何人ですか?
    • どの路線で予約数が時間の経過とともに減少していますか?
    • 現在アクティブでない長期在籍ゴールド会員は何人いますか?

    ルートとキャビンクラス全体の予約傾向の追跡

    予約量を経時的に追跡するには、チームにルート、月、キャビンクラスが必要です。このデータはすべて、1つのSnowflakeテーブル(FLIGHT_SEGMENTS)に存在します。FLIGHT_SEGMENTSを介した単一テーブルデータインターフェイスでは生のセグメントデータが公開され、プラットフォームアナリティクスダッシュボードはクエリ時に日付フィルターと上位ルートランキングを適用します。インターフェイスを汎用のまま維持すると、同じデータで複数のダッシュボードウィジェットにそれぞれを再構築することなく強化できます。11 列が検証された Snowflake の flight_segments への 1 つのテーブル接続を示すデータインターフェイス構成。

    沈黙している長期在職メンバーの特定

    非アクティブなメンバーの質問に答えるために必要なもの (ロイヤルティ階層、在職期間、アクティブまたは非アクティブなステータス) はすべてMEMBER_PROFILEに存在します。単一テーブルインターフェイスは、在職期間が 5 年以上で非アクティブステータスのゴールドメンバーをフィルタリングします。このインターフェイスは、10 人の非アクティブな長期在職期間のゴールドメンバーを表示する KPI ウィジェットと、ハブ空港ごとに分類されたドロップオフチャートの両方を強化します。

    8 つの列が検証された Snowflake の member_profile への 1 つのテーブル接続を示すデータインターフェイス構成。

    ポイント獲得とポイント獲得のルートをつなぐ

    どのルートが最もポイントを獲得できるアクティビティを促進しているかを知るには、2 つのテーブルを接続する必要があります。ポイント取引はPOINTS_LEDGERに存在しますが、ルート情報(出発地、目的地)はFLIGHT_SEGMENTSに存在します。2 つのテーブルはbooking_idを共有しています。JOINデータインターフェイスは、そのキーでそれらをリンクし、EARNトランザクションのみをフィルタリングし、ルートごとに獲得した合計ポイントを示すフラットな結果を生成します。ダッシュボードにクエリを実行するアナリストには、1 つのテーブルが表示されます。結合ロジックはユーザーには見えません。合計 18 列を持つ flight_segments テーブルと points_ledger テーブル間の結合を示すデータインターフェイス構成。

    ルートごとのゴールドメンバーエンゲージメントの測定

    4番目の質問(各ルートを予約しているゴールド会員の数)は、フライトデータを会員データに接続する必要があります。FLIGHT_SEGMENTSは、ルートと予約の記録を保持します。MEMBER_PROFILEロイヤルティ階層を保持します。JOIN インターフェイスは、tier = GOLD のフィルターで 2 つのテーブルをリンクし、前四半期のルートごとの一意のメンバー数と合計予約数を返します。合計 18 列を持つ member_profile テーブルと flight_segments テーブル間の結合を示すデータインターフェイス構成。

    結果:トラベルパルスダッシュボード

    データスチュワードは、4 つのデータインターフェイスすべてを単一のデータ製品にパッケージ化します。スチュワードはそれをデータカタログに公開します。倉庫へのアクセス権を持たないロイヤルティアナリストは、製品を検出し、アクセス権を要求し、Platform Analytics で Travel Pulse ダッシュボードをビルドします。各ウィジェットは、ライブSnowflakeデータに対して1つのインターフェイスを直接クエリします。データはコピー、抽出、またはレプリケートされません。予約傾向、ルートランキング、ゴールドメンバーアナリティクスを示す Platform Analytics の Travel Pulse ダッシュボード。

    パターンの拡張:複数のソースからのデータの結合

    チームが後で提携航空会社からの予約データを含める必要がある場合は、UNION データインターフェイスを使用できます。パートナーデータは、FLIGHT_SEGMENTSと同じスキーマを持つ別のSnowflakeテーブルに保存されます。UNION データインターフェイスは、両方のテーブルを 1 つのクエリ可能なビューに積み重ねます。コンシューマーは 1 つの統一データセットをクエリします。既存のインターフェイスは変更されません。

    このパターンは、同じ種類のレコードが複数のシステムで追跡される場合に当てはまります。予約、注文、トランザクション、イベントなどのレコードは、地域、期間、または事業部門ごとに分割される場合があります。レポートの必要性は、それらすべてを一度にカバーすることです。