2026年9月2日(水)
データ分析

GAのコンバージョン計測窓が「1日単位で自由」になった——自由と引き換えに手放すのは、去年の数字と比べる権利

Google Analyticsのコンバージョン計測ウィンドウが、プリセット選択から任意の日数指定に変わった。クリックスルーは1〜90日、エンゲージビューは1〜30日。商談サイクルに合わせられるのは前進だが、変更は遡及適用されない。窓を1日でも動かした瞬間、前後の数字は連続しなくなる。何を得て何を失うのか、そして変更前にやっておくべき記録の作り方まで整理する。

WebTech Journal 編集部

編集・執筆

|
|
4分で読める

自由度が上がる機能追加ほど、事故が起きやすい。今回のものは、その典型だ。

変わったこと

Search Engine Landが8月14日に報じたところによれば、Google Analyticsでコンバージョンのルックバックウィンドウ(計測の遡及期間)を、任意の整数値で設定できるようになった。

  • クリックスルーコンバージョン(CTC): 従来は 1 / 7 / 14 / 30 / 60 / 90日 のプリセットから選ぶ形式。今後は1〜90日の任意の値を指定できる。
  • エンゲージビューコンバージョン(EVC): 従来は3日固定。今後は1〜30日の任意の値を指定できる。

設定場所は、Google Analyticsの「広告」>「コンバージョン管理」>「設定」、および連携しているGoogle広告のコンバージョン管理画面。

混同しやすいので整理しておく。これは広告側のコンバージョン計測に関する窓の話であり、GA4のレポート用「キーイベントのルックバックウィンドウ」とは別のレイヤーにある。後者はGoogle公式ヘルプによれば、獲得系キーイベント(first_open、first_visit)が既定30日で7日に変更可能、その他のキーイベントが既定90日で30日・60日に変更可能、エンゲージビュー系が既定3日、という構成だ。

そして公式ヘルプは、ルックバックウィンドウの変更は将来に向かって適用され、プロパティ内のすべてのレポートに反映される、と明記している。この一文が、今回の機能追加の意味をほぼ決めている。

得るもの:商談サイクルとの一致

素直な価値から書く。

プリセット方式の困りごとは、事業の実態と刻みが合わないことだった。BtoBでリード獲得から受注までの中央値が45日の会社にとって、選択肢が30日と60日しかないのは単に不便だ。30日にすれば取りこぼし、60日にすれば無関係な接点まで拾う。1日単位で指定できるなら、自社データから導いた実測値をそのまま入れられる。

高額商材のECも同じだ。検討期間が数週間の商品と、衝動買いされる商品で、同じ窓を使う理由はない。

つまりこの機能は、「計測の設定を、事業の意思決定単位に合わせる」ための道具である。ここは前進だ。

失うもの:連続性

問題は、窓を動かした瞬間に何が起きるかだ。

窓を伸ばせば、コンバージョン数は必ず増える。施策が良くなったからではなく、拾う範囲が広がったからだ。しかも公式ヘルプの通り、変更は遡及適用されない。過去の数字は古い窓のまま、今後の数字は新しい窓で計上される。

結果として、変更日をまたぐ比較——前年同月比、前四半期比、施策のBefore/After——はすべて、設定変更由来の差分と施策由来の差分が混ざったものになる。そして事後に切り分ける方法はない。混ざったあとで分離する手段がないからだ。

現場でこれが最も危険な形で表れるのは、レポート提出の直前に誰かが「もっと実態に合った窓にしよう」と設定を変えたときだろう。数字は改善する。理由は説明できない。

変更する前にやる4つのこと

窓を変えること自体は正しい判断でありうる。だが、以下を先にやってからにしてほしい。

  1. 変更前のスナップショットを取る。 BigQueryエクスポートがあれば生データが残るので問題は小さいが、そうでなければ主要指標を旧設定のまま、少なくとも過去13か月分エクスポートして保管する。これをやらないと、旧基準の時系列が二度と再現できない。

  2. 変更日をアノテーションに残す。 GA4のアノテーション機能でも、レポートの注記でもいい。半年後にグラフの段差を見た誰かが、原因にたどり着けるようにしておく。

  3. 変更理由を一行で書き残す。 「実測の商談中央値45日に合わせた」なのか、「数字が伸びなかったから」なのか。後者だと自覚した時点でやめられる。

  4. 変更後しばらくは新旧両方の水準を併記する。 少なくとも1四半期は「新設定でX件(旧設定基準では概算Y件)」と併記して報告する。読み手の頭の中にある基準線を、静かに書き換えないためだ。

窓を変える意思決定は「レポートを良く見せる」ためではなく「意思決定の単位に合わせる」ためだけに行うべきものだ。この2つは、設定画面の上では完全に同じ操作に見える。だからこそ、理由を言葉にして残す手順が要る。

別の見方:窓の議論は、どこまで持つのか

最後に逆の視点も置いておきたい。

ルックバックウィンドウの精密化は、「ユーザーの接点がすべて計測できている」ことを前提にした改善だ。しかしその前提は、いま最も削れている部分でもある。

本誌が8月12日に報じた通り、Search Consoleの生成AIパフォーマンスレポートで見えるのはインプレッションだけで、クリックもクエリも返ってこない。AI検索経由の流入は、そもそも参照元として正しく取れるとは限らない。計測できていない接点に対しては、窓を1日単位で刻んでも何も改善しない。

窓の設定を詰める作業と、計測されない流入の存在を経営に説明する作業は、まったく別の仕事だ。前者は今日できる。後者はまだ誰も完全な答えを持っていない。両方が必要だという認識だけは、持っておきたい。

関連記事

データ分析

検索結果から「行き先のURL」が消えた——google.com/goto全面展開で、順位計測は1クエリ500〜1,000リクエストの世界に入る

Googleが8月26日、検索結果のリンクをgoogle.com/goto経由の転送に差し替える技術措置を認めた。計測ツールはHTMLから遷移先を読めなくなり、HEADリクエストは通らない。5ページ分の順位を解決するのに500〜1,000リクエストが必要だとNozzleは報告する。順位レポートは「安いから毎日出せた」成果物だった。その前提が崩れるとき、日本の代理店とインハウスは計測の何を捨て、何を残すのか。

データ分析

GTMスニペットが gtag('config') を無視する日が来る——「動いているから触らない」計測が、静かに壊れる側の条件

Googleがタグマネージャーのヘルプに追記した一文が重い。gtm.jsスニペットは今後 gtag('config') を認識も待機もしなくなる。GTM以外のID(G-/AW-/DC-)をgtm.js経由で読み込んでいるサイトは「非対応実装」に分類され、該当コンテナには通知メールがすでに届いている。7月9日の挙動変更から8月20日の統合発表までを時系列で追い、自社が該当するかを5分で判定する手順と、直し方2通りをまとめる。

データ分析

Search Consoleに「サイトを持たないプロパティ」が生まれた——Instagram・TikTok・X・YouTubeの検索データを、誰が月次レポートに載せるのか

Search ConsoleにInstagram・TikTok・X・YouTubeを接続できる「プラットフォームプロパティ」が段階的に展開されている。自社SNS投稿がGoogle検索やDiscoverでどう見られているかが投稿単位でわかる一方、プラットフォーム内の露出は見えず、GA4とも接続されない。サマリーと詳細で数字が合わない仕様も公式に明記されている。SEOとSNSの分業線をまたぐこの機能を、実務でどう扱うかを整理する。