INFORMATION_SCHEMAでGA4のネストされたスキーマを効率的に探索する

はじめに：GA4のネストが深くて、どこに何があるか分からない

GA4のBigQueryエクスポートを使い始めたとき、最初につまずくのが「列の場所が分からない」という問題です。

通常のテーブルなら、列名はフラットに並んでいます。order_id、amount、created_at のように、一覧を見ればすぐに目的の列が見つかります。ところがGA4のイベントテーブルは違います。event_params や items のように、列の中にさらに構造（STRUCT）や配列（ARRAY）が入れ子になっていて、ひとつの列の中に複数の値がぶら下がっているのです。

たとえば「ページのURLはどこにあるのか」「商品名はどの列に入っているのか」を調べようとすると、event_params という配列の中を展開して、その中の key と value を見て、さらに value の中の string_value を取り出す、という多段階の構造になっています。最初は、このネストの全体像がまったくつかめません。

公式ドキュメントを見れば構造は書いてありますが、自分のテーブルに実際にどんなパスが存在するのかを、手元で素早く確認できると探索がぐっと楽になります。とくにカスタムイベントやカスタムパラメータを設定していると、自分の環境固有のフィールドが増えていくため、ドキュメントだけでは追いきれない部分が出てきます。

また、クエリを書いている途中で「このフィールド名で合っているのか」「型は何だったか」と手が止まることも少なくありません。そのたびにドキュメントを開いて確認するのは地味に時間を食います。手元のテーブルそのものに問い合わせて答えを得られれば、こうした往復を減らせます。

この記事では、INFORMATION_SCHEMA を使って、GA4テーブルのネストされた列パスを一覧で取り出す方法を紹介します。商品名やページURLがどのパスにあるのかを、SQLだけで機械的に調べられるようになります。対象としているのは、GA4のBigQueryエクスポートを設定済みで、これからデータを本格的に触り始める段階の方です。

この記事はあくまで「フィールドを見つける」段階を扱うものです。見つけたパスを実際のクエリでどう展開して使うかは、姉妹記事のBigQueryのSTRUCT・ARRAY型を活用してGA4データを効率的にモデリングするで扱っています。UNNESTでの展開方法まで知りたい場合は、そちらもあわせてご覧ください。

ネストした列パスを一覧する

BigQueryには、テーブルの構造を調べるためのメタデータビューがいくつか用意されています。フラットな列の一覧であれば INFORMATION_SCHEMA.COLUMNS で足りますが、GA4のように入れ子の構造を持つテーブルでは、ネストの中まで掘り下げて列を見たいことがあります。

そのときに役立つのが INFORMATION_SCHEMA.COLUMN_FIELD_PATHS です。このビューは、STRUCTやARRAYの内側にある「フィールドのパス」までを1行ずつ展開して返してくれます。つまり、event_params.key や event_params.value.string_value のような深い場所にあるフィールドも、それぞれ独立した行として一覧できるのです。

まずは、特定のテーブルに含まれる列パスを丸ごと取り出してみます。

SELECT
  column_name,
  field_path,
  data_type
FROM
  `your_project.analytics_123456789`.INFORMATION_SCHEMA.COLUMN_FIELD_PATHS
WHERE
  table_name = 'events_20260830'
ORDER BY
  field_path;

your_project は自分のプロジェクトID、analytics_123456789 はGA4のエクスポート先データセット、events_20260830 は調べたい日付のテーブル名に置き換えてください。

このクエリを実行すると、column_name（トップレベルの列名）、field_path（ネストを含む完全なパス）、data_type（そのフィールドの型）が並びます。field_path を見れば、入れ子の中身がドット区切りで表現されているのが分かります。

ポイントは、ORDER BY field_path で並べ替えていることです。こうすると、同じ親を持つフィールドがまとまって表示されるため、どの列の下にどんな子フィールドがぶら下がっているのかを目で追いやすくなります。

特定の構造だけに絞り込む

列パスの全件は数が多いので、目的の構造だけを見たいときは WHERE で絞り込みます。たとえば event_params の中身だけを確認したい場合は、次のようにします。

SELECT
  field_path,
  data_type
FROM
  `your_project.analytics_123456789`.INFORMATION_SCHEMA.COLUMN_FIELD_PATHS
WHERE
  table_name = 'events_20260830'
  AND column_name = 'event_params'
ORDER BY
  field_path;

column_name = 'event_params' と条件を付けることで、event_params 配下のフィールドだけが残ります。商品関連を見たいなら column_name = 'items' に変えるだけです。調べたい構造を切り替えながら、必要な部分だけを順番に確認していけます。

トップレベルの列名だけをざっと知りたいときは、ネストを含まない INFORMATION_SCHEMA.COLUMNS を見るほうが手早いこともあります。フラットな列の一覧で十分なのか、入れ子の中まで見たいのかで使い分けると効率的です。GA4のように構造が深いテーブルでは、最初に COLUMN_FIELD_PATHS で全体像をつかみ、そのあと必要に応じて絞り込んでいく流れがしっくりきます。

event_params と items の構造を把握する

GA4のテーブルでとくに頻繁に触ることになるのが、event_params と items の2つです。先ほどのクエリで取り出せるパスを手がかりに、それぞれの構造を整理しておきます。

event_params は、イベントに付随するパラメータを格納する配列です。1つのイベントに複数のパラメータがぶら下がるため、配列になっています。各要素は key と value のペアを持ち、value の中はさらに型ごとに分かれています。COLUMN_FIELD_PATHS で見ると、おおむね次のようなパスが並びます。

event_params.key … パラメータ名（page_location や page_title など）
event_params.value.string_value … 文字列で入る値
event_params.value.int_value … 整数で入る値
event_params.value.float_value … 浮動小数で入る値
event_params.value.double_value … 倍精度で入る値

つまり、ページURLを取り出したいなら「key が page_location の要素を探し、その value.string_value を読む」という流れになります。値の型がパラメータごとに違うため、どの *_value に入っているかを把握しておくことが大切です。文字列なら string_value、数値なら int_value というように、対象に応じて読む先が変わります。

items は、eコマースの計測で使う商品情報の配列です。1回の購入に複数の商品が含まれることがあるため、こちらも配列になっています。COLUMN_FIELD_PATHS で見ると、items.item_id、items.item_name、items.price、items.quantity といった、商品にひもづくフィールドが並びます。event_params のような key と value のペア構造ではなく、フィールド名がそのまま意味を持っている点が違いです。

この2つの違いを押さえておくと、データを読み出すSQLを書くときに迷いません。event_params は「キーで目的のパラメータを探す」、items は「フィールド名を直接指定する」と覚えておくとよいでしょう。

なお、同じ「配列の中の構造」でも、event_params のようにキーと値のペアで汎用的に値を持つ形と、items のようにフィールド名そのものが意味を持つ形の2パターンがあることが、COLUMN_FIELD_PATHS の出力を見ると一目で分かります。パスの並びを眺めるだけで、その列が「キー引き」なのか「フィールド直指定」なのかを判断できるようになると、初見の列に出会っても落ち着いて対処できます。

スキーマ探索を効率化する使い方

COLUMN_FIELD_PATHS は、単に構造を眺めるだけでなく、日々の探索を速くするための道具としても使えます。いくつか実践的な使い方を紹介します。

キーワードでフィールドを検索する

「URLっぽいフィールドはどこだろう」と当たりを付けたいときは、field_path に対して部分一致で検索すると便利です。

SELECT
  table_name,
  field_path,
  data_type
FROM
  `your_project.analytics_123456789`.INFORMATION_SCHEMA.COLUMN_FIELD_PATHS
WHERE
  table_name = 'events_20260830'
  AND LOWER(field_path) LIKE '%page%'
ORDER BY
  field_path;

LIKE '%page%' のように探したい語を入れることで、ページ関連のフィールドだけを抜き出せます。商品なら %item%、ユーザー関連なら %user% といった具合に、見当を付けたキーワードで素早く絞り込めます。列名を覚えていなくても、雰囲気で探せるのが利点です。

検索は LOWER(field_path) で小文字に揃えてから行っているため、大文字小文字の違いを気にせず探せます。GA4のフィールド名はおおむね小文字ですが、自分で追加したカスタムパラメータなどで表記が混在している場合に効いてきます。field_path だけでなく column_name 側にも同じ要領で検索をかければ、トップレベルの列から絞り込むこともできます。

型から目的のフィールドを探す

逆に「数値で入っているフィールドを一通り見たい」というときは、data_type で絞り込めます。集計に使えそうな列を洗い出すのに役立ちます。データ型の表記はバージョンや環境によって変わることがあるため、まずは絞り込みなしで一覧を眺め、実際の表記を確認してから条件を付けると確実です。

たとえば購入金額や数量のように合計や平均を取りたい値は、たいてい数値型として並びます。先に型で当たりを付けておくと、集計クエリを書くときに「この列は文字列だった」と後から気づいて書き直す、という手戻りを減らせます。GA4では金額系のパラメータが思わぬ型で入っていることもあるので、事前確認の価値は大きいです。

スキーマの変化に気づく

GA4のエクスポートは、カスタムイベントやカスタムパラメータを追加すると、テーブルに含まれるパスが増えていきます。COLUMN_FIELD_PATHS を別の日付のテーブルと比べれば、いつの間にか増えた（あるいは消えた）フィールドに気づけます。「先月までは取れていた値が見当たらない」といったときの調査の入り口として使えます。

たとえば、過去のある日のテーブルと最新のテーブルのそれぞれで field_path の一覧を取り出し、差分を比べるという使い方が考えられます。新しいパラメータを計測に追加したつもりが、実は名前を間違えていた、といったミスも、こうして並べてみると見つけやすくなります。スキーマの履歴を残しておくほどの大げさな仕組みを作らなくても、必要なときに一覧を出して見比べるだけで十分役に立ちます。

補足として、event_params のパラメータは「テーブルの列」ではなく「配列の中身の値」です。そのため、あるパラメータが特定の日に1件も送られていなければ、構造上のパスは存在しても、実データとしては空になることがあります。パスの一覧はあくまで「器」を示すものだと考え、実際に値が入っているかは別途データを確認するのが安全です。

このように、COLUMN_FIELD_PATHS を起点にすれば、ドキュメントと実テーブルを往復する手間を減らし、自分の環境に即した形でスキーマを探索できます。GA4のデータをBigQueryで扱うなら、最初に一度この一覧を出しておくと、その後の作業がずっと楽になります。

なお、ネストされた配列を実際に展開して値を取り出す書き方そのものについては、BigQueryでGA4のSTRUCT・ARRAYをモデリングするで詳しく扱っています。また、探索で見つけたパスを使った実践例として、GA4×BigQueryでSearch Consoleと結合してオーガニック分析するもあわせて参考にしてください。

⚠️ メタデータビューの名前や、各ビューが返す列・対応範囲は、将来変更される可能性があります。INFORMATION_SCHEMA.COLUMN_FIELD_PATHS の利用にあたっては、必ず最新の公式ドキュメントで正式なビュー名と仕様を確認してから本番のクエリに組み込んでください。

まとめ

GA4のBigQueryエクスポートは入れ子構造が深く、最初は列の場所をつかむだけでも苦労します。INFORMATION_SCHEMA.COLUMN_FIELD_PATHS を使えば、event_params や items の内側にあるフィールドまでをパスとして一覧でき、スキーマの全体像を機械的に把握できます。

要点を整理すると、次のとおりです。

COLUMN_FIELD_PATHS はネストの中のフィールドを1行ずつ展開して返す
column_name で構造を、field_path のキーワード検索で目的のフィールドを絞り込める
event_params は「キーで探す」、items は「フィールド名で直接指定する」と構造が違う
パスの一覧は「器」を示すもので、実データの有無は別途確認する

最初にこの一覧を出しておくだけで、その後のクエリ作成や調査が一気に進めやすくなります。GA4のデータ探索でつまずいたら、まずはスキーマを覗いてみるところから始めてみてください。

自社のGA4テーブルにどんなフィールドがあるか把握できていない、あるいはスキーマ探索からGA4×BigQueryのデータ基盤構築まで一通り相談したいという場合は、お問い合わせからご連絡ください。