GA4の探索レポートとデータポータル(旧Googleデータスタジオ、旧Looker Studio)は、どちらも同じGA4データを参照しています。しかし正規表現の書き方や制約が異なるため、同じ意図で設定しても数値が一致しないケースが頻繁に発生します。本記事では、両ツールの正規表現ルールの違いと設定の落とし穴を実務者向けに整理します。カテゴリ設計パターンごとの実装対応表も掲載しているので、月次レポート作成にそのまま活用できます。
GA4とデータポータル(Looker Studio)の正規表現は同じではない
GA4の探索レポートとデータポータルは、いずれも正規表現エンジンとして「RE2」を使用しています。しかし、正規表現を「どこに・どのように適用するか」という仕組みに大きな差があります。
同じGA4のデータソースを参照していても、フィルタの設定方法・文字数制限・OR条件の扱い・使用できるディメンションが異なるため、設定を誤ると数値が合わなくなります。
以下の表で、両ツールの主な制約を比較します。
| 比較項目 | GA4探索フィルタ | GA4探索セグメント | データポータルフィルタ |
|---|---|---|---|
| 正規表現エンジン | RE2 | RE2 | RE2 |
| 1条件あたりの文字数上限 | 256文字 | 制限なし(実用上) | 制限なし(実用上) |
| フィルタ間のOR条件 | 不可 | 可能 | 可能(|で1本化) |
| 自然検索の絞り込み | セッションのデフォルトチャネルグループ等 | セグメント内ANDで設定 | フィルタコントロールで設定 |
| LPディメンション | ランディングページ+クエリ文字列 | ランディングページ+クエリ文字列 | ランディングページ(パスのみ) |
この表のポイントは2つです。GA4探索のフィルタは256文字制限があること、そしてフィルタ間でOR条件が使えないことです。複雑な条件はセグメントで実装する必要があります。
まず押さえる正規表現の基本ルール(両ツール共通)
RE2エンジンを使う両ツールで共通して適用される、正規表現の基本的な書き方を確認します。
^と$を必ず付ける
正規表現で「完全一致」させるには、先頭に^、末尾に$を付けます。付けないと「部分一致」になり、意図しないURLにもマッチしてしまいます。
たとえば/productだけで設定した場合、以下のようなURLにすべてマッチします。
/product
/product/shoes
/production-guide ← 意図しないURL
/old-product-list ← 意図しないURL
^/productと書いた場合でも/productから始まるすべてのパスにマッチするため、下位パスを含めるか否かを明示的に設計する必要があります。
パス末尾の書き方:($|/.*)と(/.*)?
あるパス配下のURLをまとめてマッチさせたい場合、よく使われる書き方が2種類あります。
($|/.*) → 「末尾で終わるか、/以降が続く」
(/.*)? → 「/以降が続くか、何もない」(?で省略可能にする)
どちらも実質的に同じ意味ですが、データポータルでは($|/.*)、GA4では(/.*)?のほうがシンプルに書けるケースが多いです。
末尾スラッシュの処理:/?
URLの末尾スラッシュは、サイトの設定によってあったりなかったりします。/?を付けることで両パターンに対応できます。
^/product(/.*)?$ → /product, /product/shoes にマッチ(末尾スラッシュなし)
^/product(/?|/.*)$ → /product, /product/, /product/shoes にマッチ
書き方パターン早見表
| 目的 | 正規表現パターン | マッチ例 |
|---|---|---|
| 完全一致(TOPのみ) | ^/$ |
/ |
| パスのみ(配下含まず) | ^/product/?$ |
/product、/product/ |
| パス配下すべて | ^/product(/.*)?$ |
/product、/product/shoes |
| パス配下(スラッシュ必須) | ^/product/.*$ |
/product/shoes(/product単体は除外) |
| OR条件(複数パス) | ^(/sale|/coupon)(/.*)?$ |
/sale、/coupon/line |
データポータル(Looker Studio)の正規表現ルール
データポータルでは、フィルタコントロールまたはグラフ・表の「フィルタ」設定で正規表現を使用します。
フィルタの設定方法(概念)
グラフや表にフィルタを設定する方法は大きく2つです。
ひとつは「フィルタコントロール」をページに配置して、閲覧者がインタラクティブに絞り込む方法です。もうひとつは、グラフ・表のプロパティ内「フィルタ」タブで固定フィルタを設定する方法です。
フィルタの条件には「正規表現に一致する」と「正規表現に一致しない」が選べます。包含(一致する)と除外(一致しない)を使い分けることで、柔軟な絞り込みが可能です。
長いOR条件を1本にまとめられる
データポータルの最大の利点は、文字数制限が実用上ないため、OR条件(|)を使って複数のパスを1本の正規表現にまとめられることです。
架空のECサイトexample-shop.jpの「商品カテゴリ」を例に示します。
^(/product($|/.*)|/brand($|/.*))$
このように書くことで、/product配下と/brand配下を1本のフィルタでまとめて集計できます。
包含フィルタと除外フィルタの使い分け
「店舗カテゴリ」のように、「含めたいパスはあるが、そのうち一部だけ別カテゴリに割り当てたい」という場合、包含フィルタと除外フィルタを組み合わせます。
包含フィルタ:^(/store(/.*)?|/search(/.*)?)$
除外フィルタ:^/store/special-price/region-a/?$
同一グラフに複数フィルタを設定した場合、AND条件として機能します。
注意:フィルタの適用漏れに気をつける
データポータルでよくあるミスが「フィルタをページレベルではなくグラフ・表単位で設定する必要がある」点の見落としです。
フィルタをひとつのグラフにしか設定していないのに、別のグラフで全LPのデータが表示されてしまっているケースがあります。カテゴリ別のLP詳細表を複数設置する場合は、それぞれのグラフにフィルタが適用されているか必ず確認してください。
GA4探索の正規表現ルール
GA4の探索レポートは「フィルタ」と「セグメント」の2箇所で正規表現が使えます。それぞれの役割と制約を理解した上で使い分けることが重要です。
フィルタ:256文字制限とOR不可
探索レポートのフィルタ(ディメンション・指標の絞り込み)では、1条件あたり256文字の上限があります。また、複数のフィルタ条件はAND条件でしか結合できず、OR条件はフィルタ単体では実現できません。
たとえば以下のような長いOR条件を1本にまとめようとすると、256文字を超える場合があります。
^(/sale/?|/coupon/line(/.*)?|/lp/winter(/.*)?|/lp/newmember(/.*)?|/lp/spring(/.*)?)$
このようなケースでは、セグメントに切り替えて設計します。
セグメント:OR条件・複雑条件の実装場所
GA4のセグメントはOR条件や複合条件を柔軟に設定できます。「キャンペーンカテゴリ」のように、複数のパスをOR条件でまとめ、さらに自然検索(Organic Search)に絞り込む場合はセグメントが適切です。
架空サイトexample-shop.jpの「キャンペーンカテゴリ」をセグメントで設定する例:
セグメント条件:
チャネル = Organic Search
AND
ランディングページ+クエリ文字列 が正規表現に一致
条件1(OR):^(/sale/?|/coupon/line(/.*)?)$
条件2(OR):^(/lp/winter(/.*)?|/lp/newmember(/.*)?)$
OR条件はセグメント内の「条件グループ」を複数追加することで実現します。
ディメンション差:「ランディングページ+クエリ文字列」の注意
GA4探索ではLPのディメンションとして「ランディングページ+クエリ文字列」が使われます。これはURLパスに加えてクエリパラメータ(?utm_source=...など)が付与された状態の文字列です。
データポータルでは「ランディングページ」(パスのみ)が使えるため、同じ正規表現を書いてもマッチする対象が異なります。クエリパラメータが多いサイトでは、この差が数値差異の原因になります。
GA4側でクエリパラメータを除外したい場合は、正規表現を以下のように調整します。
^/product(/[^?]*)?(\?.*)?$
ただしこの書き方は文字数が増えるため、256文字制限に注意が必要です。
カテゴリ設計パターン別|データポータルとGA4の実装対応表
実務でよく登場するカテゴリ設計パターンを5つに分類し、LookerとGA4それぞれの実装方法を整理します。
| パターン | カテゴリ例 | データポータル | GA4探索 |
|---|---|---|---|
| A:単一パス | TOPページ | ^/$ |
^/$(フィルタ) |
| B:複数パス・OR少 | 商品カテゴリ | ^(/product($|/.*)|/brand($|/.*))$ |
^(/product(/.*)?|/brand(/.*)?)$(フィルタ可) |
| C:OR多 | キャンペーン | 1本のOR regex | セグメント必須 |
| D:包含+除外 | 店舗カテゴリ | 包含フィルタ+除外フィルタ | セグメント+除外条件 |
| E:それ以外全部 | その他 | 除外フィルタ複数本AND | 256字で分割した除外フィルタ複数本AND |
パターンA:単一パス(TOP型)
TOPページだけを取得する場合はシンプルです。
Looker / GA4共通:^/$
パターンB:複数パス・OR少(商品型)
/productと/brand配下をまとめる場合の比較です。
データポータル:
^(/product($|/.*)|/brand($|/.*))$
GA4探索(フィルタ):
^(/product(/.*)?|/brand(/.*)?)$
どちらも機能的に同じですが、書き方が若干異なります。GA4の(/.*)?のほうが文字数を節約できます。
パターンC:OR多(キャンペーン型)
キャンペーンLPのように対象パスが多い場合、GA4のフィルタでは256文字を超えることがあります。
データポータル(1本で書ける):
^(/sale/?|/coupon/line(/.*)?|/lp/winter(/.*)?|/lp/newmember(/.*)?)$
GA4:フィルタでは実装困難 → セグメントで条件を分割して実装
パターンD:包含+除外(店舗型)
店舗関連ページを取得しつつ、一部のURLを別カテゴリに割り当てる場合です。
データポータル:
包含:^(/store(/.*)?|/search(/.*)?)$
除外:^/store/special-price/region-a/?$
GA4(セグメント):
包含条件:^(/store(/.*)?|/search(/.*)?)$
除外条件:^/store/special-price/region-a/?$
パターンE:その他(除外方式)
「どのカテゴリにも該当しないURL」を集める場合、他カテゴリのURLをすべて除外する方式になります。
データポータル:
除外フィルタ①:^(/product($|/.*)|/brand($|/.*))$
除外フィルタ②:^(/sale/?|/coupon(/.*)?)$
除外フィルタ③:^(/store(/.*)?|/search(/.*)?)$
※フィルタ間はANDで結合
GA4(フィルタ):
除外フィルタ①:^(/product(/.*)?)$(256字以内に分割)
除外フィルタ②:^(/brand(/.*)?)$
除外フィルタ③:^(/sale/?|/coupon(/.*)?)$
※各フィルタが256字を超えないよう分割
データポータルとGA4で数値がズレる典型原因5つ
原因1:正規表現の表記差
同じ意図でも書き方が違うと、マッチするURLが変わります。代表的な例として($|/.*)と(/.*)?の違いがありますが、実際には同じ意味です。一方で^/service/(末尾スラッシュあり)と^/service(スラッシュなし)では、マッチ範囲が変わります。
原因2:フィルタ未適用
データポータルでLP詳細表を複数配置している場合、各グラフにフィルタが適用されていないと全LPが集計されてしまいます。フィルタは「ページ全体」ではなく「グラフ単位」で管理されている点に注意が必要です。
原因3:ディメンション差(LP vs LP+クエリ)
前述のとおり、データポータルとGA4探索では使用できるLPディメンションが異なります。クエリパラメータが多いサイトでは、この差が顕著な数値差異を生みます。
原因4:自然検索の二重定義
チャネル絞り込み(Organic Search)の設定をフィルタとセグメントの両方に重複して設定してしまうと、意図しない集計になることがあります。自然検索の絞り込みはどこで行うか、設計段階で統一してください。
原因5:指標定義の違い
正規表現以外の原因として、指標そのものの定義差があります。データポータルでGA4の「セッション」を使っているつもりが、別の指標を参照していたり、集計期間の設定がグラフごとに異なっていたりするケースがあります。数値がズレた場合は正規表現だけでなく指標名も確認してください。
設定後の検証チェックリスト
カテゴリ設計が完成したら、以下のチェックリストで設定の正確性を確認します。
合計値の突合
- カテゴリ1〜Nのセッション合計が、自然検索合計のおおむね97〜100%に収まっているか
- 合計が大幅に超えている場合、どこかで重複カウントが発生していないか確認する
- 合計が大幅に少ない場合、未分類のURLがないか確認する
正規表現の動作確認
- 各カテゴリの代表URLをRE2テスター(例:regex101.comでRE2選択)で手動確認したか
- 末尾スラッシュあり・なしの両パターンでテストしたか
- クエリパラメータ付きのURLでもテストしたか(GA4のみ)
フィルタ適用確認(データポータル)
- LP詳細表のすべてのグラフにフィルタが適用されているか
- 月次合計とLP別内訳でフィルタ適用範囲が一致しているか
- 包含フィルタと除外フィルタの優先順位は意図通りか
GA4探索の確認
- 256文字を超えるフィルタがないか確認したか
- セグメントを使っている場合、OR条件が正しく設定されているか
- ディメンションが「ランディングページ+クエリ文字列」になっているか確認したか
よくある質問(FAQ)
Q1:データポータルの正規表現はGA4と同じ文字列をそのまま使える?
同じRE2エンジンなので、文字列自体は基本的に流用できます。ただし、GA4の256文字制限を超えるものはLookerから移植できません。また、GA4で使った(/.*)?をLookerでそのまま使うことは可能ですが、($|/.*)に書き直してもほぼ同じ動作をします。どちらを標準にするかはチームで統一することをおすすめします。
Q2:256文字を超える場合はどうする?
GA4探索のフィルタを使う場合、256文字を超えるOR条件はセグメントに切り替えます。どうしてもフィルタで実装したい場合は、OR条件を2つのフィルタに分割してAND結合することで対応できますが、この場合は「両方の条件に一致するURL」ではなく「それぞれ別のフィルタで絞り込まれた集合のAND」になるため、意図した絞り込みにならない場合があります。セグメントを使うのが最も確実です。
Q3:除外フィルタと包含フィルタ、どちらを使うべき?
基本的には「含めたいURLが明確なら包含、含めたくないURLが少ないなら除外」という考え方で選びます。「その他」カテゴリのように「特定カテゴリ以外すべて」を取得する場合は除外フィルタが向いています。包含フィルタだけでは定義しきれない複雑なカテゴリでは両方を組み合わせます。
Q4:データポータルで正規表現エラーが出る
RE2で使えない構文(先読み(?=...)、後読み(?<=...)、\dなどの一部の省略形)を使用した場合にエラーが出ます。RE2はPCRE(Perlの正規表現)と一部の構文が非互換です。エラーが出た場合はregex101.comのRE2モードで構文を確認してください。また、括弧の対応が合っていない場合もエラーになります。
Q5:GA4探索とデータポータル、どちらを正とすべき?
どちらが「正」ということはなく、設計と設定が正しければ近い数値になるはずです。ただし、ディメンション差(LPのパスのみ vs パス+クエリ)により完全一致はしません。月次レポートの管理ツールとしてどちらをメインにするかを決め、もう一方はクロスチェック用として使う運用が実務的です。データポータルは長いOR条件を1本で管理できるため、カテゴリ定義の「ソース」として扱いやすい面があります。
まとめ
本記事で解説した内容を整理します。
データポータル(Looker Studio)の設計方針
- 文字数制限がないため、長いOR条件を1本の正規表現にまとめて管理できる
- 包含フィルタ・除外フィルタを組み合わせることで柔軟なカテゴリ分けが可能
- フィルタはグラフ単位の設定のため、適用漏れに注意する
GA4探索の設計方針
- フィルタは1条件256文字制限、フィルタ間OR不可
- OR条件や複雑な条件はセグメントで実装する
- ディメンションが「ランディングページ+クエリ文字列」のため、LookerのLPディメンションと動作が異なる
設定後の検証ポイント
| 確認項目 | 目安 |
|---|---|
| カテゴリ合計 vs 自然検索合計 | 差異±1〜3%以内 |
| 代表URLの手動マッチ確認 | 全カテゴリの代表1〜3件 |
| フィルタ適用範囲の一致 | 月次合計とLP別内訳が一致 |
両ツールで表記を揃え、合計突合で検証する習慣をつけることが、安定したレポート運用への近道です。正規表現の差分を理解した上で設計・検証することで、ツール間の数値差異を最小限に抑えられます。
コメント