この記事の内容
  1. 参照元と利用者の経路を並べる
  2. 参照元の除外とドメイン間計測を区別する
  3. 決済からの戻りと紹介サイトを分ける例
  4. 条件の範囲を狭くして確認する
  5. 現在の設定と過去の表示を混同しない
  6. 終了や移行では判断理由を引き継ぐ

参照元と利用者の経路を並べる

最初に対象プロパティ、データストリーム、期間、参照元のドメイン、関係するページを残します。支払いやパスワード回復など、サイト側が管理する操作から戻る場面なのか、外部の記事や紹介から初めて来た場面なのかを調べます。名前に自社と似た語がある、件数が多いというだけでは不要な参照元とは言えません。操作を再現する場合は許可された検証用の経路とデータを使い、実在の購入を分析確認のために勝手に作らないようにします。どのページから外へ出て、どこへ戻り、その時点で何を観測したかを表にします。この経路が分かると、集客源の問題とサイト内の継続性の問題を分けて調べられます。

参照元の除外とドメイン間計測を区別する

Google Analyticsには不要な参照元を条件で指定する仕組みと、管理する複数ドメインをまたぐ計測の仕組みがあります。参照元を表示しないことだけで、別ドメインの識別や操作が同じ利用として正しくつながるとは限りません。自社が両方を管理する経路ならドメイン間の設定を別に調べ、外部の決済先のように設定権限がない場所へ勝手にタグを置く前提にはしません。公式の不要な参照元の資料は、条件に合うイベントへ参照元を無視する情報を付ける働きを説明しています。今回の不足がどちらの役割なのかを一行にし、別の設定を同じ解決策として混ぜないでください。

決済からの戻りと紹介サイトを分ける例

仮に購入後の戻り先で決済ドメインが参照元になり、別の紹介記事からも利用が来るとします。前者は元の集客の見方を崩す可能性を調べますが、後者は正当な集客源かもしれません。両方をまとめて除外しないよう、経路、対象ページ、取得時の設定を別に記録します。設定前後のテストでは、決済からの戻りだけでなく紹介元からの初回到達も確認します。正当な参照元が消える変更は目的に反するため、合格条件へ含めます。これは架空の検証例であり、どの決済サービスでも同じ表示になる、あるいは特定の設定で売上が増えるという説明ではありません。

条件の範囲を狭くして確認する

設定する担当者は対象ストリームと必要な権限を確認し、現行画面の条件がどのドメインへ当たるかを点検します。似た文字列を含む他の紹介元まで巻き込まないよう、期待する一致と不一致の例を用意します。全ページで無条件に参照元を無視する実装は、必要な集客情報を失う可能性があると公式資料も注意しています。画面上の改善を目的に広い条件を追加せず、元に戻せる設定記録を残してください。反映後に期待どおりかを確認できない場合は、問題が解消したと報告せず、テストの不足かデータ処理待ちかを分けます。未知の範囲を都合のよい数字へ補正することもしません。

現在の設定と過去の表示を混同しない

設定を追加した後も、過去の接点や集計の考え方によって旧参照元が報告に見える場合があります。過去のすべてが書き換わると想定せず、変更日、対象イベント、期間、使用した指標を残します。数字がすぐゼロにならないことだけで条件をさらに広げるのではなく、公式資料と今回の検証経路へ戻ります。標準機能で確認できる仕事なら追加契約は不要ですが、継続報告の加工や確認にかかる時間は費用です。Data Studioへ結果を出す場合も、同じ期間と定義、更新日で読む構成にします。正しい分類に直すことと、元の事業実績が改善したことは別の成果として説明してください。

終了や移行では判断理由を引き継ぐ

引き継ぎには除外条件、理由、担当者、変更日、検証した経路、残した正当な紹介元を含めます。レポートの数字だけでは、後からなぜそのドメインを外したか分かりません。別の分析構成へ移す場合は、同じ参照元処理が存在するか、指標が同じ意味かを確認し、系列を無条件につなげません。必要な報告と設定を保存できる形式も現在のサービスや契約で確認してください。収集を止める場合はタグや連携先を整理し、設定画面を見なくなっただけで送信が止まったとは考えません。新担当者が代表的な経路を再確認できる状態を作ることで、不要な除外を残し続けることも、必要な条件を消すことも避けやすくなります。

参照した公式情報

料金・提供条件・対応範囲は変更されることがあります。契約前に、下記の公式ページでご確認ください。

比較方針を読む広告について