GA4のコンバージョン設定でずれる数字｜数え方を先に決める

「設定はひと月前から何も触っていないのに、報告に出す件数が営業の手元の数と20件ずれます」「広告の画面とGA4を並べると数字が違うので、会議にどちらを出すか毎回もめます」。計測を任された担当者から届く相談は、たいていこの2つのどちらかです。サイトの調子が悪くなったから起きた話ではありません。コンバージョンの設定は、イベントに印を付ける数分の操作として説明されることが多く、一度やれば終わる作業だと受け取られています。実際には何を1件と数えるかを決める作業で、決めなかった箇所は既定値が黙って埋めます。この記事では、設定の側で数字がずれる場所を6か所に分けて座標を示し、直す順番と、広告側の数字とどう付き合うかまでを整理します。

印を付ければ終わる作業だ、と受け取られている

GA4では、収集しているどのイベントでもキーイベントにできます。つまり、まず行動を測るイベントがあり、そのうち成果にあたるものへ後から印を付ける、という順番です。画面の操作としては数分で終わります。この手軽さが、設定を「済ませる作業」に見せてしまいます。

実際には、印を付けた時点では何も決まっていません。同じ人が同じ日に2回申し込んだら2件なのか1件なのか。完了ページの再読み込みを数えるのか。広告を見てから30日後の申し込みを、その広告の成果として数えるのか。これらはすべて別々の設定項目で、指定しなければ既定値が入ります。そして既定値は、こちらの都合ではなく、その印がどのように作られたかで変わります。

だから、数字のずれは事故ではありません。決めなかった箇所を既定値が埋めた結果が、そのまま画面に出ているだけです。ずれを直す作業は、原因を探す作業ではなく、決めていない箇所を数え上げる作業です。設定の中でずれが生まれる場所は、大きく6か所しかありません。

ずれる場所は、設定の中の6か所に分かれる

先に地図を出します。数字が合わないという相談は、ほぼこの6つのどれかに落ちます。探す順番を決めておくと、勘で触って別の場所を壊す事故が減ります。

1. 印の付け方：どのイベントに印を付けたか、印が上限に触れていないか、名前が長すぎないか
2. 二重計上：同じ成果を2つの経路で拾っていないか、計測の送信が1回の表示で2回出ていないか
3. 数え方の既定：イベントごとに1回か、セッションごとに1回か。既定がどちらで入っているか
4. 発火の条件：ページの表示を数えているのか、要素の押下を数えているのか
5. 参照元の除外：外部の決済やメールのドメインが流入元として残っていないか
6. 期間と処理：締めた時点で数字が固まっているか、比較する期間に設定変更をまたいでいないか

この6つのうち、1から4は数える対象そのものの問題、5と6は数えた結果をどう並べるかの問題です。対象が定まっていないのに並べ方を直しても、数字は落ち着きません。上から順に見ます。

ずれ1：印の付け方と、見落としやすい上限

印を付ける対象は、後から自由に選べます。その自由さが災いして、成果になりそうなイベントへ次々と印が付いていきます。ところがプロパティごとに置ける印は30件までで、外部から登録するものも同じく30件が上限です。上限に近づくと、本当に報告したい成果に印を付けられなくなります。

もう1つ、名前の長さに落とし穴があります。イベント名は40文字までで、40文字を超えた名前は、印を付けてもキーイベントとして報告されません。画面上は印が付いているように見えるのに、レポートの数字が0のまま増えないときは、まず名前の長さを数えてみてください。業務の内容を名前に詰め込んだ結果、上限を越えている例が実際にあります。

印は、付けた時点から先の分だけが数えられます。付ける前の期間に遡って数え直すことはできません。そのため、施策を始めた月と印を付けた月がずれていると、月次の比較で説明のつかない段差ができます。印を付けた日を、設定の記録に必ず残しておくと、その段差を毎回調べ直さずに済みます。

上限は印の数だけではありません。1人の利用者について、1日に数えられるコンバージョンは10,000件、イベントは100,000件、区別されるセッションは2,000件までと決まっています。通常の事業サイトで触れる水準ではありませんが、社内の動作確認を本番のプロパティで繰り返すと、上限より先に確認用の操作が実績へ混ざります。確認は別のプロパティで行うか、行った日と件数を記録に残して報告のときに差し引きます。

ずれ2：同じ成果を、2つの経路で拾っている

報告の件数が実際より多いときに、最初に疑うのがここです。典型は、フォームの送信を表すイベントと、完了ページの表示の両方に印を付けている状態です。1回の申し込みで信号が2つ立ち、2件として数えられます。どちらか一方だけを成果として扱うと決めれば、その場で半分に戻ります。

経路そのものが二重になっている場合もあります。現場でよく報告されている形は3つで、タグを配る道具の中で設定用のタグが重複している、タグを配る道具とページへの直接の記述が併存している、そして入れ物そのものを2つ読み込んでいる、というものです。支援会社の記事で共通して挙げられている確認方法は、ブラウザの通信を見て、1回のページ表示に対する計測の送信が2件以上出ていないかを数えるやり方です。2件出ていれば、原因の候補はこの3つに絞られます。

直し方の原則は単純で、計測の入口を1本にすることです。ページに直接書く方式と、タグを配る道具を経由する方式のどちらかに寄せます。サイトの改修や別会社への引き継ぎのたびに、前の方式が残ったまま新しい方式が足されるのが、二重化のいちばん多い経緯です。計測の入口が今どちらなのかを、担当が代わるたびに1行で申し送るだけで、この事故はかなり減ります。

ずれ3：数え方の既定は、印の作られ方で変わる

カウント方法には、イベントごとに1回と、セッションごとに1回の2種類があります。1回の訪問中に同じ成果が5回起きたとき、前者は5件、後者は1件と数えます。問題は、指定しなかった場合の既定が一律ではないことです。旧世代の目標から引き継がれた印は、セッションごとに1回が既定になります。具体的には、自動で作成されたプロパティと、2023年4月以降に設定アシスタントの目標移行ツールを使った場合が該当します。それ以外の印は、すべてイベントごとに1回が既定です。

つまり、同じプロパティの中に、生まれの違う印が混在していると、何もしていないのに数え方が2種類並んでいることになります。資料請求は訪問ごとに1件、購入は起きた回数だけ、という設計なら問題ありません。設計としてそう決めたのか、既定がそうなっただけなのかを印ごとに1回だけ確かめるのが、この工程の作業です。

1回と数えるか毎回数えるかをどちらに寄せるべきかは、成果の性質と、その数字を何に使うかで決まる別の論点です。その判断そのものは本記事では扱いません。ここで押さえるのは仕様のほうで、カウント方法の変更は、変更後に発生した分にだけ適用され、過去のデータは書き換わりません。変更にはマーケティング担当者以上の権限が要ります。変えた日を境に段差ができるので、比較の期間を変更日にまたがせないようにします。

• カウント方法の変更にはマーケティング担当者以上、除外する参照の設定には編集者以上の権限が要る。設定を依頼する相手を先に確かめる
• 印を付けた日、カウント方法を変えた日、窓の長さを変えた日は、同じ記録の同じ欄にまとめて書く。別々の場所に散らすと突き合わせられない
• 既定のままにした項目にも、既定のままにしたと書き残す。空欄は「決めていない」と「既定でよいと決めた」の区別がつかない

ずれ4：発火の条件が、成果の実態とずれている

何を信号にするかで、数え方の性格が変わります。完了ページの表示を信号にすると、再読み込み、戻る操作、ブックマークからの再訪でも増えます。申し込みの完了画面をそのまま開きっぱなしにしてタブを復元した、という程度のことでも数が動きます。訪問ごとに1回と数える設定にしておけば、同じ訪問の中の重複は吸収できます。

逆に、ボタンの押下を信号にすると、送信が失敗しても数えます。入力の不備で戻されたとき、押した回数だけ成果が立ちます。画面の遷移が起きない作りのサイトでは完了ページ自体が無く、押下を信号にせざるを得ない場合もあります。その場合は、送信の成功を表す別の信号を作れないかを開発側と相談します。

判断の軸は1つです。成果が成立したことを、どの信号が最も正確に表しているか。紙の申込書を後から突き合わせる業務なら、受付台帳に載った件数が正解です。3日分だけでよいので、台帳の件数と画面の件数を並べます。台帳と3日分を突き合わせれば、発火条件のずれはその場で判別できます。合わない差の中身を見れば、増えているのか減っているのかで原因の側も絞れます。

ずれ5：参照元の除外が効いていない

外部の決済代行を経由して戻ってくる場合や、パスワード再設定のメールから戻ってくる場合、そのドメインが流入元として記録されます。業務の途中経過が流入元に化けるので、成果の帰属先が崩れます。除外する参照は、データストリームごとに最大50個まで設定でき、設定には編集者以上の権限が要ります。

ここで多いのが、設定したのに消えないという相談です。除外リストへ追加する前に、そのドメインからの流入としてセッションが記録されていた場合、その後にブックマークなどで直接戻ってきても、同じ流入元に帰属し続けます。最後に判明している接点を引き継ぐ仕組みだからです。設定した翌日に画面から消えなくても、設定が効いていないとは限りません。しばらく置いてから、新しい期間で確認します。

自社のドメイン内からの参照は、既定で自動的に検出され、新しい流入元としては扱われません。複数のドメインをまたぐ計測を設定している場合も同様です。個々のページやイベントに参照を無視する指定を足すこともできますが、提供元は、必要になる場面はほとんどないとしたうえで、全ページに付けると流入元の情報そのものが失われると注意しています。使うとしても、特定の1ページに限る形にとどめます。

除外の一覧は、増やすほど正確になるわけではありません。提携先からの送客や、比較のためのページ経由の流入まで消してしまうと、成果がどこから来たのかが分からなくなります。除外するのは、業務の途中で必ず通る外部のドメインに限る、と線を引きます。迷うものは、除外せずに別の名前で束ねて集計するほうが後戻りできます。50個の枠は、埋めるための枠ではありません。

ずれ6：期間の切り方と、数字が固まるまでの時間

朝いちばんに前日の数字を締めて報告し、翌週に見直したら件数が増えていた、という食い違いは処理の間隔で説明がつきます。提供元の案内では、リアルタイムの反映は通常数分、標準のプロパティの当日中の処理は2時間から6時間、日次の処理は12時間が目安です。規模の大きいプロパティでは18時間、24時間以上になる場合もあります。前日分を朝の時点で締めると、まだ動く余地がある数字を報告することになります。

期間そのものにも上限があります。データの保持は最長14か月です。前年同月比を毎月出す運用にしていると、ある月から比較対象の期間が取れなくなります。長期の比較が必要なら、月次の締め値を別の表に書き出して保管しておきます。

もう1つ、変更の効き方の違いを押さえておきます。レポート用のアトリビューションモデルの変更は、過去のデータにも将来のデータにも適用されます。つまり、モデルを変えた瞬間に過去の数字の見え方が変わります。一方、キーイベントのルックバックウィンドウの変更は、それ以降にだけ適用されます。報告の数字が変わったときは、サイトより先に設定の変更履歴を見る順番にします。

モデルそのものにも、いつから使えるかという境目があります。有料とオーガニックの両方を対象にしたデータドリブンは2021年11月1日から、規則にもとづくモデルは2021年6月14日からで、それより前を含む期間で見ると、表示されるのは部分的なデータになります。また、ファーストクリック、線形、減衰、接点ベースの4つのモデルは、2023年11月をもって使えなくなりました。古い解説どおりに設定しようとして見当たらないときは、廃止されたモデルを探している可能性があります。

広告側と合わないのは、帰属の窓とモデルが違うから

設定を整えても、広告の管理画面の数字とGA4の数字は一致しません。数え方の土台が違うためです。まず窓の長さが違います。GA4では、初回訪問など獲得を表すキーイベントのルックバックウィンドウは既定30日、それ以外のキーイベントは既定90日で、前者は7日、後者は30日か60日にも変えられます。90日前の接点まで貢献度を配る数字と、もっと短い窓で締めた数字は、そもそも同じ量を測っていません。

貢献度の配り方も違います。貢献度を割り当てるチャネルは、検索広告の有料チャネルだけにするか、有料とオーガニックの両方にするかを選べます。2023年6月以降にプロパティで初めて連携を作った場合、既定は有料チャネル側です。また、データドリブンのモデルでは1件の成果が経路上の複数の接点へ小数で配られ、合計が1.0になります。件数の列に小数が並ぶのはこのためで、故障ではありません。

仕組みの側で、そもそも見えないものもあります。GA4のキーイベントをもとに広告側へ取り込んだ成果は、入札の最適化で同じイベントを2回数えないために、副次的な成果として設定されます。解析側から取り込んでいる場合、広告を見ただけで後から成果に至った分は表示されません。端末をまたいだ計測には別の設定を有効にする必要があります。逆に、広告側で作られた成果は、GA4の標準レポートには出てきません。タイムゾーンも、GA4はプロパティ側、広告側はアカウント側の設定を使うため、日付の境目がずれることがあります。合わせにいくのではなく、どちらの数字を何の判断に使うかを先に決めます。

見比べるときは、日付の並べ方もそろえます。広告側には、成果が起きた日で並べる列と、その成果のもとになったクリックの日にさかのぼって並べる列があります。GA4は、成果が起きた日で並べます。並べ方の違う表を横に置けば、期間の合計が同じでも日別は必ずずれます。比べるなら、まずどちらの並べ方で見るかを決めてから差を読みます。

直す順番：何を1件と数えるかを先に決める

ここまでの6か所は、上から順に触っても直りません。数える対象の定義が決まっていないと、どの設定が正しいかを判定できないからです。次の順で進めます。1から3は会議室で決める作業で、画面は触りません。

この順で進めると、設定を触る作業は4番目以降だけになります。画面から入ると、原因を探しながら設定を変えることになり、変更が遡らない仕様と相まって、後から検証できない状態になります。

最後の突き合わせが3日分でよいのは、差の性質が3日あれば見分けられるからです。毎日ほぼ一定の割合で多いなら、数え方か経路の重なりです。特定の日だけ多いなら、その日の施策か、外部からの一斉の流入を疑います。逆に画面の件数のほうが少ないなら、信号が立っていない経路が残っています。件数の大小より、差が毎日出るのか特定の日だけかを先に見ます。

イベント名の付け方を、設定より先に決める

名前は後から直しにくい設定です。名前を変えると、変更の前と後で別のイベントとして扱われます。集計の連続性が切れるので、途中で直すほど不便になります。最初に型を決めておくのが、いちばん安上がりです。

守る制約は3つです。名前は40文字まで。これを越えると印を付けても報告されません。大文字と小文字は区別されるので、綴りが同じでも別のイベントになります。そして1つのイベントに付けられるパラメータは25個まで、値は原則100文字までで、ページの題名は300文字、参照元は420文字、ページの場所は1,000文字が例外として認められています。

型としては、対象と動作を並べ、英小文字と下線だけで書く、と決めておけば十分です。日本語や空白を混ぜない、部署名を入れない、日付を入れない。この3つを避けるだけで、後から名寄せする作業がほぼ消えます。同じ意味の名前が2つ増えていないかを、月に1度だけ一覧で見る運用にしておくと、ゆれが溜まる前に気づけます。

支援会社の記事でよく指摘されるのが、新しく作ったイベントが設定画面の一覧に現れるまでに時間がかかる点です。一覧から選んで印を付ける手順に慣れていると、データが溜まるのを待つことになり、その待ち時間のぶんの成果が数えられません。一覧に出るのを待たず、名前を直接入力して印を付けられる場合があるので、新しい成果を測り始める前に、その手順を確かめておきます。

AIに渡してよい工程と、人が決める工程

設定の周辺には、機械に回したほうが速い作業がいくつかあります。イベント名の一覧を渡して、意味が重なっている名前の組を挙げさせるのは有効です。人の目では、綴りが1文字違う名前や、単数と複数の違いを見落とします。設定内容を社内向けに説明する文章の下書き、変更履歴の要約、差分が出た日に何を順に確認するかの手順書きも、下書きまでは渡せます。

渡してはいけないのは、判定です。何を1件と数えるかは、業務の定義であって解析の問題ではありません。受付台帳に載る条件を知っているのは現場です。どの流入元を除外するかも人が決めます。外部の決済代行は除外してよくても、提携先からの送客は成果の一部かもしれません。社内に報告する数字をどれにするかも人が決めます。広告側とGA4のどちらを出すかは、その数字で何を判断するかによります。

いちばん危ないのは、数字が動いた理由を尋ねて、返ってきた答えをそのまま採ることです。モデルは、与えられた範囲の中でもっともらしい説明を組み立てます。原因を断定させず、確認すべき箇所の候補と、その確かめ方だけを出させます。根拠として設定の画面か記録を指し示せない指摘は採用しない、を運用の決めごとにしておきます。

実務仕様：設定台帳に残す項目

設定の内容は、画面を見れば分かります。分からなくなるのは、なぜその設定にしたのかと、いつ変えたのかです。この2つを残す表を1枚だけ作ります。担当が代わったときに読まれるのは、この表だけです。

残す項目	書く内容	見落とすと起きること
成果の定義	業務の言葉で1文。台帳の何をもって成立とするか	画面と台帳のどちらが正か決まらない
信号にしたイベント	ページ表示か、送信の成功か。選ばなかった側とその理由	後から両方に印が付き、二重計上に戻る
カウント方法	訪問ごとに1回か、起きた回数だけか。決めた理由	生まれの違う印が混在し、数え方が2種類並ぶ
印を付けた日と変更日	設定を入れた日、変えた日、変えた項目	月次の段差を毎回調べ直すことになる
ルックバックウィンドウ	既定のままか、変えたか。変えた日	広告側との差を毎回ゼロから説明することになる
除外している参照元	ドメインと、除外した理由	業務上必要な送客まで消してしまう
報告に出す数字	GA4か広告側か。どの判断に使う数字か	会議のたびにどちらを見るかでもめる

7行あれば足ります。この表を作る作業自体が、決めていない項目のあぶり出しになります。埋められない行が残ったら、そこが次に数字がずれる場所です。

設定を変えた日の扱いと、報告に出す数字

設定変更は、原則としてその日から先にしか効きません。カウント方法も、ルックバックウィンドウも同じです。例外は、報告用のアトリビューションモデルで、こちらは過去にも効きます。前者は段差を生み、後者は過去の数字そのものを書き換えます。性質が逆なので、同じ扱いにすると説明できなくなります。

実務としては、変更日をまたぐ期間比較をしないと決めるのが最も簡単です。どうしてもまたぐ場合は、グラフに変更日の線を1本引き、注記として「この日からカウント方法を変更」と書きます。注記があるだけで、会議での質問はほとんど出なくなります。

報告に出す数字は、1つに絞ります。2つ並べると、必ずどちらが正しいかの議論になり、本題の時間が削られます。広告の出稿量を判断するなら広告側、サイトの改善効果を見るならGA4、というように用途で割り当てます。どちらの数字も正しく、測っている範囲が違うだけだと最初に共有しておくと、ずれ自体が議題にならなくなります。

点検のチェックリストと、やりがちな失敗

四半期に一度、次の項目を上から確認します。所要は30分程度で、設定を触るのは食い違いが見つかった場合だけです。

• 印を付けているイベントの数と、名前の長さを確認した（上限30件、名前は40文字まで）
• 1件の成果に対して、信号が1つだけになっていることを確認した
• 印ごとにカウント方法を開き、設計どおりか既定のままかを確認した
• 1回のページ表示に対する計測の送信が1件だけであることを確認した
• 除外している参照元の一覧を見て、不要になったものと足りないものを確認した
• この四半期に入れた設定変更と、その日付を記録に書き足した
• 画面の件数と業務側の台帳を、直近3日分だけ突き合わせた

あわせて、報告の場で説明が難しくなる形も挙げておきます。いずれも、設定そのものより決めた記録が残っていないことが原因です。

• フォームの送信と完了ページの両方に印を付ける：1回の申し込みが2件として数えられる
• カウント方法を確認せずに使う：生まれの違う印が混在し、数え方が2種類並んだまま報告される
• 設定を変えた日を記録しない：月次の段差が出るたびに、原因の調査からやり直すことになる
• 広告側とGA4の数字を並べて報告する：測っている範囲の違いが、計測の不備として扱われる
• 参照元の除外を設定した翌日に効果を判定する：以前に付いた帰属が残るため、効いていないと誤認する
• 数字が動いた理由をAIに断定させる：もっともらしい説明が採用され、確認すべき設定が素通りする

まとめ

コンバージョン設定でずれる場所は、印の付け方、二重計上、数え方の既定、発火の条件、参照元の除外、期間と処理の6か所に収まります。どれも、決めなかった項目を既定値が埋めた結果です。先に決めるのは操作ではなく、何を1件と数えるかという業務の定義です。広告側との差は、窓の長さと貢献度の配り方が違うために生まれるもので、一致させる対象ではありません。名前のゆれの洗い出しや説明文の下書きはAIに渡してよい一方、何を数え、何を除外し、どの数字を会議に出すかは人の側に残ります。次に数字が動いたときは、サイトを開くより先に、印を付けた日と設定を変えた日の記録を開きます。そこに何も書かれていないのであれば、まず記録を作るところが本題になります。

※本記事にはAIが活用されています。編集者が確認・編集し、可能な限り正確で最新の情報を提供するよう努めておりますが、情報の完全性、正確性、最新性、有用性等について保証するものではありません。本記事の内容に基づいて行動を取る場合は、読者ご自身の責任で行っていただくようお願いいたします。