Looker Studioでサーチコンソールと日付補正したGA4のデータを統合してランディングページ×日付のテーブルを作る

GA4とサーチコンソールのデータ統合をする際，日付を太平洋夏時間にそろえることは最低限実地すべきであるという考えに基づき，ランディングページと日付を用いた統合方法などを紹介します．この方法は，Search Console とアナリティクスのデータの不一致の原因の一つである「タイムゾーンが異なる」問題に対する補正案です．

1．はじめに

本記事のようなコンテンツや動画解説では，Looker Studioなどのツールを使ったデータ統合の例として，Google Analytics 4（以下，「GA4」と表記）とGoogleサーチコンソール（以下，単に「サーチコンソール」と表記）のデータソースが取り上げられることが多いです．しかし，それらの解説において，日付のデータに関する重要な注意点がほとんど触れられていないと筆者は感じています．

その注意点とは，日本時間とサーチコンソールのタイムゾーン（太平洋夏時間）の間には16時間の時差があることです．したがって，タイムゾーンを日本時間に設定しているGA4の「日付」データと，サーチコンソールの「日付」データは，必ずしも一致しません．詳細については，記事「日本と時差が16時間あるGoogleサーチコンソールのタイムゾーンの年月日のデータをGA4に記録させる方法」や「Google AnalyticsとSearch Consoleのタイムゾーンを認識してデータポータルを活用する」を参照してください．

本記事では，この日付データの補正を行い，Looker StudioでサーチコンソールとGA4のデータを統合する手順を紹介します．ここで紹介する補正とは，GA4の「日時（YYYMMDDHH）」データから太平洋夏時間（PDT）の日付データを作成し，その日付を基にデータ統合を行う手法です．

サーチコンソールとGA4のデータを統合する目的は，両方のランディングページデータに紐づく指標を一つのテーブルにまとめることです．そこで，共通ディメンションとしてランディングページと日付（太平洋夏時間）を持つ「ランディングページ×日付のテーブル」の作成を目指します．このテーブルでは，「ランディングページ×日付」の組み合わせごとに，サーチコンソールのインプレッション数やクリック数と，GA4のセッション数やキーイベント数などの指標が一行に並びます．（これは，多くのユーザーがランディングページ単位で両者の指標を比較したいという要望に応えるものだと思います）．

なお，データ統合の概念，Looker Studioの統合機能やその用語（結合演算子，左外部結合，結合条件など）の説明については，本記事では割愛いたします．これらの基本的な情報については，既に優れた記事が多数存在するため，そちらをご参照ください（本記事は手順解説にも注力したため，これらを省いても詳細で長めの構成となっています）．

例えば，Google公式説明は下記のリンク先で確認できます．

Google：Looker Studio での統合の仕組み

https://cloud.google.com/looker/docs/studio/how-blends-work-in-looker-studio?hl=ja

その他にも，アユダンテ株式会社さんの下記の記事も参考になります．

アユダンテ：Looker Studio 統合の結合はどれを使うのが正解かを解説

https://ayudante.jp/column/2023-09-13/17-00/

アユダンテ：Looker Studioの統合が思った通りにならない。の原因と対処を解説

https://ayudante.jp/column/2023-12-27/15-00/

なお，記事「日本と時差が16時間あるGoogleサーチコンソールのタイムゾーンの年月日のデータをGA4に記録させる方法」で触れたように，日本時間設定のGA4とサーチコンソールのタイムゾーンが異なっていることを認識した上で活用する分には，日付補正をしないでそれらをデータ統合してもいいと思います．そもそも，サーチコンソールとGA4のデータには不一致となる要因が多々あるため，長くとった期間単位でデータを見る場合は，16時間の時差も誤差として処理する方が現実的かもしれません．しかし，本記事が目的とするように「日付」単位でデータを詳細に見たい場合は，16時間の時差を誤差として無視することはできないでしょう．

2．データソースの準備と確認

Looker Studioで「空のレポート」のテンプレートを選択し，データを追加します．既に登録済みのデータソースがあればそれを使用できますが，本例では「データに接続」で新たに選ぶことにします．

まず，Googleサーチコンソールでデータを追加します．一覧から「Search Console」のタイルを選択（図1赤枠内参照）し，アカウントと紐付いているサイトの一覧から該当するデータを選びます．今回の目標は，特定のWebサイトのサーチコンソールとGA4のデータソースを統合し，「ランディングページ×日付のテーブル」を作成することです．そのため，サーチコンソールの「サイト」は目的のサイトを選択し，「表」は「URLのインプレッション」を，「検索タイプ」は「web」を選択します（図2参照）．

Search Consoleの各サイトのデータには「サイトのインプレッション」と「URLのインプレッション」の2種類がありますが，サイト全体でなく各ランディングページに関するデータを使用したいので， 「表」では「URLのインプレッション」を選択します．

図1．Looker Studioでサーチコンソールのデータに接続．

図2．データのレポートへの追加で，該当サイトの表「URLのインプレッション」を選び，「検索タイプ」では「web」を選ぶ．

これは任意ですが，追加したサーチコンソールのデータが「URLのインプレッション」であることが分かりやすいように，名前を変更しておくことを推奨します．Looker Studioの編集画面で「リソース > 追加済みのデータソースの管理」を選択（図3赤枠内参照）し，一覧にあるデータの「アクション > 編集」をクリック（図4赤枠内参照）し，名前を編集します．本例では「SC index-lab.jp URL-impression-date」としました（図5赤枠内参照）．

図3．Looker Studioの編集画面で「リソース > 追加済みのデータソースの管理」を選択．

図4．データソースの一覧にあるサーチコンソールのデータの「アクション > 編集」をクリック．

図5．編集画面でデータソース名を「SC index-lab.jp URL-impression-date」と変更．

次に，該当するGA4のデータを同様に追加します．本例ではGA4のデータの名前は「GA4 index-lab.jp_202510」としました（図6参照）．

図6．追加したデータソース．

サーチコンソールのデータと対応させるGA4のデータは，Google自然検索の流入に限定します．GA4には複数の「参照元 / メディア」がありますが，今回は「セッションの参照元 / メディア」を使用します．もし，GA4の各「参照元 / メディア」がどのようなものかを知りたい場合は以下のなどを参照してください．

[GA4] トラフィック ソースのディメンションのスコープ

https://support.google.com/analytics/answer/11080067?hl=ja

アユダンテ：[GA4]レポートを作るときに選択する「参照元/メディア」はどれ？

https://ayudante.jp/column/2024-06-28/15-00/

そこで，Google自然検索に該当するフィルタを作成します．Looker Studioの編集画面で「リソース > フィルタの管理」（図3青枠内参照）からフィルタを開き，「＋フィルタを追加」をクリック（図7赤枠内参照）して「フィルタの作成」を開きます（図8参照）．データソースにGA4（本例：「GA4 index-lab.jp_202510」）を選択し，「一致条件」で項目を「セッションの参照元 / メディア」，条件を「次に等しい（=）」，Any Valueを「google / organic」に設定し，フィルタ名を「Google自然検索」として保存します（図9参照）．

図7．Looker Studioのフィルタ管理画面．

図8．Looker Studioのフィルタ作成画面．

図9．フィルタ「Google自然検索」を作成．

データの準備が完了したので，次にGA4とサーチコンソールそれぞれで，ランディングページを第1ディメンション（主軸）とする簡単なテーブルを作成して確認します．

「挿入 > テーブル（図43参照）」でテーブルを挿入し，そのテーブルのデータソースにGA4（本例：「GA4 index-lab.jp_202510」）を選択して，ディメンション「ランディング ページ + クエリ文字列，日時（YYYMMDDHH），日付，セッションの参照元 / メディア」，指標「セッション，キーイベント」のテーブルを作成します（図10参照）．

図10．GA4の「ランディング ページ + クエリ文字列」を第1ディメンション（主軸）とするテーブルを作成．

図10のテーブルの「セッションの参照元 / メディア」の列から分かる通り，このままではGoogle自然検索以外の流入も含まれています．そのため，先ほど作成したフィルタ「Google自然検索」をこのテーブルに追加します（図11赤枠内参照）．これにより，「セッションの参照元 / メディア」の値が「google / organic」のみになったことが確認できます．

図11．フィルタ「Google自然検索」をテーブルに追加．

上記テーブルを「編集 > コピー」し，「編集 > 貼り付け」で複製を作成します（図12参照）．複製したテーブルをコピー元の直下に移動させ，ディメンションを「ランディング ページ + クエリ文字列」から「ランディング ページ」に変更します（図13参照）．

図12．Looker Studioでテーブルの「編集 > コピー」と「編集 > 貼り付け」を実行．

図13．複製したテーブルを使ってGA4の「ランディング ページ」を第1ディメンション（主軸）とするテーブルを作成．

GA4で2つのテーブルを作成したのは，「ランディング ページ + クエリ文字列」と「ランディング ページ」の値がどのように表示されるか（表記の違い）を確認するためです．

本サイトはWordPressで作られていますが，例えば本サイトの記事「生成AIサービスからのアクセスとGA4の計測」は，「ランディング ページ + クエリ文字列」の場合は「/tools/0217183932/ai-search-access-01/」と表示され，「ランディング ページ」の場合は「/tools/0217183932/ai-search-access-01」と表示されています．つまり，共にパス表記なのですが，「ランディング ページ + クエリ文字列」の場合は末尾に「/」がある表記，「ランディング ページ」の場合は末尾に「/」がない表記となっています．この表記の違いは，サイトの環境によって異なります．例えば，「ランディング ページ + クエリ文字列」と「ランディング ページ」の両方とも末尾に「/」がない表記になるGA4データも確認しています．

データ統合を行う上で，この表記の違いが重要になります．ご自身の環境でどのように表示されるかを把握しておいてください．

次に，データソースにサーチコンソール（本例：「SC index-lab.jp URL-impression-date」）を選択し，ディメンション「Landing Page，Date」，指標「Impressions，Url Clicks，URL CTR」のテーブルを，上記の2つのGA4のデータソースのテーブルの下に作成します（図14参照）．

最後に「コントロールを追加」から「期間指定」を選択し（図15赤枠内参照），データ期間を設定できるボタンを追加しておきます．

図14．サーチコンソールの「Landing Page」を第1ディメンション（主軸）とするテーブルを作成．

図15．「コントロールを追加」から「期間指定」のコントロールボタンを追加．

＜補足＞ Google自然検索の流入のみが対象の場合，通常，ランディングページにクエリ文字（「?」記号で始まるパラメータ）は付与されないため，「ランディング ページ」だけを気にすればいいかもしれません．しかし，本例（本サイト）のような表記揺れがある場合もありますので，ご自分の環境で「ランディング ページ + クエリ文字列」と「ランディング ページ」の表記などに違いがあるかを，事前に確認しておくことをお勧めします．後述するように，サーチコンソールの「Landing Page」のデータとの兼ね合いを考慮し，本例では「ランディング ページ + クエリ文字列」を使用します．

3．GA4のデータソースにサーチコンソールのタイムゾーンに対応した日付データを作る

記事「Google AnalyticsとSearch Consoleのタイムゾーンを認識してデータポータルを活用する」や「日本と時差が16時間あるGoogleサーチコンソールのタイムゾーンの年月日のデータをGA4に記録させる方法」で紹介しているように，Googleサーチコンソールのタイムゾーンは「太平洋夏時間（PDT：Pacific Daylight Time）」に固定されています．したがって，日本時間に設定しているGA4とは16時間の時差があります（以下，対象のGA4は日本時間に設定されているとします）．

この時差により，例えばGA4で計測された2025年10月20日のGoogle自然検索からの流入データは，サーチコンソールのレポート上では2025年10月19日，または2025年10月20日のデータと対応する可能性があります（注意：実際には様々な要因が関係するため，特定の流入が必ずこのように対応するとは限りません）．

そこで，Looker Studioの計算フィールドにおいてDATE 関数とDATETIME_SUB 関数，そしてGA4の「日時（YYYMMDDHH）」を組み合わせて使用し，GA4のデータソース内に太平洋夏時間の日付データを作成します．

GA4のデータソースで「フィールドを追加 > 計算フィールドを追加」を選択（図16赤枠内参照）し，数式入力画面を開きます．フィールド名を「[fx]_PDT日付」とし，数式を

DATE(DATETIME_SUB(日時（YYYYMMDDHH）, INTERVAL 16 HOUR))

と入力して（図17参照），保存します（もちろん，フィールド名は任意に変更可能です）．

Looker Studio：DATETIME_SUB

https://cloud.google.com/looker/docs/studio/datetimesub?hl=ja

Looker Studio：DATE

https://cloud.google.com/looker/docs/studio/date?hl=ja

図16．GA4のデータソースで「フィールドを追加 > 計算フィールドを追加」を選択．

図17．Looker Studioの計算フィールドでDATE 関数とDATETIME_SUB 関数とGA4の「日時（YYYMMDDHH）」を使い太平洋夏時間の日付を出力するフィールドを作成．

このディメンション「[fx]_PDT日付」を，第2節で作成したGA4のテーブルの1つに追加して確認してみます（図18参照）．

図18．GA4のテーブルの1つにディメンション「[fx]_PDT日付」をテーブルに追加．

以下，本記事では統合の結合条件で使用するフィールドを「結合キー」と呼ぶことにします．

図19．「[fx]_PDT日付」のデータの確認．

4．ランディングページの表記を統一させる

次に結合キー（統合の結合条件で使用するフィールド）として使いたいランディングページのデータを，GA4とサーチコンソールで同じ表記形式にします．

第2節で述べたとおり，GA4のランディングページはパス形式で表示されます．また，本サイトの環境では「ランディング ページ + クエリ文字列」と「ランディング ページ」の値では，その末尾（本サイトの場合での第4階層の後）に「/」があるかないかのとう表記の違いがあることを確認しています．

一方，サーチコンソールの「Landing Page」の値はURLのフル表記です．

本サイトの記事「生成AIサービスからのアクセスとGA4の計測」を例にすると，Looker Studioのテーブルでは以下のような表示になっていました．

• GA4の「ランディング ページ + クエリ文字列」は「/tools/0217183932/ai-search-access-01/」と表示．
• GA4の「ランディング ページ」は「/tools/0217183932/ai-search-access-01」と表示．
• サーチコンソールの「Landing Page」は「https://index-lab.jp/tools/0217183932/ai-search-access-01/」と表示．

GA4とサーチコンソールのデータ統合でランディングページを結合キーとして使用する場合は，この表記の違いを修正して統一することが必須となります．

なお，本サイトのサーチコンソールの「Landing Page」の値は末尾（第4階層の後）に「/」がある表記ですが，「/」がない表記となる場合もあります．また，サーチコンソールの「Landing Page」の値が末尾に「/」がない表記で，対応するGA4の「ランディング ページ + クエリ文字列」や「ランディング ページ」の値も同様に末尾に「/」がない表記という場合もあるでしょう．そのため，以下で紹介する本サイトの内容に対応させた変換方法が，ご自身の環境とは異なる可能性は高いです．しかし，基本的な手法は同じなので，参考にしてご自分の環境に合わせて調整してください（本例では，上記のような表記揺れもあり，GA4の「ランディング ページ + クエリ文字列」の値を活用していますが，自然検索の流入なので，「ランディング ページ」の値を使ってもほとんどの場合は問題ないと考えられます）．

Looker Studioのテーブルでランディングページの情報を使用する場合，GA4のようなパス表記の方が，短く視認性が高いので，良いと感じます．ランディングページをパス表記に統一するには，サーチコンソールの「Landing Page」のURL表記をパス表記に変換する必要がありますが，これは正規表現を用いるため複雑になりがちです．一方で，GA4の「ランディング ページ + クエリ文字列」と「ランディング ページ」をURLのフル表記に変換するのは，ホスト・ドメインなどの第1階層（本例ならば「https://index-lab.jp」）を先頭に追加するだけであり，CONCAT関数を用いて容易に行えます．ただし，URLのフル表記を用いるとテーブルの列幅が長くなり，全体が横長になりやすいという欠点があります（もちろん，折り返し表示やレポートそのものの横幅調整などの対応は可能ですが，他のディメンションや指標が増えるほど，URLの表記は煩雑に感じるかもしれません）．

本例では，ランディングページをパス表記に統一する方法を採用します．

変換が容易なURLのフル表記に統一する方法は，記事「【補足】Looker Studioのデータ統合で作ったランディングページ×日付のテーブルについて」の第2節にて紹介しています．

それでは，ランディングページをパス表記に統一する手順を紹介します．具体的には，サーチコンソールの「Landing Page」のURL表記をパス表記に変換することになりますが，この変換には，REGEXP_EXTRACT関数を使用します．

Looker Studio：REGEXP_EXTRACT

https://cloud.google.com/looker/docs/studio/regexpextract?hl=ja

上記の公式解説を確認すれば基本的な使用方法は普通に理解できますが，正規表現を使う必要があることが分かります．

Looker Studio：Looker Studioの正規表現

https://cloud.google.com/looker/docs/studio/regular-expressions-in-looker-studio?hl=ja

この正規表現の利用が，多くのユーザーにとって複雑で難解な点だと思われます．正規表現になれている方は問題ありませんが，そうでない方も多いでしょう．そこでこの正規表現を用いるREGEXP_EXTRACT関数の記述を，生成AIに作成してもらうことにします．使用する生成AIはChatGPTでも良いとは思いますが，Looker StudioがGoogleのサービスなのでGeminiを使用しました．このために用いたプロンプトは以下の通りです（表示の問題で以下は画像です．テキストファイルを REGEXP_EXTRACT関数でURLをパスに変換するため記述依頼プロンプト でダウンロードできるようにしました）．

上記の質問に対してのGeminiの回答は以下のようなものでした（図20に示すように回答は，REGEXP_EXTRACT関数の記述そのものだけでなく，解説もしてくれています）．

REGEXP_EXTRACT(URL, '^https?://[^/]+(/.*)')

図20．Geminiの回答．

上記のプロンプトは本例で使用しているサイトのサーチコンソールとGA4のデータを見て検討した結果，どのような出力にしたいかを考えて作成しました．同様に生成AIを利用する場合は，ご自分の環境のデータを見て上記のプロンプトを調整してください．

GA4のランディングページのパス表記の最後に「/」がない表記なのに，計算フィールドを使って作ったサーチコンソールのパス表記の最後に「/」がある表記だと，それらをLooker Studioの結合キーとして使用しても機能しないので注意してください．

サーチコンソールのデータソース（本例：「SC index-lab.jp URL-impression-date」）を選び，「計算フィールドを追加する」を実行します．フィールド名を「[fx]_LPのパス（第2階層以下の表記）」とし，上記のGeminiの結果を利用して数式を

REGEXP_EXTRACT(Landing Page, '^https?://[^/]+(/.*)')

と入力して（図21参照），保存します（もちろん，フィールド名は任意に変更可能です）．

図21．Looker Studioの計算フィールドでREGEXP_EXTRACT関数とサーチコンソールの「Landing Page」を使いランディングページを出力するフィールドを作成．

第2節で作成したレポートの一番下のテーブルのディメンションに「[fx]_LPのパス（第2階層以下の表記）」を追加して確認をします（図22参照）．図23のように，サーチコンソールの「Landing Page」のURLのフル表記に対して「fx]_LPのパス（第2階層以下の表記）」はパス表記になっているのが確認できました．

図22．サーチコンソールのテーブルに「[fx]_LPのパス（第2階層以下の表記）」を追加．

図23．「fx]_LPのパス（第2階層以下の表記）」の確認．

5．Looker StudioでGA4とサーチコンソールをデータ統合する

ランディングページと日付の結合キー（統合の結合条件で使用するフィールド）の準備ができたので，ランディングページ×日付のテーブルのためのデータソースを，サーチコンソールとGA4のデータ統合で作成します．

本例のデータ統合では，結合演算子の左外部結合を使うことにします（「結合演算子」と「左外部結合」の詳細については，第1節で紹介したGoogle公式やアユダンテ株式会社さんの記事を参照してください）．左外部結合を行う際，主体となる左側のテーブルをGA4とサーチコンソールのどちらにするかですが，本例ではサーチコンソールを左側のテーブルとすることを推奨します．その主な理由は3つありますが，本記事では割愛し，記事「【補足】Looker Studioのデータ統合で作ったランディングページ×日付のテーブルについて」の第3節にて紹介しています．

それでは，サーチコンソールを左側のテーブルにして左外部結合を実行します．

統合を始める方法はいろいろありますが，編集画面で上部のタブにある「ブレンド」をクリックすると（図24赤枠内参照），統合を追加や管理する画面が表示されます．そこで「統合を追加」を押すことで開始できます（図25赤枠内参照）．

図24．Looker Studioの編集画面上部タブにある「ブレンド」をクリック．

図25．Looker Studioの統合を追加や管理する画面．

データの統合の画面が開かれたら，テーブル1にサーチコンソールのデータソース（本例：「SC index-lab.jp URL-impression-date」）が選択されていればそのまま進みます（図26赤枠内参照）．GA4のデータソース（本例：「GA4 index-lab.jp_202510」）が選択されている場合（図27赤枠内参照）は，本例では左外部結合を採用するため，図28のようにプルダウンからデータソースを該当するサーチコンソールに変更してください．またテーブル1の「テーブル名」は任意です（本例では特に与えていません）．

図26．データの統合の画面のテーブル1にサーチコンソールのデータソースが選ばれている状態．

図27．データの統合の画面のテーブル1にGA4のデータソースが選ばれている状態．

図28．データの統合の画面のテーブル1のデータソースを変更．

次に，テーブル1の横にある「別のテーブルを結合する（図26緑枠内参照）」をクリックすると，データソースの一覧が表示されます（図29参照）．そこで「添付のデータソース」の欄から太平洋夏時間の日付を作ったGA4のデータソース（本例：「GA4 index-lab.jp_202510」）を選択します．

図29．テーブル1の横にある「別のテーブルを結合する」をクリックした状態．

結果，テーブル1にサーチコンソールのデータソース，テーブル2にGA4のデータソースを選んだ状態になります（図30参照）．

図30．Looker Studioの統合を追加や管理する画面でテーブル1にサーチコンソール，テーブル2にGA4のデータソースを選んだ状態．

それでは，テーブル1でディメンションに結合キーとして使用する「[fx]_LPのパス（第2階層以下の表記），Date」を追加し，指標として「Impressions，Url Clicks」を追加します（図31参照）．「[fx]_LPのパス（第2階層以下の表記）」は，サーチコンソールのデータソースに計算フィールドで追加したLanding PageのURL表記をパス表記に変換させたものです（第4節参照）．

図31．テーブル1でディメンションと指標を追加．

テーブル2でディメンションに「[fx]_PDT日付，ランディング ページ + クエリ文字列，セッションの参照元 / メディア，日付」を追加し，指標として「セッション，直帰率，キーイベント」を追加します（図32参照）．「[fx]_PDT日付」は，第3節で作成した太平洋夏時間の日付のデータで，結合キーとして使用します．本例では，パス表記を「ランディング ページ + クエリ文字列」にそろえたためこのディメンションを追加しましたが，環境によっては「ランディング ページ」でも問題ないと考えられるので，適時判断してください．「セッションの参照元 / メディア」は，後にフィルタリングなどで使うので含めています．そして，GA4のデータソースであるテーブル2では，第2節で作成した「Google自然検索」のフィルタを追加してください（図32と33参照）．

図32．テーブル2でディメンションと指標とGoogle自然検索のフィルタを追加．

図33．テーブル2の「フィルタを追加」をクリックした状態．

なお，ここでテーブル2に「Google自然検索」のフィルタを追加せず，後からデータ統合で作成したデータソースを用いたテーブルにGoogle自然検索だけになるようなフィルタを適用することも可能ですが，その場合はそのデータ統合で作成したデータソースに対して新たに同様のフィルタを作成する必要があります（このような後付けでフィルタを適用したとき，作成直後のテーブルでは，サーチコンソールのデータとGoogle自然検索以外の流入元が紐付いた誤った内容を多く表示され視覚的な混乱を招くため，テーブル2でフィルタを追加するのを推奨します）．

テーブル1や2に，上記のディメンションや指標に他のものを追加してもかまいません．データ統合で作成したデータソースを用いたテーブルを作成する場合，ここで追加したディメンションや指標しか設定の選択肢として現れないので，テーブルで使用したいものはここで追加する必要があります．

次に，テーブル1とテーブル2の間にある「結合を設定（図34赤枠内参照）」をクリックし，「結合の設定」のウィンドウを開き結合演算子と結合条件を設定します（図35参照）．

図34．テーブル1とテーブル2の間にある「結合を設定」をクリック．

図35．「結合の設定」のウィンドウ．

すでに述べたとおり，本例では結合演算子は「左外部結合」を使用します．図35で示すように，デフォルトで「左外部結合」が選ばれた状態なので，結合演算子は変更せず，結合条件の下にある「フィールドを追加」を設定します．結合条件の左の「フィールドを追加」をクリックして，「[fx]_LPのパス（第2階層以下の表記）」を選択（図36と37参照）．すると右側が「指標がありません」となるのでそれを押して，「ランディング ページ + クエリ文字列」を選択します（図38参照）．

図36．「結合の設定」で左の「フィールドを追加」をおした状態．

図37．左の「フィールドを追加」「[fx]_LPのパス（第2階層以下の表記）」を選択した結果．

図38．「結合の設定」で右の「フィールドを追加」で「ランディング ページ + クエリ文字列」を選択した結果．

さらに同様にして，左側のフィールド追加で「Date」を選択し，その右側に「[fx]_PDT日付」を選択し，保存します（図39参照）．

図39．「結合の設定」でさらに左のフィールド追加で「Date」を選択，その右に「[fx]_PDT日付」を選択した結果．

図40．データの統合の設定が終わった状態．

図41．統合名を「SCｰGA4のLP＆DATEでの結合」と名付けて保存．

6．データ統合で作ったデータソースでテーブルを作成

それでは，Looker Studioの編集画面に戻り，新しいページを追加します（図42参照）．その新しいページに，「挿入 > テーブル（図43参照）」でテーブルを挿入します．

図42．Looker Studioのレポートで新しいページを追加．

図43．テーブルの挿入．

新しいページにテーブルを挿入すると，添付データソースの1つがデフォルトで選択されています（図44参照）．これを混合データにあるデータ統合で作成したデータソース（本例：「SCｰGA4のLP＆DATEでの結合」）に選択し直します．

図44．挿入したテーブルのデータソースをサーチコンソールからデータ統合で作成したデータソース「SCｰGA4のLP＆DATEでの結合」に変更．

データソースがデータ統合で作成した「SCｰGA4のLP＆DATEでの結合」に設定された状態で，ディメンションと指標を追加してテーブルを構築します（図45参照）．

図45．選択しているテーブルのデータソースがデータ統合で作成した「SCｰGA4のLP＆DATEでの結合」に設定された状態．

本例では，ディメンション「[fx]_LPのパス（第2階層以下の表記），Date，セッションの参照元 / メディア」，指標「Impressions，Url Clicks，セッション，直帰率，キーイベント」のテーブルを作成しました（図46と47参照）．

図46．テーブルにディメンションと指標を追加．

図47．編集画面でのテーブル表示．

以上で，サーチコンソールとGA4のデータソースを統合した「ランディングページ×日付のテーブル」が完成です（図48参照）．

図48．完成したサーチコンソールとGA4のデータソースを統合した「ランディングページ×日付のテーブル」．

データの並び順はデフォルトで「Url Clicks」の降順となっていたので，そのままにしてあります．データが無い項目は「null」表記となるため，並び順をDate（日付）の降順などに変更すると「null」ばかりの行が表示され，見栄えが悪くなったりします．サーチコンソールのランディングページのデータ（本例の統合したデータだと「[fx]_LPのパス（第2階層以下の表記）」）には，インプレッションのみ（クリックはされていない，「Url Click」がゼロ）のデータが大量に含まれています（図49参照）．インプレッションのみの場合サイトには流入していないため，GA4のデータは存在しません．したがって，テーブル内のインプレッションのみに該当するディメンション「セッションの参照元 / メディア」や指標「セッション，直帰率，キーイベント」の値は「null」となります．

図49．インプレッションのみ（クリックはされていない，「Url Clicks」がゼロ）のデータ．

「Url Clicks」の値がゼロでも「セッション」が「null」でない行もわずかに見られます（図50参照）が，データ統合での結合条件にマッチするものがなぜかあったのでしょう．元々，サーチコンソールとGA4との間でデータの不一致となる原因がいくつも存在することを踏まえて，これは何かしらのエラーの影響だと見なし，完全な一致は不可能であるという前提で，このような場合の対応ルール（無視するなど）を事前に決めておくのが良いでしょう（もちろん，このようなデータが大量にある場合は，原因を調査すべきです）．

図50．「Url Clicks」の値がゼロでも「セッション」が「null」でないデータ．

また，「Url Clicks」の値が1以上であるにもかかわらず，GA4関連「セッションの参照元 / メディア，セッション，直帰率キーイベント」の値が「null」の行も存在します（図51参照）．これは，GA4の計測エラーや計測される前に離脱した可能性もありますが，広告ブロックアドオンが有効なブラウザが使用されていた場合に該当する可能性もあります．なせなら，サーチコンソールのデータは広告ブロックアドオンの影響は受けませんが，GA4の計測はその影響を受け，GA4のデータに流入そのものが記録されないためです．

図51．「Url Clicks」の値が1以上であるがGA4関連の値が「null」のデータ．

なお，「Url Clicks」の値がゼロのものをフィルタでテーブルから完全に除外できるのではと考えられますが，このフィルタは機能しないことを確認しています．データソースを混合データの「SCｰGA4のLP＆DATEでの結合」で，「除外条件」で項目を「Url Clicks」，条件の選択を「次に等しい（=）」，Any Valueを「0」としたフィルタを作成し（図52参照），これをテーブルに適用しましたが，システムエラーでテーブルの中身が表示されなくなります．

図52．「クリックゼロ除外」フィルタ．

図53．「クリックゼロ除外」フィルタを提供したテーブルがシステムエラーになった状態．

テーブルは完成したのですが，このままでは使いにくいので，レポート（同一ページ）内に期間指定とディメンション「Date，[fx]_LPのパス（第2階層以下の表記），セッションの参照元 / メディア」のコントロールボタンを追加しました（図54参照）．なお，ディメンション「Date」と「[fx]_LPのパス（第2階層以下の表記）」と「セッションの参照元 / メディア」のコントロールボタンを作るときは，「データソース」をデータ統合で作成したデータソース（本例：「SCｰGA4のLP＆DATEでの結合」）に選び直すことを忘れないように注意してください．デフォルトでは，これらコントロールボタンを作ろうとすると添付のデータソースが選ばれていると思います．

図54．コントロールボタンを追加したサーチコンソールとGA4のデータソースを統合した「ランディングページ×日付のテーブル」．

サーチコンソールの日付に該当する「Date」をコントロールボタン（指標「Url Clicks」）として加えると，データ期間内ならある特定の日だけを選んで見ることができるので便利だと考えました（図55参照）．

図55．「Date」のコントロールボタン．

サーチコンソールの「Landing Pages」をパス表記に変換した「[fx]_LPのパス（第2階層以下の表記）」をコントロールボタン（指標「Url Clicks」）に加えると，特定のページを選択して（絞って）で見ることができるので便利だと考えました（図56参照）．

図56．「[fx]_LPのパス（第2階層以下の表記）」のコントロールボタン．

図57．「セッションの参照元 / メディア」のコントロールボタン．

図58．「セッションの参照元 / メディア」のコントロールボタンで「null」を除外した状態．

なお，コントロールボタンで「google / organic」だけにするのが面倒，最初から「null」の場合を全部無くしたいという場合は，データ統合で作成したデータソース（本例：「SCｰGA4のLP＆DATEでの結合」）を用いて，「一致条件」で項目を「セッションの参照元 / メディア」，条件の選択を「次に等しい（=）」，Any Valueを「google / organic」としたフィルタを作り（図58参照），それをテーブルに適用してください．このフィルタをテーブルに適用した場合は，「セッションの参照元 / メディア」のコントロールボタンもいりませんし，テーブルの「セッションの参照元 / メディア」の列を無くしてもいいでしょう．

図59．データ統合で作成したデータソースに対するGoogle自然検索だけにするフィルタ「混合Google自然検索」．

最後に，Dateを「2025/10/09，2025/10/10，2025/10/11，2025/10/12，2025/10/13，2025/10/14」に絞り，「[fx]_LPのパス（第2階層以下の表記）」を「/marketing/0701201615/microsoft-rewards-001/」のみに絞ったテーブルを示しておきます（図60参照．クリックすると拡大します）．このとき，「セッションの参照元 / メディア」に「null」は含まれていませんでした（したがって，「セッションの参照元 / メディア」のコントロールボタンは「google / organic」だけとなっています）．

図60．特定の日付とランディングページに絞ったテーブル（クリックすると拡大します）．

「/marketing/0701201615/microsoft-rewards-001/」の該当記事は「Bing検索を使ってMicrosoft Rewards ポイントを獲得して「Windows 10」延命プログラム「ESU」を無償で利用」です．時期的にWindows 10の延長方法の具体的な手順を知りたい人が入ってきたのではないかと推測していましたが，直帰率が意外と低いことに驚きました（記事の内容は，具体的な延長方法の手順を記述していません）．

図60から，「2025/10/09」は，「Url Clicks」の値が「セッション」の値と等しい日だったと確認できます．

図60から，「2025/10/12」は，「Url Clicks」の値が「セッション」の値より大きい日だったと確認できます．この「Url Clicks」の値が「セッション」の値より大きい場合は，広告ブロックアドオンが有効なブラウザを使った流入があった可能性を示唆しています（もちろん，それらがGA4の計測エラーや，計測される前に離脱した可能性もあります）．

図60から，「2025/10/10，2025/10/11，2025/10/13，2025/10/14」は，「Url Clicks」の値が「セッション」の値より小さい日だったと確認できます．この「Url Clicks」の値が「セッション」の値より小さい場合は，直前にGoogleで検索していない流入（例えば，ブックマークを使った流入）があったと推測されます．

以上で，本記事での「ランディングページ×日付のテーブル」のレポートの紹介はおわりですが，図54のコントロールボタンを追加した「ランディングページ×日付のテーブル」のレポートを，さらに改良した内容などを，記事「【補足】Looker Studioのデータ統合で作ったランディングページ×日付のテーブルについてhttps://index-lab.jp/tools/1111125211/ga4-sc-date-003/」の第4～6節で紹介しています．

記事「【補足】Looker Studioのデータ統合で作ったランディングページ×日付のテーブルについて」の第4節で，指標「新規ユーザー数」を追加した場合を紹介しています．

記事「【補足】Looker Studioのデータ統合で作ったランディングページ×日付のテーブルについて」の第5節で，ディメンション「Query」を追加した場合を紹介しています．

記事「【補足】Looker Studioのデータ統合で作ったランディングページ×日付のテーブルについて」の第6節で，デバイスカテゴリーの情報を追加した場合を紹介しています．

7．おわりに

本記事は，GA4とサーチコンソールのデータ統合をする際，日付を太平洋夏時間にそろえることは最低限実地すべきであるという考えに基づき，ランディングページと日付を用いた統合方法などを紹介しました．

この方法は，Googleが述べているSearch Console とアナリティクスのデータの不一致の原因の一つである「タイムゾーンが異なる」問題に対する補正案です．

ただし，GA4とサーチコンソールのデータの間には，上記リンク先に書かれた不一致の原因以外にも様々な課題が存在します．例えば，ブラウザの広告ブロックアドオンの影響もその一つです（参照：記事「広告ブロックのアドオンを使っているブラウザ（GA4等で計測されないアクセス）の割合はどれぐらいなのか」）．サーチコンソールのデータは広告ブロックアドオンの影響は受けませんが，GA4の計測はその影響を受けます（GA4のデータに流入そのものが記録されません）．この点を考慮すると，実際のGoogleの検索結果での流入数（サーチコンソールのクリック数）は，GA4で計測されたGoogle自然検索の流入セッションと等しいか，それ以上になるという大小関係が推測できます．

ですが，この大小関係の推測とは異なる結果を示すデータも存在します．その原因の一つは，GA4では直接の訪問で開始されたセッションが，そのユーザーの最後に確認された「参照元 / メディア」に関連付けられるというルールです．本例では，GA4のセッションをGoogleの自然検索に限定するためのフィルタで「セッションの参照元 / メディア」の情報を使用しています．「セッションの参照元 / メディア」の値が「google / organic」であっても，そのセッションが真にGoogle自然検索からのものかどうか（例えば，この時間より前にGoogle自然検索から流入して，セッションが一度切れた後に，ブックマークなどから流入したセッションなどが含まれている可能性）は，完全に断定することはできません．

いずれにせよ，GA4とサーチコンソールのデータ統合において，完全に一致するデータを作成することは不可能であると認識すべきです．ただし，本記事で紹介したようにせめて日付の補正はしたほうがいい（日付の補正を行わない場合でも，日本時間のGA4とはサーチコンソールは16時間の時差がある認識を持つべき）と筆者は考えて，この記事を書きました．

結局は，サーチコンソールとGA4のデータ統合はどうやっても不完全なものになることと，そしてその統合データがどのような要因によって影響を受けているかを理解したうえで活用することが重要です．