Places Insights のデータとクエリについて

Places Insights のデータ

Places Insights は、BigQuery で完全なデータセットとサンプル データセットを提供します。

サンプル データセットは、Places Insights を試して、完全なデータセットを購入する前にプロダクトのユーザビリティと価値を評価できるようにすることを目的としています。サンプル データセットには、都市自体のデータのみが含まれています。周辺の大都市圏のデータは含まれません。

サンプル リスティングには、サポートされている各国の主要都市のデータが含まれています。

  • アムステルダム（オランダ）
  • アンカラ（TR）
  • アレキパ（PE）
  • アテネ（GR）
  • バート ガスタイン（オーストリア）
  • ベルリン（ドイツ）
  • ブルノ（チェコ）
  • ブリュッセル（ベルギー）
  • ブカレスト（RO）
  • ブエノスアイレス（AR）
  • 釜山（韓国）
  • カイロ（EG）
  • チェンマイ（タイ）
  • コペンハーゲン（DK）
  • コーク（IE）
  • デブレツェン（ハンガリー）
  • ハノイ（VN）
  • ヘルシンキ（フィンランド）
  • 香港（HK）
  • ジャカルタ（ID）
  • ジェッダ（SA）
  • ヨハネスブルグ（南アフリカ）
  • クアラルンプール（マレーシア）
  • リスボン（PT）
  • ロンドン（GB）
  • ルサイル（カタール）
  • マドリード（スペイン）
  • マニラ（フィリピン）
  • メデジン（CO）
  • メキシコシティ（MX）
  • ムンバイ（IN）
  • ニューヨーク市（米国）
  • オスロ（NO）
  • パリ（フランス）
  • プロヴディフ（BG）
  • リファー（BH）
  • ローマ（IT）
  • サンティアゴ（CL）
  • サンパウロ（ブラジル）
  • シャールジャ（AE）
  • シンガポール（SG）
  • ストックホルム（SE）
  • シドニー（オーストラリア）
  • 台北（TW）
  • テルアビブ（IL）
  • 東京（日本）
  • トロント（カナダ）
  • ワルシャワ（PL）
  • ウェリントン（ニュージーランド）
  • チューリッヒ（CH）

完全なデータセットには、サポートされている各国のデータが含まれており、購入する必要があります。Places Insights への登録をご希望の場合は、リクエスト フォームにご記入ください。Places Insights データセットへのアクセスをリクエストする必要があるのは、データ サブスクライバーのみです。BigQuery プロジェクトでサブスクリプションが有効になると、そのプロジェクトにアクセスできるユーザーは、Places Insights データをクエリできるようになります。

各国のデータセットには独自のリスティングがあり、個別にサブスクライブする必要があります。リスティングのサブスクリプションの詳細については、Places Insights を設定するをご覧ください。

データセット スキーマ

各国の Places データセット スキーマは、次の 2 つの部分で構成されています。

たとえば、スペイン（ES）のデータセットを操作する場合は、コアスキーマと ES 固有のスキーマの両方を参照します。

brands データセットのスキーマでは、次の 3 つのフィールドが定義されています。

  • id: ブランド ID。
  • name: ブランドの名前（「Hertz」、「Chase」など）。
  • category: ブランドの上位カテゴリ（「ガソリン スタンド」、「飲食店」、「宿泊施設」など）。

Places Insights データをクエリする

Places Insights では、次の 2 つの方法でデータセットをクエリできます。

  • SQL を使用してデータセットを直接クエリする: データセット テーブルに対して標準の BigQuery SQL クエリを実行します。これにより、複雑なフィルタリング、独自のデータとの結合、カスタム分析、COUNT 以外の追加の集計関数（AVG、SUM、GROUP BY など）のサポートを最も柔軟に行うことができます。ドキュメントをご覧ください。
  • Places Count 関数を使用してデータセットをクエリする: Places Count 関数は、BigQuery で直接実行され、一般的なデータ取得タスクを簡素化する、事前定義された最適化された SQL クエリです。プレイス ID を返して個々の場所の詳細を検索するなど、より詳細な分析情報を提供します。ドキュメントをご覧ください。

直接クエリ

データを直接クエリすると、集計しきい値が適用されます。結果が返されるのは、クエリで 5 つ以上の場所が集計された場合のみです。たとえば、検索条件の結果が 0、1、2、3、4 のいずれかの場合、その結果はレスポンスから除外されます。たとえば、特定のエリアのレストランの合計数をクエリすると、合計数が 5 以上の場合にのみレスポンスが返されます。それ以外の場合、レスポンスは返されません。

Places Count 関数のクエリ

Places Count 関数は、プレイス ID のリストを返すことができます。このリストは、Places API や Places UI Kit などの他の GMP プロダクトを使用して個々の場所の情報を検索するために使用できます。

Places Count 関数では、集計しきい値は適用されませんが、代わりに 40.0 m × 40.0 m（1, 600 m2）の最小検索エリアが適用されます。つまり、検索クエリが最小検索エリアよりも大きい限り、クエリに一致する場所が 0 件の場合でも、常に結果が返されます。

データを直接クエリするタイミングと関数を使用するタイミング

低い結果カウントが不要な場合、AVG、SUM、COUNTIF などのカウント以外の分析情報を取得する場合、またはデータセットの結合などのより複雑なクエリを実行する必要がある場合は、データを直接クエリします。

結果が少ないかゼロかどうかを確認する必要がある場合や、場所の名前や住所などの個々の場所情報を取得する必要がある場合は、関数を使用してクエリを実行します。

次の表は、直接クエリと Places Count 関数の違いを詳しく比較したものです。

Places Count 関数 直接データセット クエリ
メリット
  • 他の API のクエリに使用できるプレイス ID を返します。
  • 任意の数を返すことができます。
  • パフォーマンスと低い処理コストを重視して最適化されています。
  • 使いやすいこのアプリでは、複雑なクエリを記述する必要はありません。
  • 入力パラメータを検証し、エラーを返します。これにより、使用とデバッグが容易になります。
  • 高度なフィルタリングや結合などの複雑なクエリが可能。
  • 最小検索領域を適用しません。
  • COUNT 以外の集計関数（AVG、SUM、GROUP BY など）をサポートします。
インターフェース COUNT 分析情報を生成する 4 つの事前定義 SQL 関数: 単一カウント、タイプごとのカウント、地域ごとのカウント、H3 セルごとのカウント。JSON_OBJECT は関数に引数を渡します。 独自の SQL を記述して、COUNT、COUNT_IF、SUM、AVG. などの集計関数を実行します。JOIN、GROUP BY、WHERE などを使用して、追加の分析情報を生成できます。
制限事項 40.0 m × 40.0 m（1,600 m2）の最小検索エリアを適用します。最小検索エリアが満たされている限り、集計数が 5 未満であっても、関数は結果を返します。 カウントが 5 未満の結果は結果から除外されます（つまり、行が除外されます）。
サポート属性フィルタ Places Count 関数のフィルタ パラメータは、以下を除き、直接クエリの属性フィルタと同じものをサポートしています。
  • 場所: id
  • 住所コンポーネント
 完全なスキーマがサポートされています。