AIに見られたくないGA4の設定ミス5選【#現場で役立つGA4】 - ブログ

こんにちは、JADEのコンサルタントの郡山です。

#現場で役立つGA4、今回は「GA4の設定ミス」について整理してみました。

中でも今回は、分析担当者やAIの誤った解釈を招くような設定ミスをピックアップしてみました。具体的には、データにノイズを混入させてしまう設定の問題です。

分析するそのGA4プロパティ、本当に信頼できる精度で必要なデータが揃っていますか？

AIツールに問いかけたり、Looker Studioで可視化するより前に、まずはちゃんと計測できているか確認してみましょう。

この記事を読んでもらえれば、こんなことがわかります

💡 GA4のデータ精度を損なう設定ミスの例5つ

💡 分析の誤解を招くノイズの特定方法

💡 各設定ミスの対処法と、検証時のチェックポイント

【もくじ】

01. サイト内リンクにUTMパラメータを設定している
02. クロスドメイン先のサイト内リンククリック時に_glパラメータが削除される
03. イベントを重複カウントしてしまっている
04. 不適切・不必要なカスタム設定をしている
05. テスト環境のデータや社員のアクセスが混入している
まとめ：分析の前にデータの品質を確認しよう

01. サイト内リンクにUTMパラメータを設定している

【問題点】

UTMパラメータを「サイト内別ページへの回遊先」を識別するために回遊動線のリンクに設定することはGA4のアクセスログのノイズになるため非推奨です。

サイト内リンクにUTMパラメータを設定すると、本来評価されるべき「セッションの流入経路」の実績を損ない、サイト内リンクのUTMパラメータが評価されてしまうケースが発生します。

例）広告経由のセッションの実績を損なうケース

「google / cpc」で訪問したセッション内で「internal / top_banner_a」というUTMパラメータ付きサイト内リンクをクリックする
ページを閲覧していたタブを開きっぱなしで放置して離脱する
放置タブから閲覧を再開して商品購入キーイベントが発生
- 本来は「google / cpc」の再訪問セッションと記録するはずだが、「internal / top_banner_a」の再訪問セッションとして記録してしまう

【理解しておくべき点】

GA4でセッションが終了する条件は「30分以上操作がなかったとき」なのでサイト内リンクにUTMパラメータが設定されていても、セッションは切れない。
しかし、「Directのセッションは、ひとつ前のセッションの参照元を引き継ぐ」というGA4の仕様がある。これにより、再訪問時のセッションの参照元がサイト内リンクのutmパラメータのものになる場合がある。

UTMパラメータは「ユーザーがどこから自社のWebサイトへ流入したのか」を識別するために用いられます。広告やメールマガジンなど、セッション単位で流入経路を判定する目的で配信URLに設定するのが基本的な使い方です。

【対処法】

サイト内リンクにはUTMパラメータを設定しない
回遊動向を把握する目的であれば、UTMではないパラメータの付与やカスタムイベントの実装など別アプローチで検討する

02. クロスドメイン先のサイト内リンククリック時に_glパラメータが削除される

【問題点】

GA4では、複数のドメインを横断して1つのプロパティで計測する際は「クロスドメイン」設定をする必要があります。

GA4プロパティの設定で計測対象のドメインを登録すれば、各サイトを行き来するサイト内リンクをユーザーがクリックした際、リンク先ドメインの URL に、リンカーパラメータ _gl が含まれるようになります（例: https://www.example.com/**?_gl=1*abcde5***）。

しかし、ウェブサイトの仕様によっては遷移先ページのURLを表示するまでにリダイレクトなどの処理が発生し、_gl パラメータが削除されたURLでページを開くケースがあります。

このような場合、クロスドメイン設定が機能せずドメインごとに別ユーザーとして記録されてしまうケースが懸念されます。

例）

www.hogehoge.comとwww.example.comの2つのドメインを対象にクロスドメイン設定
各ドメインを行き来するサイト内リンクをクリックした際、URL末尾にリンカーパラメータ _gl が付与される
直後にリダイレクトが実行され、URL末尾のパラメータが除去されたURLにアクセスする
結果、ドメインごとに別々のクライアントIDがCookieに保存され別ユーザーとして記録される

【理解しておくべき点】

GA4のクロスドメイン設定は管理画面でドメインを登録するだけで「設定作業」自体は完了する。
しかし、クロスドメイン設定が計測対象サイトで適切に機能しているか「検証」することを怠ると、クロスドメインが機能していないことに気づかないままユーザーをドメインごとに重複カウントしてしまう恐れがある。

【対処法】

クロスドメインを設定した際は、主要なサイト内リンクのクリックをしてリンカーパラメータ _gl が含まれるURLでページを開くことができるか確認する
あわせて、Tag AssistantやChromeデベロッパーツールでClient-IDが維持できているか確認する
リンククリック後にリダイレクトやJavaScriptなどの処理でパラメータが維持できない場合は、開発サイドへ相談し修正する必要がある

03. イベントを重複カウントしてしまっている

【問題点】

GA4のイベントは、ソースコードに実装されているタグ、GA4管理画面、GTM管理画面の3つの設定箇所で定義したさまざまなデータを計測できます。

しかし、設定内容によっては本来計測する（カウントする）必要のないものも混在してしまうことがあります。

ユーザーがどんな行動を何回したのか、ちゃんとカウントしていないと分析のしようがありません。

例）

GTM管理画面で同じ測定IDのGoogle タグを複数作成している
GA4管理画面でカスタムイベントを作成し、GTM管理画面でも同名のカスタムイベントを作成している
GA4管理画面で「特定ページを閲覧」する際に記録するカスタムイベントを作成したが「page_location」パラメータでURLを定義しただけで、対象ページのscrollイベントなどでも計測している
GTM管理画面で「特定ページを閲覧」する際に記録するカスタムイベントを作成したが、対象外のURLパターンでもタグ配信するトリガーをセットしている

【理解しておくべき点】

GA4で新しいイベントを計測する際は、ソースコード・GA4管理画面・GTM管理画面のどこで何を計測しているか現状把握していないと、重複計測する設定を実装してしまう恐れがある

【対処法】

検証する際は、以下の観点でチェックするべきである
- 既存の設定・計測が適切であるか
- 計測対象のユーザー行動で重複カウントせずイベントを適切に記録できるか
- 計測対象外のユーザー行動でイベントを記録することがないか
カスタムイベントの実装前の検証で問題がなくとも、計測開始後の1週間程度で本番環境の計測結果を確認しておくと安心

04. 不適切・不必要なカスタム設定をしている

【問題点】

カスタム設定が間違っていることで、集計に支障をきたすことがあります。

例）

page_viewをキーイベントに設定してキーイベント率が意味をなさない状態
日本語で命名したカスタムイベントをキーイベントに設定して、APIで個別に集計できない状態
page_locationやpage_referrerなど、高基数のカスタムディメンションに登録していることで、サンプリングや(other)行が表示されやすい状態

【理解しておくべき点】

カスタム設定やキーイベントはサイトや事業ごとに適したユーザー行動を集計するものである。独自の設定をするにあたって、Googleアナリティクスのヘルプで記載された仕様に沿っていて、関係者と共に扱いやすい設計かどうか考慮することが重要
高基数のディメンションや大量のイベント数を記録するカスタムイベントは、集計時の精度に悪影響を及ぼす懸念がある。（BigQueryの集計には影響はない）

【対処法】

Google アナリティクスのヘルプの推奨設定に則ってカスタム設定をする
「ページロケーション」や「ページの参照元 URL」など、標準ディメンションで利用できるものを重複してカスタムディメンションに登録しない

05. テスト環境のデータや社員のアクセスが混入している

【問題点】

ユーザーが利用する本番環境のサービスサイトを対象に、一般ユーザーのサイト内行動を計測している状態が理想です。

一方で、テスト環境や無関係のドメインを含んだ計測をするケースや社員のアクセスを除外していないケースなどはすべてノイズです。GA4で何かしらの仮説を立てて集計・分析をする際の精度を低くする点や、誤った解釈をしてしまう恐れがあるため避けるべきです。

例）

本番環境とテスト環境に同じ測定IDのGA4計測用Google タグを実装していて、フィルタなどせずに運用している
GTMプレビューモードの検証を社員が各自で行っているため、テスト時の申込みがキーイベント数に含まれている

【理解しておくべき点】

GA4は標準設定ではタグが埋まっている全ページ・全ユーザーを対象に計測するため、計測する必要のない範囲を除外する設定が機能しているか管理する必要がある
すでに記録された過去のデータから社員アクセスを除外するといった処理をすることはできないため、そのようなデータが含まれている場合は前期比などの比較をする際に注意が必要

【対処法】