【補足】Looker Studioのデータ統合で作ったランディングページ×日付のテーブルについて

本記事は，記事「Looker Studioでサーチコンソールと日付補正したGA4のデータを統合してランディングページ×日付のテーブルを作る」を補足する内容です．この記事を読了していることを前提としています．本記事で登場するGA4（Google Analytics 4），サーチコンソール，Looker Studioは，すべてGoogleが提供しているサービスのことです．

1．太平洋夏時間の日付データを作る別の方法

前提記事「Looker Studioでサーチコンソールと日付補正したGA4のデータを統合してランディングページ×日付のテーブルを作る」の第3節で省略した，太平洋夏時間の日付を作成する別の方法について紹介します．

太平洋夏時間の日付データをGA4のデータソースに作るのに，記事「日本と時差が16時間あるGoogleサーチコンソールのタイムゾーンの年月日のデータをGA4に記録させる方法」で紹介したイベントパラメータ「custom_date_pdt」を使用することも可能です．ですが，その記事の第5節でも書いたように，「custom_date_pdt」はタイプが「テキスト」です（すなわち，「2025/10/11」のような文字情報となっています．図1参照）．一方，GA4のデフォルトの「日付」やサーチコンソールの「Date」はタイプが「日付」です．つまり，「custom_date_pdt」をLooker Studioのテーブルで使用したとき，GA4のデフォルトの「日付」やサーチコンソールの「Date」と画面上の表示は同じでも，データ形式が異なっています．

そのため，Looker Studioのデータ統合で結合キー（統合の結合条件で使用するフィールド）として，GA4の「custom_date_pdt」とサーチコンソールの「Date」は対応させられません（対応させてもエラーとなり結果が表示されません）．

図1．「custom_date_pdt」の値はタイプが「テキスト」．

したがって，記事「日本と時差が16時間あるGoogleサーチコンソールのタイムゾーンの年月日のデータをGA4に記録させる方法」の第5節で紹介したように，PARSE_DATE関数を使って「custom_date_pdt」の値を日付形式（タイプを「日付」）に変換させます（図2と3参照）．このように変換したフィールドならば，サーチコンソールの「Date」に対応させる有効な結合キーとして，サーチコンソールとGA4のデータ統合に使えます（図4参照）．

図2．PARSE_DATE関数を使って「custom_date_pdt」の値を「日付」タイプに変換し，「[fx]_PDT日付（custom_date_pdtを日付形式に変更）」と名付けて保存．

図3．フィールド「[fx]_PDT日付（custom_date_pdtを日付形式に変更）」のタイプが「日付」になっているのを確認．

図4．サーチコンソールの「Date」とGA4の「[fx]_PDT日付（custom_date_pdtを日付形式に変更）」を結合キーとして使用．

2．GA4のランディングページの値をURLのフル表記にする方法

前提記事「Looker Studioでサーチコンソールと日付補正したGA4のデータを統合してランディングページ×日付のテーブルを作る」の第4節で紹介しなかった方法を説明します．

Looker Studioで該当するGA4のデータソース（本例：「GA4 index-lab.jp_202510」）を選び，「計算フィールドを追加する」を実行します．フィールド名を「[fx]_ランディングページURL」とし，本サイトの場合ならば数式を

CONCAT('https://index-lab.jp', ランディング ページ + クエリ文字列)

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

Looker Studio：CONCAT
https://cloud.google.com/looker/docs/studio/concat?hl=ja

図5．CONCAT関数を使ってGA4のランディングページのパス表記をURL表記に変換．

CONCAT関数の数式内の「https://index-lab.jp」の部分は，もちろん例として使用しているサイトがこのサイトだからです．ここは，ご自分のサイトのホスト＆ドメインなどの第1階層の情報にしてください．また「ランディングページ + クエリ文字列」をCONCAT関数の変数として使用しているのは，本サイトのサーチコンソールの「Landing Page」のURL表記の最後（本サイトの場合での第4階層の後）に「/」がある表記だからです（本サイトのGA4の「ランディングページ + クエリ文字列」と「ランディングページ」の表記の違いなどは，前提記事の第4節を参照）．

前提記事の第2節で作成したGA4のテーブルの1つを利用して，ちゃんと変換が出来ているか確認してみます．一番上のテーブルのディメンションから「日時（YYYMMDDHH）」を除いて，「[fx]_ランディングページURL」を追加します（図6参照）．図6のようにサーチコンソールの「Landing Page」のURLの表記と同じ形式になりました．

図6．CONCAT関数で変換した結果を確認．

もし，本サイトのサーチコンソールの「Landing Page」のURL表記の最後に「/」がない表記だったら，上記の計算フィールドの数式は，

CONCAT('https://index-lab.jp', ランディング ページ)

と「ランディングページ」を関数の変数として使用していたでしょう．

CONCAT関数を使う場合，その変数を「ランディングページ + クエリ文字列」と「ランディングページ」のどちらにするかはご自身の環境に合わせて考えてください．どちらを使っても問題ない場合もあると思います．

ともかく，もしもサーチコンソールの「Landing Page」のURL表記の最後に「/」がある表記なのに，GA4の計算フィールドのCONCAT関数で作ったランディングページのURLの表記の最後に「/」がない場合，それらをLooker Studioの結合キー（統合の結合条件で使用するフィールド）として使用しても機能しない（結合条件に一致するものがないとしてテーブルが空になる）ので注意してください．

上記のようにCONCAT関数を使ってランディングページをURLのフル表記に統一した場合，Looker Studioのデータ統合において，テーブル1（サーチコンソールがデータソース）のディメンションは「Landing Page, Date」」を追加し，指標は「Impressions，Url Clicks」を追加します（図7参照）．そしてテーブル2（GA4がデータソース）のディメンションは「[fx]_PDT日付，[fx]_ランディングページURL，セッションの参照元 / メディア，日付」を追加し，指標は「セッション，直帰率，キーイベント」を追加すればいいでしょう（図7参照）．

図7．Looker Studioのデータ統合でのテーブル1とテーブル2．

この場合のランディングページに関する結合キーは，「Landing Page」と「[fx]_ランディングページURL」の組み合わせになります（図8参照）．図9は，本節のデータ統合の設定（図7と図8）で作ったデータソースを用いたテーブルです．

図8．結合演算子と結合条件の設定．

図9．「Landing Page」と「[fx]_ランディングページURL」を結合キーとしたデータ統合のデータソースを用いたテーブル．

3．左外部結合で主体となる左側テーブルをサーチコンソールにした理由

前提記事「Looker Studioでサーチコンソールと日付補正したGA4のデータを統合してランディングページ×日付のテーブルを作る」の第5節で，

『左外部結合を行う際，主体となる左側のテーブルをGA4とサーチコンソールのどちらにするかですが，本例ではサーチコンソールを左側のテーブルとすることを推奨します．その主な理由は3つあります』

と記述しましたが，その3つの理由をここで示しておきます．

理由1：行動の時系列順序に基づいた選択．ユーザーはまずGoogleの検索結果にサイトが表示され（サーチコンソールの計測），その後にサイトに流入する（GA4の計測）という時系列で行動するため，起点となるサーチコンソールを主体とするのが適切だと考えました．

理由2：広告ブロックアドオンによるデータ欠損の考慮．データがどのように計測されているかが関係しています．昨今，ブラウザに広告ブロックアドオンを使用している方も増えています（参照：記事「広告ブロックのアドオンを使っているブラウザ（GA4等で計測されないアクセス）の割合はどれぐらいなのか」）．広告ブロックアドオンが有効のブラウザでGoogle検索を行った場合でも，その検索行為はGoogleによって記録され，サーチコンソールのデータに反映されます（これはサーバー側での記録行為に基づくことから推測されます）．一方，GA4の計測はJavaScriptで生成したクッキーに依存するため，広告ブロックアドオンが有効のブラウザが使用されていると計測されないことがあります．つまり，Googleの自然検索で流入したにもかかわらず，GA4では計測されていないデータが存在し得るということです．したがって，左外部結合でサーチコンソールが主体でないと，広告ブロックアドオンが有効のブラウザでクリックされたデータが，ディメンションにランディングページを使ったテーブルでは表示されないリスクがあります．

理由3：データ反映のラグ（時間差）への対応．Looker StudioでGA4とサーチコンソールに接続してデータを読み込んだ際，GA4は昨日のデータから反映されますが，サーチコンソールは3日前のデータからしか反映されないという特性があるからです．例えば，図10は，上が「日付」を降順にしたGA4のテーブルで，下が「Date」を降順にしたサーチコンソールのテーブルです（データ期間は「過去28日間」のデフォルト状態）．GA4は「2025/11/04」，サーチコンソールは「2025/11/02」となっており，同じデータ期間でも，表示されるデータの最終日が異なることが確認できます．

図10．G A4とサーチコンソールの最終反映日の違いを確認（降順）．

左外部結合で主体となる左側のテーブルをGA4にすると，結合キー（統合の結合条件で使用するフィールド）に使う日付はGA4のもの（本例：「[fx]_PDT日付」）がテーブルで表示されます．その結果，そのテーブルにはサーチコンソールのデータが反映されていない日が必ず含まれ，これらの日のサーチコンソールの指標は「null」となります．

＜補足＞「null」はデータがない場合の表記です．Looker Studioではデフォルト「null」が使われますが，スタイルの「データの欠落」で異なる表記に変更可能です（図11参照）．

図11．スタイルの「データの欠落」設定で、データがない場合の表記を変更可能．

なお，左外部結合で主体となる左側のテーブルをGA4としてデータ統合するアプローチが必ずしも間違いというわけではありません．

サーチコンソールのランディングページのデータ（「Landing Page」，本例のデータ結合ではパス形式に変更したもの）には，「Impressions」は計測されても「Url Clicks」がゼロの場合が多数存在します．「Url Clicks」がゼロの場合とは，すなわちサイトに流入していないことを意味するため，それに対応するGA4のデータは当然ありません．この点を考慮すると，左外部結合でGA4を左側のテーブルにすれば，「Url Clicks」がゼロのデータ（基本的にはGA4側に対応データがないもの）が一掃されます（ただし，理由3の影響で直近2日間は「Impressions，Url Clicks」の値が「null」になる表示が大量に現れたりもしますし，その他の箇所でも「null」を確認したので，完全に「null」を無くすのは無理だと思われます）．なお，前提記事の第5節でのテーブル1（サーチコンソール）とテーブル2（GA4）で結合演算子を右外部結合にすれば，図12と同じデータ統合となります．

図12．左側テーブルをGA4に設定してデータ統合した例．

図13．左側テーブルをGA4に設定してデータ統合したデータソースを用いたテーブル．

この左外部結合で主体となる左側のテーブルをGA4としてデータ統合した場合は，前提記事の第6節で行ったような「セッションの参照元 / メディア」のコントロールボタンの追加や，統合で作ったデータソースでのGoogle自然検索のみにするフィルタを作るなどの調整作業を省略できます．

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

4．指標「新規ユーザー数」を追加と活用

前提記事「Looker Studioでサーチコンソールと日付補正したGA4のデータを統合してランディングページ×日付のテーブルを作る」の第7節で，以下のような考察を示しました．

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

セッションが真にGoogle自然検索からのものかを知るために，完全ではないものの，指標「新規ユーザー数」が利用できます．なぜなら「新規ユーザー数」は「過去にサイトにアクセスしたことがないユーザー数」ですから，特段の原因などが無い限り，その新規ユーザーの「セッションの参照元 / メディア」には実際の流入元の情報が記録されるからです．

Googleの公式ヘルプ
新規ユーザー数：指定した期間にサイトまたはアプリにアクセスしたユーザーのうち、過去にサイトまたはアプリにアクセスしたことがないユーザーの数。
https://support.google.com/analytics/answer/12253918?hl=ja

まず，前提記事の第5節で作成したデータ統合のデータソースのテーブル2（GA4）の指標に，「新規ユーザー数」を追加し，保存します（図14赤枠内参照）．

図14．テーブル2のGA4の指標に「新規ユーザー数」を追加．

そして，前提記事の第6節で作成したデータ統合のデータソースを用いたランディングページ×日付のテーブルに，指標「新規ユーザー数」を追加します（図15参照）．

図15．データ統合したデータソースで作ったテーブルに指標「新規ユーザー数」を追加．

図16は，図15のテーブルで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/」のみに絞った結果です（クリックすると拡大します）．

図16．図15のテーブルを特定の日付とランディングページで絞り込んだ結果（クリックすると拡大図が見られます）．

例えば，図16のテーブルの4行目のDate「2025/10/12」では，「セッション」の値と「新規ユーザー数」の値が等しいので，この日の（GA4で計測された該当する）セッションすべてが真にGoogle自然検索から始まったと推測できます．ただし，この日の「Url Clicks」は10なのに「セッション」は7です．これは，広告ブロックアドオンが有効なブラウザを使っていた（ためにGA4では計測されなかった）流入が3件あった可能性を示唆しています（もちろん，それらがGA4の計測エラーや，計測される前に離脱した可能性もあります）．

図16のテーブルの1行目のDate「2025/10/09」では，「セッション」の値は12で「新規ユーザー数」の値は8なので，12セッションのうち少なくとも8セッションが真にGoogle自然検索から始まったと推測できます．また，この日の「Url Clicks」と「セッション」は等しいため，残りの4セッションも真にGoogle自然検索から始まったセッションであり，そのセッションのユーザーはすでに本サイトに訪れたことがあると考えられます．

図16のテーブルの6行目のDate「2025/10/14」では，「セッション」の値は15で「新規ユーザー数」の値は10なので，15セッションのうち少なくとも10セッションが真にGoogle自然検索から始まったと推測できます．一方で，この日の「Url Clicks」は14なのに「セッション」は15です．これは，15セッションのうちの1セッションが，ブックマークなどから流入したセッションだった可能性を示唆しています．

このように，「新規ユーザー数」をデータ統合したデータソースの指標に追加することで，より詳細な推測が可能となりました．

5．ランディングページに紐付くクエリ（Query）を追加する

Search Consoleの「URLのインプレッション」のデータソースには，「Landing Page，Date，Query，Device Category，Google Property，Country」のディメンションが含まれています．これらディメンションと指標「Impressions，Url Clicks」とを組み合わせたテーブルが図17です．

図17．Search Consoleの「URLのインプレッション」のデータソースを用いたディメンション「Landing Page，Date，Query，Device Category，Google Property，Country」と指標「Impressions，Url Clicks」のテーブル．

本節では，ディメンション「Query」に注目します．これは，Googleでの検索時にユーザーが入力したキーワードに該当し，サーチコンソールの画面で「クエリ」として表示されて確認できる情報です．「URLのインプレッション」のデータソースの「Query」は，「Landing Page」に紐付いています．例えば，図18は，「Date」が「2025/10/25」かつ「Landing Page」が「https://index-lab.jp/marketing/0701201615/microsoft-rewards-001/」に絞り込んだ場合の図17のテーブルです．

図18．特定の日付とランディングページで絞り込んだ図17のテーブル（クリックすると拡大図が見られます）．

図18を確認すると，「2025/10/25」の日だけでも多様なクエリに対して「https://index-lab.jp/marketing/0701201615/microsoft-rewards-001/」のページが検索結果として表示されたことが確認できます．例えば「bing rewards」というクエリを使った検索では，このページが検索結果として，この日に「Device Category」が「DESKTOP」で4回（図18のテーブル4行目参照）と「Device Category」が「MOBILE」で4回（図18のテーブル18行目参照）の合計8回表示されたことが確認できます．

このサーチコンソールのデータソースにあるクエリの情報「Query」を，前提記事「Looker Studioでサーチコンソールと日付補正したGA4のデータを統合してランディングページ×日付のテーブルを作る」の第6節で作成したランディングページ×日付のテーブル，もしくは上記の第4節の図15のランディングページ×日付のテーブルに追加したらどうなるでしょうか．特定のクエリを使ったユーザー（セッション）の流入に関するサイト内での行動が可視化できることを期待したいところですが，本例で作成したデータ統合のデータソースを用いたランディングページ×日付のテーブルの結合演算子や結合条件の設定から，期待する結果は得られないと推測できます．

ただし，Looker Studioにて実際に本例で作成したデータ統合のデータソースを用いたランディングページ×日付のテーブルにディメンション「Query」を追加してみると，予想と違う結果（通常の左外部結合をした場合に出力されると思っていた結果）が出力されます．実際に第4節の図15のテーブルに「Query」を追加したものが図19となります（ただし，ランディングページの値である「[fx]_LPのパス（第2階層以下の表記）」は「/marketing/0701201615/microsoft-rewards-001/」のみに絞っています）．なお，図19のように「Query」をテーブルに追加するには，第4節で指標「新規ユーザー数」を追加した（図14参照）際と同様に，該当するデータソースのテーブル1（サーチコンソール）のディメンションに「Query」を追加しておく必要があります．

図19．図15のテーブルに「Query」を追加し絞り込んだ結果（「[fx]_LPのパス（第2階層以下の表記）」は「/marketing/0701201615/microsoft-rewards-001/」のみ．クリックすると拡大図が見られます）．

図19の「Query」の列をみると，図18の「Query」の列とは異なり，数値が表示されています．図19のテーブルの「Query」の数値は，該当するランディングページと日付（「[fx]_LPのパス（第2階層以下の表記）」とDate）に紐付いたクエリの種類の数を表していると考えられます．

例えば，図18と同じ条件で「Date」が「2025/10/25」で「[fx]_LPのパス（第2階層以下の表記）」が「/marketing/0701201615/microsoft-rewards-001/」のみのデータを図19のテーブルで確認してみると，図20のように「Query」は「24」となっています．図18のサーチコンソールのデータではテーブルは26行ありますが，これはディメンション「Device Category，Google Property，Country」を同時に使っている影響です．図18のテーブルからディメンション「Device Category，Google Property，Country」を削除したテーブルが図21です．図21のテーブルでは行が24（つまり，クエリが24種類）あり，図20の「Query」の「24」と一致することが確認できます．

図20．特定の日付とランディングページで絞り込んだ図19のテーブル（Queryが「24」）（クリックすると拡大図が見られます）．

図21．図18のテーブルから特定のディメンションを削除した結果（クエリが24種類．クリックすると拡大図が見られます）．

なお，図22のような上段のサーチコンソールのテーブルと下段のGA4のテーブルを図15や図20などと同様に左外部結合でデータ統合した場合は，通常は違う形式で出力されます（注：図22は日付「2025/10/25」でランディングページ「/marketing/0701201615/microsoft-rewards-001/」で絞った状態にしています）．図22の各テーブルの内容をcsvファイルでエクスポートして．そのcsvファイルをExcelのマージ（データの結合機能）を用いて（図23参照），図20のようなテーブルをExcelで作った結果が図24です．すなわち，図22の上段のテーブルの左側に，下段のテーブルの値がすべて追加されたような結果が出力されます．上記で「予想と違う結果」と記述したのは，この結果と違っていたからです．

サーチコンソールとGA4とLooker StudioのいずれもGoogleサービスですから，Looker Studioで本例のようなデータ統合をした場合，図19のような出力になるようにGoogle側で仕様が設定されていると考えられます．

図22．特定条件で絞り込んだサーチコンソール（上段）とGA4（下段）のテーブル（クリックすると拡大図が見られます）．

図23．Excelのマージ（データの結合機能）．

図24．Excelでマージした統合結果（クリックすると拡大図が見られます）．

6．デバイスカテゴリー（「Device Category」と「デバイスカテゴリ」）をコントロールボタンで追加

図17で示したSearch Consoleの「URLのインプレッション」のデータソースを用いたディメンション「Landing Page，Date，Query，Device Category，Google Property，Country」と指標「Impressions，Url Clicks」のテーブルからわかるようにサーチコンソールのデータソースにも「Device Category」が含まれています．そして，GA4のデータソースにも当然「デバイスカテゴリ」のディメンションがあります．そこで第5節で示した図19のランディングページ×日付のテーブルのレポートに，デバイスカテゴリーを追加してみたいと思います．

ただし，デバイスカテゴリーはテーブルにディメンションとして追加するのではなく，コントロールボタンとしてテーブル上部に追加するほうが便利だろうと考えました（少なくとも本例の場合は）．

まずは，該当するデータソースを選択して「データの統合」画面を開き，テーブル1（サーチコンソール）のディメンションに「Device Category」を追加し，テーブル2（GA4）のディメンションに「デバイスカテゴリ」を追加し，保存します（図25赤枠内参照）．

次にレポート上部にコントロールボタンを新たに追加して，データソースを先ほどディメンションを追加したもの（図25）を選択し，ディメンション「Device Category」で指標「Url Clicks」と設定します（図26参照）．このコントロールボタンをコピー＆ペーストして，ディメンション「デバイスカテゴリ」で指標「セッション」と選び直したコントロールボタンをもう一つ作ります（図27参照）．

図25．「データの統合」にてテーブル1のディメンションに「Device Category」を追加し，GA4のテーブル2のディメンションに「デバイスカテゴリ」を追加．

図26．ディメンション「Device Category」のコントロールボタン．

図27．ディメンション「デバイスカテゴリ」のコントロールボタン．

図28が，図19のランディングページ×日付のレポートにデバイスカテゴリーのコントロールボタン2種を追加したレポート（ページ）となります．

図28．図19のランディングページ×日付のレポートにデバイスカテゴリーのコントロールボタンを追加したレポート．

サーチコンソールでのデバイスの測定とGA4でのデバイスの測定は紐付いていません．ですから，例えば図28のレポートでデバイスがモバイルだけのデータを見たい場合は，サーチコンソール用に「Device Category」のコントロールボタンで「MOBILE」のみを選択し，GA4用に「デバイスカテゴリ」のコントロールボタンで「mobile」のみを選択した状態にする必要があります．

内容を確認するために，図28のレポートで，Dateを「2025/10/14」に絞り，「[fx]_LPのパス（第2階層以下の表記）」を「/marketing/0701201615/microsoft-rewards-001/」のみに絞った状態にしてみます．すると，図29のように該当するデータが3つ（3行）も出てきました．

図29．図28のレポートで，Dateを「2025/10/14」に絞り，「[fx]_LPのパス（第2階層以下の表記）」を「/marketing/0701201615/microsoft-rewards-001/」のみに絞った結果（クリックすると拡大図が見られます）．

興味深いというかおかしなことに，ページ内に「Device Category」のコントロールボタンがある場合，本例で作成したデータ統合のデータソースを用いたランディングページ×日付のテーブルにディメンション「Query」が存在すると，テーブル内の表示が3種類のデバイスごとに分離され表示される状態になることを確認しています（これはGoogleの仕様による影響だと推測されますが，理由は不明です．サーチコンソールのデータソースを用いたディメンション「Landing Page，Date，Query」で指標「Impressions，Url Clicks」であるテーブルを作ったとき，ページ内に「Device Category」のコントロールボタンがあっても，テーブル内の表示が3種類のデバイスごとに分離されません）．試しに「Device Category」のコントロールボタンで「DESKTOP」のチェックを外してみますと，図30のように図29の1行目にあった（DESKTOPに該当する）データが消えるのが確認できます．なお，図29のテーブルにディメンション「Device Category」を追加した場合は図31のようになり，デバイスごとに分離していることが明確に確認できます．

図30．図29のレポートで「Device Category」のコントロールボタンで「DESKTOP」のチェックを外した結果（クリックすると拡大図が見られます）．

図31．図29のレポートにディメンション「Device Category」を追加した結果（クリックすると拡大図が見られます）．

図32は，図28のレポートのテーブルから「Query」のディメンションを削除して，Dateを「2025/10/14」に絞り，「[fx]_LPのパス（第2階層以下の表記）」を「/marketing/0701201615/microsoft-rewards-001/」のみに絞った状態にしたレポートです．該当データが1つになりました．ということで，デバイスカテゴリーのコントロールボタンを本例のテーブルで使いたい場合は，図33のようにテーブルから「Query」のディメンションを削除してください．

図32．図28のレポートのテーブルから「Query」のディメンションを削除し，Dateを「2025/10/14」に絞り，「[fx]_LPのパス（第2階層以下の表記）」を「/marketing/0701201615/microsoft-rewards-001/」のみに絞った結果（クリックすると拡大図が見られます）．