日本と時差が16時間あるGoogleサーチコンソールのタイムゾーンの年月日のデータをGA4に記録させる方法

Google Analytics 4（日本時間）とGoogleサーチコンソールのタイムゾーンの違いにより，それらの間にはデータの日付にズレが生じます．本記事では、このズレを解消するため，GoogleタグマネージャーのカスタムJavaScriptとGA4のカスタムディメンションを活用し，サーチコンソールのタイムゾーンの年月日をGA4のデータに正確に記録・可視化する具体的な手順を紹介します．

1．はじめに

日本国内でGoogle Analytics 4（以下，GA4）を使っている場合，そのレポートのタイムゾーンとして「日本」の「（GMT+9:00）日本時間」を設定している方がほとんどでしょう．また，GA4のデータストリームでウェブストリームを選びウェブサイトの計測をしている場合，多くの場合はGoogle検索を意識しているでしょう．その場合，Googleサーチコンソールを設定し，さらにはGA4とリンクさせる設定をしていると推測します．

さて，そのようにGoogleサーチコンソールを使っている場合，サーチコンソールのタイムゾーン，つまりサーチコンソールのタイムスタンプデータがどのタイムゾーンに基づいているか，正しく認識しているでしょうか．GA4の場合はプロパティ作成時に「レポートのタイムゾーン」を選択する画面が出てきます（図1参照）し，管理画面の「プロパティの詳細」でも確認・変更が可能です（図2参照）．

図1．GA4のプロパティ作成時に「レポートのタイムゾーン」を選択する画面．

図2．GA4の管理画面の「プロパティの詳細」．

ちなみに，GA4の初期設定画面では「レポートのタイムゾーン」の説明として「レポートに使用するタイムゾーン。このタイムゾーンは、データの発生した地域のタイムゾーンとは無関係です。タイムゾーンを変更すると、変更はその時点から収集されたデータに適用されます。」と表示されます（図3参照）．

図3．GA4の初期設定画面での「レポートのタイムゾーン」の説明．

一方で，Googleサーチコンソールでは，初期設定でGA4の「レポートのタイムゾーン」というような表示が出てきませんし，設定内にもタイムゾーンに関係する項目はみあたりません（図4参照）．

図4．Googleサーチコンソールの設定画面．

なぜなら，Googleサーチコンソールのタイムゾーンは「太平洋夏時間（PDT：Pacific Daylight Time）」に固定されているからです（図5参照）．したがって，サーチコンソールではタイムゾーンを設定するような箇所がありません．なお，「太平洋夏時間（PDT：Pacific Daylight Time）」とは，主にアメリカ西海岸の標準時である「太平洋標準時間（PST）」の夏時間にあたります．日本標準時間（JST）と太平洋夏時間（PDT）との時差は16時間です．つまり，日本で午後4時（16時）になると，太平洋夏時間の地域では同日の午前0時になります．

図5．サーチコンソールのタイムスタンプデータが説明されている箇所．

例えば、レポートのタイムゾーンを「日本」に設定しているGA4で計測された2025年10月20日のGoogle自然検索からの流入データは，サーチコンソールのレポート上では2025年10月19日，あるいは2025年10月20日のデータと対応することになります（注意：実際にはいろいろなものが関係するので，ある特定の流入を取り出した場合に必ずこのように対応するとは言えません）．

サーチコンソールはタイムゾーンが太平洋夏時間に固定されていること（不便さ）を説明しましたが，その他にも不便を感じることがタイムスタンプ関連であります．それはサーチコンソールのタイムスタンプデータは年月日であり，時間の情報がないのです（サーチコンソールの「Date」は太平洋夏時間の日付までしか格納されていません）．このため、タイムゾーンがサーチコンソールと異なる地域では，サーチコンソールのデータだけでは，現地の日付との間に生じる具体的なズレの大きさを把握することが困難です．

取得データ期間を長期にして，タイムゾーンの違いで生じるこのズレを誤差として処理する（無視する）のも一つの方法です．しかし，日本時間との16時間の時差は無視できないと感じ，このズレを少しでも緩和したいと考える方もいるでしょう．

そこで本記事ではGA4とGTMを使って，GA4のデータでサーチコンソールの日付をGA4側で再現する（探索レポートでそれを見られるようにする）ことで，このズレを実際に可視化して確認できるようにします．このようなデータを得ることで，サーチコンソールとGA4タイムスタンプデータで生じるズレの緩和に役立つような気づきがえられるかもしれません．

2．GTMの設定

GA4の計測でGoogleタグマネージャー（以下，GTM）を使っていることを前提に話を進めます．

まず対象となるGA4のGoogleタグがあるGTMのワークスペースにて，タイムスタンプ用の変数を設定します．「変数 > ユーザー定義変数」で「新規」のボタン（図6の赤枠内参照）をクリックして，「変数タイプを選択」の一覧からページ変数の「カスタム JavaScript」を選択します（図7の赤枠内参照）．カスタム JavaScriptのコードとして以下のコードを入力し，名前を付けて保存します（図8参照）．

function() {
   var tz = 7, // PDT
       now = new Date(Date.now() - (tz * 60 - new Date().getTimezoneOffset()) * 60000),
       pad = function (n){return n<10 ? '0'+n : n};
   return now.getFullYear()
       + '/' + pad(now.getMonth()+1)
       + '/' + pad(now.getDate());
}

このコードで，太平洋夏時間（PDT：Pacific Daylight Time）の年月日が「2025/10/19」のような形式で取得できます．本例では，この変数を「custom_date_PDT[アメリカ太平洋夏時間の年月日]」と名付けました．

図6．GTMのワークスペースで「変数 > ユーザー定義変数」から「新規」のボタンをクリック．

図7．ページ変数「カスタム JavaScript」を選択．

図8．GTMで変数「custom_date_PDT[アメリカ太平洋夏時間の年月日]」を作成．

サーチコンソールのタイムスタンプデータは年月日のため，それに合わせて年月日のみが取得できるようにします．したがって，上記のコードを使った設定で完了します．ですが，本当に太平洋夏時間の年月日であるかをちゃんと確認しておきたい方もいるかもしれません．そのような方は，太平洋夏時間の年月日時まで取得する用の変数を，上記とは別に設定してもよいでしょう．そこで本例では，その太平洋夏時間の年月日時のデータを取得するために下記のコードを使い，「custom_timestamp_PDT[アメリカ太平洋夏時間]」と名付けた変数を別に作ってみることにします．

function() {
    var tz = 7, // PDT
        now = new Date(Date.now() - (tz * 60 - new Date().getTimezoneOffset()) * 60000),
        pad = function (n){return n<10 ? '0'+n : n};
    return now.getFullYear()
        + '/' + pad(now.getMonth()+1)
        + '/' + pad(now.getDate())
        + ' ' + pad(now.getHours());
}

このコードを使うと2025年10月19日11時が「2025/10/19 11」の形式で取得できます（図9参照）．繰り返しになりますが，この変数「custom_timestamp_PDT[アメリカ太平洋夏時間]」はあくまでも確認用なので，必須ではありません．

図9．GTMで変数「custom_timestamp_PDT[アメリカ太平洋夏時間]」を作成．

次に，GTMのワークスペースのタグに移動して，対象となるGA4のGoogleタグを開きます．そこで，「共有イベントの設定」の「イベントパラメータ」の「パラメータを追加」ボタンをクリックして，新たなイベントパラメータ「custom_date_pdt」を追加します．「custom_date_pdt」は任意に変更可能ですが，GA4で使われているイベント名などと重複しないようにします．そして，値は上記で作った変数の「custom_date_PDT[アメリカ太平洋夏時間の年月日]」を選択します（図10の赤枠内参照）．

図10．GTMでGA4のGoogleタグにイベントパラメータ「custom_date_pdt」を追加．

もしも確認用の太平洋夏時間の年月日時の値も取得するなら，同様に「パラメータを追加」で同様に新たなイベントパラメータを作ります．例えば「イベントパラメータ」を「custom_timestamp_pdt」とし，値に変数の「custom_timestamp_PDT[アメリカ太平洋夏時間]」を選択します（図11赤枠内参照）．

上記のパラメータの追加が終わったら，Googleタグを保存します．

図11．GTMでGA4のGoogleタグにイベントパラメータ「custom_date_pdt」と「custom_timestamp_pdt」を追加した状態．

さて，Googleタグには，「構成パラメータ」と「共有イベント設定 > イベントパラメータ」の2箇所にパラメータを追加できる箇所があることが気になった方がいるかもしれません．今回の場合，このどちらに追加しても計測は同じようにできます．ですが，パラメータの値がセッションやイベントごとに変化するものは，「共有イベント設定 > イベントパラメータ」に登録するのが適切とされているとのことです．このようなGoogleタグの設定に関しては，下記のアユダンテさんの記事が参考になります．

[GTM] 新しいGA4のタグ設定の仕方
https://ayudante.jp/column/2023-10-19/17-00/

また，このアユダンテさんの記事を参考にすると，GTMの「変数」にある「Google タグ: イベントの設定」を使うと，パラメータをまとめた形式にすることができることがわかります．これは，上記の「custom_date_pdt」と「custom_timestamp_pdt」のような複数のパラメータを追加したい場合に便利な機能です．そこで，この機能を使った設定も示しておきたいと思います．「変数 > ユーザー定義変数 > 新規」から，「変数タイプを選択」の一覧にあるユーティリティの「Google タグ: イベントの設定」を選び（図12の赤枠内参照），その中でイベントパラメータとして「custom_date_pdt」と「custom_timestamp_pdt」をGoogleタグのときと同様に追加して（図13参照），名前を付けて保存します（この例では，「custom_time」と名付けました）．そして，該当するGA4のGoogleタグにて，「共有イベントの設定」内にある「イベントの設定変数」で該当する「Google タグ: イベントの設定」の変数を選びます．本例だと「custom_time」としたので，それが選択肢として現れるのでそれを選びます（図14参照）．そして，Googleタグを保存します（このイベント設定変数を使った方法では，前述したような「custom_date_pdt」と「custom_timestamp_pdt」を「共有イベント設定 > イベントパラメータ」に個々に追加する必要はありません）．

図12．GTMで変数の一覧にあるユーティリティの「Google タグ: イベントの設定」を選択．

図13．ユーティリティ「Google タグ: イベントの設定」でイベントパラメータとして「custom_date_pdt」と「custom_timestamp_pdt」を追加して「custom_time」と名付ける．

図14．GA4のGoogleタグにて「イベントの設定変数」を使う場合の設定．

これで，GTM側の設定は完了です．あとは，プレビューで実際にGTMにて変数の値がとれているかを確認して，問題が無ければ公開します．

図15．プレビューで実際にGTMにて変数の値を確認．

3．GA4の設定

GTMで設定したイベントパラメータをGA4で見るために，管理画面の「データ表示 > カスタム定義」でカスタムディメンションを設定します（図16参照）．

図16．GA4でカスタムディメンションを設定．

本例では，太平洋夏時間の年月日に関するカスタムディメンションとして，ディメンション名「custom_date_pdt」，範囲「イベント」，説明「アメリカ太平洋夏時間の年月日」，イベントパラメータ「custom_date_pdt」として作りました（図17参照）．

また，この例では確認用として太平洋夏時間も登録したのでそちらのカスタムディメンションとして，ディメンション名「custom_timestamp_pdt」，範囲「イベント」，説明「アメリカ太平洋夏時でのタイムスタンプ（年月日時）」，イベントパラメータ「custom_timestamp_pdt」も作りました（図18参照）．

後は，データが貯まるのを待ちます．

図17．GA4でカスタムディメンション「custom_date_pdt」を作成．

図18．GA4でカスタムディメンション「custom_timestamp_pdt」を作成．

4．GA4の探索機能を使ってデータを確認

GA4の探索機能を使って，取得した「custom_date_pdt」や「custom_timestamp_pdt」を確認してみましょう．探索の「空白」のテンプレートを使って，テーブルを作成します．

まず1つめのテーブルには，ディメンションに「イベント名，日時（YYYYMMDDHH），日付，custom_timestamp_pdt，custom_date_pdt」，値に「イベント数」を選択しました（「イベント名，日時（YYYYMMDDHH），日付」はデフォルトで存在するディメンションです．図19参照）．イベント名「page_view」で，「日時（YYYYMMDDHH）」が16時あたりのデータを確認してみます（図20参照）．

図19．GA4の探索機能で作ったディメンション「イベント名，日時（YYYYMMDDHH），日付，custom_timestamp_pdt，custom_date_pdt」で値「イベント数」のテーブル．

図20．図18のテーブルのイベント名「page_view」で「日時（YYYYMMDDHH）」が16時あたりのデータ．

図20は日付が2025年10月11日のデータです．例えば，143行目の「page_view」のイベントは「日時（YYYYMMDDHH）」が「2025101115」なので，GA4のタイムスタンプデータが2025年10月11日15時として記録されていることが確認できます．一方で，そのときの「custom_timestamp_pdt」は「2025/10/10 23」なので2025年10月10日23時を表しています．つまり，「custom_timestamp_pdt」の記録がちゃんと日本時間と16時間ズレているのが確認できます．したがって，このときの年月日は「custom_date_pdt」でも示すように「2025/10/10」です．

次に，図20の144行目の「page_view」のイベントは「日時（YYYYMMDDHH）」が「2025101116」なのでGA4のタイムスタンプデータが2025年10月11日16時とわかります．そのときの「custom_timestamp_pdt」は「2025/10/11 00」なので2025年10月11日0時を表しています．日本との時差16時間により，太平洋夏時間でも日付が変わったことが確認できます。もちろん「custom_date_pdt」は「2025/10/11」となっています．

「custom_date_pdt」はちゃんと太平洋夏時間の年月日を反映していることが確認できました．

次に，ディメンションに「ランディングページ，セッションの参照元/メディア，日時（YYYYMMDDHH），日付，custom_date_pdt」，値に「セッション」を選択したテーブルを作ってみました（図21参照．このテーブルのデータは本サイトのものを使っています）．ただし，セグメントとして「セッションの参照元/メディア」が「google/organic」と完全一致する条件で「Googleの自然検索」を適用し，さらにフィルタでランディングページが「(not set)」と完全一致しない条件を適用しています（Googleの自然検索だけにする方法もセグメントでなくフィルタを使ってもいいでしょう）．

図21．GA4の探索機能で作ったディメンション「ランディングページ，セッションの参照元/メディア，日時（YYYYMMDDHH），日付，custom_date_pdt」で値「セッション」のテーブル．

先ほど同様に，2025年10月11日の16時あたりのデータを見てみました．図22の29行目のランディングページのセッションはGA4では「2025101115」であり，「custom_date_pdt」では「2025/10/10」が異なっていることが確認できます．つまり，このGoogle自然検索で始まったこのセッションはサーチコンソールの太平洋夏時間の日付だと「2025/10/10」であるが，タイムゾーンが日本のGA4では「2025/10/11」であったということです．

図22．図20のランディングページに関係する各データを確認．

GA4の「セッションの参照元/メディア」の定義上，このセッションが実際にGoogleの自然検索から始まったかどうかは断定できません（例えば，この時間より前にGoole自然検索から流入して，セッションが一度切れた後に，ブックマークなどから流入したセッションかもしれません．つまり，直接の訪問で開始されたセッションは，そのユーザーの最後に確認された「参照元/メディア」に関連付けられるので，このセッションが本当に直前にGoogleで検索した結果を利用したモノかはこれだけではわかりません）が，ともかくこのようにサーチコンソールとのタイムスタンプデータとGA4のタイムスタンプデータとの違いによってズレがどれぐらいあるかが確認できるものが作れたと思います．

あとは，それぞれの環境に合わせて，このデータを用いて検討を進めるのが最善です．検討の結果，前述の通り誤差として処理することに決めても問題ありません．また，今後なにか特別な出来事（特徴的な流入など）があって，それを調べるのにこの太平洋夏時間でとったデータが活用できるかもしれません．

5．Looker Studioでテーブルを作る場合の注意点など

4節のGA4の探索機能で作ったテーブルと同じものはLooker Studioでも当然作れます．ただし，データソースとなるGA4は，「custom_date_pdt」や「custom_timestamp_pdt」を作った後のGA4に接続して新たに追加してください．

また，「custom_date_pdt」の値はテキスト形式（タイプが「テキスト」）となっています（図23の赤枠内参照）．なお，「custom_date_pdt」の値を「2025/10/11」のような表示にしたのは，Looker StudioでのGA4の「日時（YYYYMMDDHH）」や「日付」の表示に合わせたからです．4節で示したように，GA4の探索機能のテーブルで「日時（YYYYMMDDHH）」や「日付」を使うと，「2025101115」や「20251011」のように表示されます．ですが，Looker Studioのテーブルで「日時（YYYYMMDDHH）」や「日付」を使うと，「2025/10/11 15」や「2025/10/11」のように表示されます（図24参照）．

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

図24．Looker StudioでのGA4の「日時（YYYYMMDDHH）」や「日付」の表示．

「custom_date_pdt」の値を，テーブルで単純に見るために表示する分にはそのままのテキスト形式で問題ありません．ですが，日付のデータとして活用するには，計算フィールドで関数を使ってデータを日付形式（タイプを「日付」）に変更する必要があります．その場合，PARSE_DATE関数を使って，

PARSE_DATE("%Y/%m/%d",custom_date_pdt)

のように計算させることで，「custom_date_pdt」の値を日付形式（タイプを「日付」）に変更します（図25と26参照）．

＜参考＞ Looker Studio：PARSE_DATE
https://cloud.google.com/looker/docs/studio/parsedate?hl=ja

図25．PARSE_DATE関数を使って「custom_date_pdt」の値を「日付」タイプに変換．

図26．タイプが「日付」になっているのを確認

6．おわりに

本記事では，GA4とGTMを使って，GA4のデータでサーチコンソールの太平洋夏時間の日付をGA4側で再現する（探索レポートでそれを見られるようにする）方法を紹介しました．ただし、この方法はGA4の計測データとしてサーチコンソールのタイムゾーンの日付データ（注：この方法で取得したデータはテキスト形式の値）をどうしても取得したい場合にのみご活用するのがよいでしょう．

例えばLooker Studioで，GA4のGoogleの自然検索の流入データでサーチコンソールの太平洋夏時間の日付を対応させたテーブルを作りたい，さらにはサーチコンソールとGA4のデータ結合を行いたいという場合は，GA4がデフォルトで取得しているデータ「日時（YYYYMMDDHH）」を使えばそれが可能です（Looker Studioの関数を使えば，GA4のデータ「日時（YYYYMMDDHH）」から太平洋夏時間の日付を作り出せます）．そこらへんのことは「Google AnalyticsとSearch Consoleのタイムゾーンを認識してデータポータルを活用する」で書いたりしていますが，この記事はGoogle Analyticsがユニバーサルアナリティクスのときの内容なので，そのうちLooker Studioを使ったサーチコンソールとGA4のデータ結合の方法として新たな記事を書いてみようかと考えています．