Google AnalyticsとSearch Consoleのタイムゾーンを認識してデータポータルを活用する

データポータル（注：2022年10月にLookerとデータポータルが統合し，「Looker Studio」に名称が変わりました）でGoogle AnalyticsとSearch Consoleのデータをまとめたレポートを作るとき，タイムゾーンなどを考慮する必要があります．Google Analyticsのタイムゾーンは管理者が設定できますが，Search Consoleのタイムゾーンは固定されています．本記事ではタイムゾーンを考慮する方法などを説明し，それを考慮したGoogle AnalyticsとSearch Consoleのレポートも紹介します．

本記事は，ユニバーサルアナリティクスのGoogle Analyticsを用いてSearch Consoleとのタイムゾーンの話をしていますが，Google Analytics 4（GA4）でも注意するべきことは同様の内容で当てはまります．なぜなら，日本でGA4を使っているユーザーは，通常はGA4の「レポートのタームゾーン」として「日本」を選んでいると思うで，Search Consoleとのタイムゾーン（こちらは固定でユーザーがいじれません）とはズレが生じるからです．

1．はじめに

サイト運用で，Googleなどの検索サイトからの流入（自然検索）においてその流入でユーザーが検索したキーワード（クエリ）の情報は重要な要素です．その昔，検索サイトがSSL化される前は，Google Analyticsでも自然検索からの流入時に使われたキーワード情報が取得できていました．ですがプライバシー保護の観点から，現在ではほぼそのような情報が得られません．

日本ではYahoo！がまだそれなりの検索シェアを占めていますが，自然検索の大半はGoogleです．Googleはプライバシー保護の観点を尊重して自然検索の流入の情報をサイト運用者などに与えるために，Search Consoleというサービスを提供しています．

サイト運用者は，Google AnalyticsとSearch Consoleのデータを相互に比較しながら，運用しているサイトにとって有益な情報を得たいと考えています．そのような場合に便利なツールがGoogleの提供しているデータポータルです．データポータルではAPI接続で，Google Analyticsのデータを使ったレポートやSearch Consoleのデータを使ったレポートの作成が可能です．

さらにデータポータルでは複数のデータソースを使って（さらには統合して）1つのレポートを作ることも可能です．つまり，Google AnalyticsのデータとSearch Consoleのデータを1つのレポート上で扱えるのです．

ただ，そこにはいくつかの注意が必要で，とくにタイムゾーンとデータ反映の特徴を考慮しなくてはいけません．本記事では注意・考慮すべきこと，それらを踏まえた具体的な手法を紹介し，それを考慮したレポートを紹介します．

2．なぜGoogle AnalyticsとSearch Consoleをまとめたデータポータルのレポートを紹介する記事が本サイトになかったのか

本サイトでは，Google Analyticsのデータを使ったランディングページのレポートとSearch Consoleのデータを使ったレポートをいくつか紹介しています．

データポータルで「ランディングページと全てのページのレポート」を作ってみた

データポータルで「GAのランディングページとページの基本的なレポート」を作ってみた

データポータルで「Search Consoleレポート」を作ってみた

しかし，Google AnalyticsのデータとSearch Consoleのデータをまとめた1つのレポートは紹介していません．その理由は，第3節以降で述べるタイムゾーンのこと（それをどのようにうまく処理すべきかを考えていたこと）もあるのですが，デモアカウントのデータの制限や問題が大きな割合を占めていました．具体的には次のような理由です．

理由その1：紹介する（閲覧できるようにする）レポートを作るために使っているGoogleが提供しているデモアカウントに使用制限があるため思うような表現ができないため．レポートをイメージ通りに作るにはデータポータルで計算フィードを活用する必要があるのですが，Search Consoleのデモアカウントはその計算フィードが使えません．

理由その2：Google Analytics（ユニバーサルアナリティクス）のデモアカウントの2020年10月以降のデータに問題があるため．詳しくは記事「データポータルで「Google Analytics流入元レポート（改訂版）」を作ってみた」の第7節「ユニバーサルアナリティクス用のデモデータの問題」を参照してもらいたいのですが，デモアカウントのデータは（おそらく）故意に変えられていて，Googleの自然検索から流入がわからない状況です．そのため，Googleのデモアカウントのデータを使ったGoogle AnalyticsとSearch Consoleのデータを1つのレポートにまとめて表示することが意味を成さない状況です．

上記の理由で例となるレポートを具体的に提示できないため記事自体の作成を躊躇し，結果として記事作成に取りかかることなく時間が過ぎました．

一方で，今年になってデータポータル関連の書籍を見たりやセミナーを受けてみたりしたのですが，Google AnalyticsとSearch Consoleを一緒に使ったレポートがよく例として取りあげられているのを確認しました．ですが，それらはタイムゾーンやデータ反映の特徴を考慮していない（考慮する気配が感じられない）ものしかなく，引っかかるものがありました．

その「引っかかるもの」を解消するには，例示するデータに問題があることを注意書きして大まかな内容（構成）でもまとめたものを作成したほうがいいと思いこの記事を書くことにしました．

3．タイムゾーンの違いとデータ反映の特徴

本サイトに訪れ記事を閲覧している方の多くは日本在住で，日本人を対象にしたサイトを運用などしているのではないかと思います．そのサイトにGoogle Analyticsを導入しているならば，そのタイムゾーンは日本標準時間（JST：Japan Standard Time）に設定されているでしょう．該当するサイトのGoogle Analyticsのタイムゾーンは，ビューの設定画面の「タイムゾーンの国や地域」で確認できます（図1参照）．

図1．Google Analyticsのビューの「タイムゾーンの国や地域」

一方で，Search Consoleにはタイムゾーンを設定するようなところは存在しません．実はSearch Consoleのタイムゾーンは「太平洋夏時間（PDT：Pacific Daylight Time）」に固定されています（図2参照）．「太平洋夏時間」とは，主にアメリカ西海岸の標準時である「太平洋標準時間（PST：Pacific Standard Time）；アメリカとカナダでは総称的に太平洋時間（PT）と呼ばれる」の夏時間のことです．日本標準時間と太平洋夏時間との時差は16時間です（日本のほうが16時間進んでいます）．

図2．「Search Consoleのタイムスタンプデータは太平洋夏時間に基づきます」という記述

つまり，タイムゾーンが日本標準時間のGoogle AnalyticsとSearch Consoleではそれぞれのデータの日付が必ずしも一致しないのです．例えばSearch Consoleで「2021年11月2日」にクリックされと記録されたデータに対応するGoogle Analyticsの日本標準時間のビューに記録されたGoogle自然検索からの流入は，「2021年11月2日」と「2021年11月3日」のどちらかに記録されたデータに該当します．

Search Consoleのデータは，リアルタイムで見ることはできません．以前は3日前のデータからしか見ることができませんでしたが，現在は改良されたようで期間の選択で「最新日」として前日を選ぶことができ，前日のデータがSearch Consoleの画面上で見ることできるようになっています（図3参照．赤枠内に「日付はすべて太平洋時間（PT）で記録されています」と書かれていますが，上述したようにこの太平洋時間は太平洋夏時間に該当します）．

図3．Search Consoleの画面上での期間選択

データポータルとSearch ConsoleをAPI接続してレポートを作った場合，データポータル上に反映できるデータは（2021年11月現在）3日前のものまでとなっています．日本標準時間と太平洋夏時間との時差は16時間であるため，3日前のSearch Consoleのデータがデータポータルのレポートに確実に反映されるのは日本時間の16時以降であると思われます．

「思われます」としたのは確証というか検証をしっかりしていないからです．日本標準時間の16時前（午前中）であっても3日前のデータが反映されている場合があることを確認していますし，16時ぐらいにならないと反映されていない場合も確認しています．

データポータルにおけるSearch Consoleの「データ更新頻度」は，公式ヘルプにて「Google 広告、Google アナリティクス、キャンペーン マネージャー 360、Search Console、YouTube アナリティクスなどの Google のマーケティング サービスと測定サービスは 12 時間ごとに更新されます。この設定は変更できません。」と書かれています（図4参照）．つまり，頻度を変更できなく12時間ごととなっています．その12時間のタイミングがいつなのかまではちゃんと検証していません（興味がある方は検証してみてください）．

図4．データポータルのヘルプ「データ更新頻度」

「データポータル上に反映できるデータは（2021年11月現在）3日前のものまで」を確認できるように，記事『データポータルで「Search Consoleレポート」を作ってみた』で紹介したレポートの2ページ目の内容を改良した

[確認用] Google AnalyticsとSearch Consoleレポート・1ページ目

を用意しました．レポートの期間は，期間設定のコントロールボタンでアクセスした日（閲覧日）に対して「過去7日間（今日を除く）」にしています．レポート上部にある期間設定のコントロールボタンの日付と，グラフやテーブル（Date降順）の日付を比べると，コントロールボタンで指定している日付のデータより2日前（データ更新のタイミングによっては3日前）のデータからしか表示されていないことが確認できます（図5参照）．同様のレポートを自身のサイトでも作れば，やはり「データポータル上に反映できるデータは3日前のものまで」ということが確認できると思います．

図5．コントロールボタンで指定している日付のデータより2日前のデータまでしか表示されていない

4．データポータルの期間設定のコントロールボタン

データポータルで，Google AnalyticsやSearch Consoleのレポートを作ったとき，通常はその内容に対してデータ期間を変更出来るような期間設定のコントロールボタン（図5参照）をページ内に追加します（もちろん，このような期間設定のコントロールボタンの設置は必須でありません．各テーブルやグラフごとに表示期間を設定できます）．

さて，Google Analyticsのデータを使ったテーブル（グラフ）とSearch Consoleのデータを使ったテーブル（グラフ）をデータポータルで1つのページに配置し，そのページに期間設定のコントロールボタンを配置した場合はどうなるでしょうか？その期間設定のコントロールボタンに連動して，Google AnalyticsのテーブルとSearch Consoleのテーブルのデータが変化します（もちろん，期間設定のコントロールボタンと連動させなくすることもできます）．

一方で，例えばデバイス（アクセスしているデバイスがPCかタブレットかモバイルか）を絞れるようにするコントロールボタンは，Google Analyticsのデータ用とSearch Consoleのデータ用で別々に用意する必要があります．ですが，期間設定のコントロールボタンは，（通常の設置で）そのページ全てに影響を与えるのです．これは，

[確認用] Google AnalyticsとSearch Consoleレポート・2ページ目

で確認できます．この2ページ目は1ページ目のSearch Consoleのデータを使ったグラフを削除し，下部にGoogle Analytics（のデモアカウント）のランディングページのテーブルを追加したものです．上部にある期間設定のコントロールボタンを操作すると，ページ内すべてのテーブルの内容が連動して変化することが確認できます．

一方で，同様に上部にあるDevice Category（デバイスカテゴリ）のコントロールボタンを操作してもSearch Consoleのデータを使ったテーブルのみが連動して変化することが確認できます．これは，このDevice Categoryのコントロールボタンのデータが，Search Consoleのデータのディメンション「Device Category」で作ったためです．Google Analyticsでデバイスカテゴリを絞りたいならば，Google Analyticsのデータのディメンション「デバイス カテゴリ」でコントロールボタンを作る必要があります．

第3節で説明しましたが，日本標準時間に設定しているGoogle Analyticsのビューで記録されている日付と，Search Consoleのデータとして記録されている太平洋夏時間の日付は一致しない場合があります．したがって，“[確認用] Google AnalyticsとSearch Consoleレポート・2ページ目”のようなSearch ConsoleとGoogle Analyticsを1つのページ内で表示されるようなレポートを作り，期間設定のコントロールボタンを使って特定の日を指定して，ランディングページAがどのようなクエリ（検索時にユーザーが入力したキーワード）で表示されクリックされたかをSearch Consoleのデータで表示させ，同時にGoogle AnalyticsのデータでランディングページAのGoogle自然検索からの流入がどのような行動をとったのか（直帰したのか，どれぐらいのページを閲覧したのか，CVしたのか）を対で表示させた場合，Search ConsoleとGoogle Analyticsとで日付が違っているということがありえます．

また，“[確認用] Google AnalyticsとSearch Consoleレポート・2ページ目”では期間設定がデフォルトでアクセスした日（閲覧日）に対して「過去7日間（今日を除く）」にしてあります．この場合，第3節で述べたようにSearch Consoleのデータは「データポータル上に反映できるデータは3日前のものまで」なのでページ内のテーブルのDateにあるように3日前のデータまでとなっています．一方で，Google Analyticsのデータは期間設定に連動して「過去7日間（今日を除く）」なので，前日までのデータを扱っています．つまりこのレポート・2ページ目のレポートはすでに違う期間のデータとなっているのです（図6参照）．

図6．レポート・2ページ目の期間設定と各テーブルの日付の関係

なお，“[確認用] Google AnalyticsとSearch Consoleレポート”におけるGoogle Analyticsのデータはデモアカウントのデータです．Search Console側のクリックでの流入のデータとGoogle Analytics側の流入データを比較する場合は，Google Analytics側のデータをGoogle自然検索（参照元/メディアが「google / organic」）に絞る必要があります．しかし，第2節で述べたようにデモアカウントのデータに問題があり，正確な「参照元/メディア」が紐付いていなく，ほとんどの流入が「(direct) / (none)」になっています．つまり，「google / organic」でデータを絞ると表示するデータがなくなってしまいます．したがって，“[確認用] Google AnalyticsとSearch Consoleレポート”におけるGoogle Analyticsのデータは，すべての流入のデータを使っています．そのためこのデモデータでは，Search ConsoleとGoogle Analyticsのデータを比べるというようなことをしても意味をなしません．

以上のような理由から，Google Analyticsのデータを使ったテーブル（グラフ）とSearch Consoleのデータを使ったテーブル（グラフ）をデータポータルで1つのページに配置したとき，期間設定のコントロールボタンはその使い方には注意が必要です．

5．フィードで「太平洋夏時間」のディメンションを作成する

それでは，Search ConsoleとGoogle Analytics（以下，日本標準時間のビューを対象として話を進めます）とのタイムゾーンの違いをどのように処理してデータポータルで，互いのデータを比較しやすいようにするかを紹介します．

その方法とは，“データポータルの計算フィードでGoogle Analyticsのデータを使った新たなディメンション「太平洋夏時間」を作成する”です．

サイト運用が日本標準時間を基準にしているならば，Search Consoleの日付のデータ（ディメンション「Date」）を日本標準時間に変更したほうが便利なのですが，それは残念ながらできません．理由は，Search Consoleのディメンション「Date」には，年月日だけで時間が含まれていないからです．したがって，該当する時間がわからないので，データポータルの計算フィードでは時差（16時間）の調整ができないのです（デモアカウントはこの計算フィードがそもそも使えません）．したがって，Google Analyticsのデータを使って，データポータルの計算フィードで太平洋夏時間を算出します．

データポータルの計算フィードで，Google Analyticsのデータを使い，時差16時間（日本標準時間と太平洋夏時間との時差は16時間で，日本の方が16時間進んでいる）をなくした年月日時間を求めるには，DATETIME_SUB関数を使います．Google Analyticsのディメンション「日付、時間、分,」を用いて，

DATETIME_SUB(日付、時間、分, INTERVAL 16 HOUR)

とし，フィードを「[fx]「日付、時間、分」から16時間減算」と名付け保存します（図7参照）．

図7．フィード「[fx]「日付、時間、分」から16時間減算」

上記の計算を，Google Analyticsのデモアカウントで再現してみたのが，

[確認用] Google AnalyticsとSearch Consoleレポート・3ページ目

のTable 1です．Table 1のディメンション「日付、時間、分」の値（年月日時間）に対して「[fx]「日付、時間、分」から16時間減算」の値が16時間前の日付と時間になっていることが確認できます（図8参照）．

図8．Table 1のディメンション「日付、時間、分」の値（赤枠内「2021/11/09 16:02」）に対して「[fx]「日付、時間、分」から16時間減算」の値（赤枠内「2021/11/09 0:02:00」；こちらは秒表示があることに注意）が16時間前の日付と時間になっていることが確認できる

なお，“[確認用] Google AnalyticsとSearch Consoleレポート・3ページ目”の各Tableはディメンション「ランディングページ」が主軸となっていますが，「/store.html」を含みかつ「/quickview」を含まないものに絞るフィルタ（図9参照）を与えています（データ多いのでわかりやすくするために特定のページに絞りました）．また，このデモアカウントのビュー（1Master View）のタイムゾーンはもちろん日本標準時間ではありません．実際は「ロサンゼルス時間」でグリニッジ標準時から8時間遅れている太平洋標準時間です．

図9．[確認用] Google AnalyticsとSearch Consoleレポート・3ページ目のTableに与えているフィルタ

Search Consoleのディメンション「Date」は年月日のみで時間はありませんので，時間の単位を含む上記で作ったディメンション「[fx]「日付、時間、分」から16時間減算」のままでは細かすぎます（Search Consoleのデータと対となるGoogle Analyticsのデータをまとめる目的では，時間の単位は必要ありません）．そこで，DATE関数をDATETIME_SUB関数に組み合わせて計算フィードで，

DATE(DATETIME_SUB(日付、時間、分, INTERVAL 16 HOUR))

として，このフィードを「[fx] 太平洋夏時間」と名付け保存します（図10参照）．

図10．フィード「[fx] 太平洋夏時間」

“[確認用] Google AnalyticsとSearch Consoleレポート・3ページ目”のTable 2で，ディメンション（フィード）「[fx] 太平洋夏時間」の値が確認できます．Table 2のディメンション「日付」はオリジナルの年月日のデータで，この日付の同じ値（年月日）に対してディメンション「[fx] 太平洋夏時間」の値が2種類存在することが確認できます（図11参照）．

フィード「[fx] 太平洋夏時間」は，その名の通りGoogle Analyticsの日本標準時間のタイムゾーンのビューの日付（年月日）データを太平洋夏時間のタイムゾーンの日付に変更したものなので，これをSearch Consoleのデータとの日付合わせに使います．

図11．Table 2のディメンション「日付」に対するディメンション「[fx] 太平洋夏時間」．赤枠内で日付「2021/11/09」に対して[fx] 太平洋夏時間に「2021/11/09」と「2021/11/08」の2つがあることが確認できる

6．Google AnalyticsとSearch Consoleのデータを使ったレポート

実際にGoogle AnalyticsとSearch Consoleのデータを1つのページにまとめたデータポータルのレポートを紹介します．作り方はいろいろあると思いますが，Search Consoleのデータではディメンション「Landing Page」と「Query」と「Date」が軸のテーブルを作り，Google Analyticsのデータではディメンションが「ランディング ページ」と「日付」と「[fx] 太平洋夏時間」が軸のテーブルをつくり，それらを上下に並べたレポートを

[確認用] Google AnalyticsとSearch Consoleレポート・4ページ目

のようにデモアカウントのデータを使って作ってみました．このレポートのSearch Consoleに関係するテーブルは記事『データポータルで「Search Consoleレポート」を作ってみた』で紹介したレポートの４ページ目の下段のテーブルが元となっています．

何度も述べています（レポート内にも注意書きしています）が，このレポートで使っているGoogle Analytics（ユニバーサルアナリティクス）のデモデータの問題で，Google AnalyticsのランディングページのデータはGoogle自然検索だけの流入になっていません．したがってあくまでもこのレポートはどのような構成・使い方をするかのイメージを得るものとして見てください．

データが多いので見やすくするためにこのレポートでは，Search ConsoleのテーブルにはLanding Pageが「https://shop.googlemerchandisestore.com/store.html」のみを含むものみを集めるフィルタを与え（図12参照），Google Analyticsのテーブルにはランディングページが「/store.html」を含むのみを集めるフィルタを与えています（図13参照）．

図12．[確認用] Google AnalyticsとSearch Consoleレポート・4ページ目のSearch Consoleのテーブル用のフィルタ

図13．[確認用] Google AnalyticsとSearch Consoleレポート・4ページ目のGoogle Analyticsのテーブル用のフィルタ

レポート上部にある期間設定のコントロールボタンでは「3日前から16日前の14日間」をデフォルトで選んでいます（テータ反映の特徴を考慮すると，デフォルトの期間設定を閲覧日に対して3日前，もしくは確実性をみて4日前までにするような設定すべきなので，詳細設定でこのようにしました）．

ある日のGoogle自然検索での特定ページ（上記のサンプルではPathが「/store.html」を含むランディングページとフィルタで固定していますが，通常はSearch ConsoleとGoogle Analyticsそれぞれでランディングページのコントロールボタンを用意してそれで見たいページを絞るようにします）に関係したクエリとそのインプレッション数とクリックされた数，そしてそれら流入からサイト内でどのような行動だったかを知ることができるようになります．

「ある日」を指定するには，Search Consoleのテーブルでは「Date」のコントロールボタンで行い，Google Analyticsのテーブルでは「[fx] 太平洋夏時間」で行います．図14は，「Date」と「[fx] 太平洋夏時間」のコントロールボタンで「2021/11/02」を選択した状態です（図14では見にくいのでこのページを出力したpdfファイルも用意しました．“ [確認用] Google AnalyticsとSearch Consoleレポート・4ページ目2021年11月2日のデータ ”からダウンロードできます）．

図14．太平洋夏時間「2021/11/02」に絞った状態

“[確認用] Google AnalyticsとSearch Consoleレポート・4ページ目”はデータの問題でSearch Consoleのテーブルの「Url Clicks」の数とGoogle Analyticsのテーブルの「セッション」の数は当然異なっていますが，自分のサイトのデータで同様なレポートを作った場合にこれら数値がピッタリ合うことは期待しない（ピッタリ合わないことを気にしない）のがいいと思われます．あくまでも有効そうなキーワードの傾向をつかむ（推測する）ためのデータとして活用を考えるべきだと思います．

7．おわりに

本記事では，Google AnalyticsとSearch Consoleのデータを1つのページにまとめたデータポータルのレポートとして太平洋夏時間の日付を使った“[確認用] Google AnalyticsとSearch Consoleレポート・4ページ目”を紹介しました．

このようなGoogle AnalyticsとSearch Consoleのデータをまとめたレポートの表現方法はもちろん他にもあります．そのひとつがデータ統合です．つまり，Google AnalyticsとSearch Consoleのデータを統合してひとつのテーブルやグラフで使う方法です．この場合，デフォルトのデータだけではちょっと無理です．ランディングページの値をキーでデータ統合するにも，Search Consoleのランディングページの表記はURL（デモデータだと「https://shop.googlemerchandisestore.com/store.html」という表記）であり，Google AnalyticsではPathのみの表記（デモデータだと「/store.html」というような「https://shop.googlemerchandisestore.com/」が省略されたもの）となっています．このような場合は，データポータルだとREGEXP_EXTRACT関数を使ってURLをPathのみとした新たなディメンションを作るなどの処理がまず必要です（Search Consoleのデモアカウントでは計算フィードが使えないのでこのようなことができません）．

またURLやPathにパラメータがつくこともあります（例えば，図14では，Search ConsoleのLanding Pageには「?vid=20180201712」などのようなパラメータがあるのが確認できます）．データ結合では，このようなパラメータも取り除く処理も必要です（このような処理ではREGEXP_REPLACE関数が使えますが，パラメータの付き方はサイトでも違ってくるので個々に対応を考える必要があります）．

上記のようにPathをデータ統合のキーで使うには処理が大変な面もあるので，Pathに含まれるカテゴリ（本サイトならば「tools」や「marketing」など）を使ってCASE関数でカテゴリ毎に集計したディメンションを使う方法も考えられます．

ともかくSearch ConsoleとGoogle Analyticsのデータ統合をするならば，日付（年月日）を太平洋夏時間に合わせる処理は必須のはずです．さらにSearch Consoleのデータがデータポータルに反映されるのが3日前からということを考慮して，レポートの期間設定（のコントロールボタン）を使う必要があります．しかし，このことをちゃんと述べているような情報はあまり見かけない気がします（書籍でも事業会社のオウンドメディアなどでも見かけた記憶がありません）．

プライバシー保護の観点からSearch ConsoleのデータとGoogle Analyticsのデータが完全に紐付けられるようにはなっていないのでもともと正確な情報を得られない面もあるのですが，タイムゾーンの違いはちゃんと認識して扱うべきでしょう（日本標準時間だと16時間も差があるのですから）．