トラッキングとは？仕組み・計測設計とCookie・同意の確認ポイント

2026年5月29日

著者: 与謝秀作

トラッキングとは、Webサイトやアプリの行動・状態を記録する仕組みです。ページ表示、リンクのクリック、フォームの操作などを測り、改善判断に使います。先に「何の判断に使うか」を決めると、必要なデータと集める必要のないデータを分けられます。

計測できたイベント数、実際の登録人数、広告による増分効果はそれぞれ別です。本記事では、収集の仕組みと測定仕様の作り方を中心に、Cookieや同意の扱い、動作確認を整理します。

トラッキングは何を記録する仕組みか

たとえば、資料ページを見た、申し込みボタンを押した、フォームを送信したという行動は、異なるイベントとして設計できます。どのページで、どの条件が満たされたときに記録するかを決める必要があります。「コンバージョン」という名前を付けただけで、実際の成功が証明されるわけではありません。

記録の目的を「問い合わせフォームの使いにくい箇所を探す」と定めたなら、開始、エラー、受理された送信などが候補になります。入力された氏名やメールアドレスを分析サービスへ送る必要はありません。目的に対して最小限の項目を選びます。

タグ・Cookie・UTM・サーバーログの役割

トラッキングには複数の要素が関わります。GTMのようなタグ管理ツールと、イベントを送る個別のタグ・ピクセルを同じ役割として説明しないことが大切です。

要素	主な役割	混同しやすいこと
タグ・ピクセル	表示や操作などのデータを送る	発火したことと事業上の成功は別
タグ管理ツール	タグや発火条件を管理する	管理ツール自体がすべての分析を行うわけではない
Cookie等の識別子	一定の条件で再訪や状態を結び付ける	必ず一人の実在人物を特定できるわけではない
UTMパラメータ	キャンペーンの流入元等を分類する	個人を識別する番号ではない
サーバーログ・事業記録	サーバーへの要求や受理した処理等を記録する	ブラウザの操作や読了をそのまま示すわけではない

Google tagと送信先の関係は公式のタグ説明を参照できます。どの方法を使っても、収集項目・目的・保存や利用の方針を確認します。フィンガープリントなどを、同意拒否やブラウザ制限を回避するための代替手順として扱わないでください。

メール用UTMを付ける例

説明用の架空URLとして、/guide?utm_source=newsletter&utm_medium=email&utm_campaign=autumn_guide のように、送信元・媒体・企画をそろえて記録できます。メールごとに表記を統一し、個人のメールアドレスや認証トークンを値に入れません。内部リンクへのUTM付与は流入分類を混乱させるため、導線を測る目的と分けて設計します。

メールの開封、リンククリック、サイト到達、送信成功は別の観測値です。制作と表示確認はHTMLメールの作り方とテスト手順も参照してください。

先に決める測定設計：目的・イベント・成功条件

実装前に測定仕様を表にすると、担当者間の解釈の違いを減らせます。イベント名だけでなく、発火する条件、重複の扱い、どの数を分母にするかまで書きます。

仕様項目	架空の相談フォームの記入例
意思決定の目的	フォーム開始から受理までの問題を探す
イベント名・発火条件	form_startは最初の入力操作時、submission_acceptedは受理確認時
成功条件	送信ボタンではなく、サーバーが受理したことを確認する
分母	フォーム開始を含むセッション等、定義を固定する
必要なパラメータ	フォーム種別や対象ページ等の必要最小限
除外する情報	氏名、メール、自由記述、認証情報
同意と遷移	未選択・許可・拒否時の動作、認証・別ドメインの確認方法
重複と責任者	再読込や再送信の扱い、確認担当、確認日
保存・利用の方針	組織が認める期間と用途、アクセス範囲

この表のイベント名は説明用で、特定のサイトに実装済みという意味ではありません。GoogleはURL、タイトル、入力値、キャンペーン情報等からPIIが送られないよう注意を求めています。個人を特定できる情報を送らないための公式資料に沿って確認します。

イベント数と登録人数・広告の因果効果の違い

架空の一連の操作で、ボタンクリック2回、フォーム開始2回、受理後の成功表示1回、成功画面の再読み込み1回が記録されたとします。成功表示を無条件に数えれば2イベントですが、2人の登録が完了したとは言えません。

観測値	この例の回数	読み取れること
クリック	2	操作の記録。受理の証明ではない
フォーム開始	2	開始の記録。異なる人数とは限らない
成功画面表示	2	再読込を含む可能性がある
重複除去後の成功	未確認	成功条件と一意キー等の検証が必要
実際の登録人数	未測定	必要に応じて事業記録と照合する

広告への成果の割り当ても、広告がなければ起きなかった成果とは別です。通常のアトリビューションと、対照群を設ける増分効果の検証を分けて考えます。GoogleのConversion Lift説明もこの違いを示しています。

計算の例では、広告に割り当てた売上20万円、広告費5万円ならROASは20万円÷5万円＝4、400%です。利益を使うROIとは分子が異なります。この計算だけで増分売上や利益を証明したことにはならず、指標の定義を添えて報告します。

Cookieや識別の利用可能範囲は、ブラウザ、利用者の設定、同意状態などで変わります。全ブラウザで第三者Cookieが一律に廃止されたという説明は正確ではありません。Chromeは2025年4月22日に、既存の第三者Cookieの選択方式を維持し、新しい単独プロンプトを導入しない方針を発表しています。当時の公式発表を確認し、運用時には現在の対象ブラウザの仕様を調べます。

Consent Modeは、伝えられた同意状態に応じてGoogleタグの動作を調整する仕組みです。同意を得る画面や、選択を保存する仕組みそのものとは別です。BasicとAdvancedでは拒否時の通信の扱いも異なるため、通信が一件あるだけで適否を一律に判断できません。

同意の必要性やデータの利用条件は、地域、目的、契約、組織の方針に応じて確認します。バナーやConsent Modeを導入した事実だけで法的な結論は出せません。技術的な役割はGoogleのプライバシー概要で説明されています。

許可・拒否・撤回を含む動作確認と改善活用

設計した条件どおりに記録されるかを、利用者の状態を変えて確認します。未選択から選択した瞬間だけでなく、次ページや再訪でも状態が引き継がれるかを確かめます。

テスト状態	記録する確認事項
初回・未選択	初期状態、タグ動作、送信される項目
許可	更新タイミングと許可後の動作
拒否	選んだ実装方式と組織方針どおりの制御
撤回	状態更新と以降の動作
次ページ・再訪	選択の保存・復元と初期化順序
認証・別ドメイン遷移	必要な条件を満たした到達・成功の継続確認