SiteOps
トップメディアダッシュボード更新履歴
記事一覧

GA4のコンバージョンが突然0になったとき、最初の30分でやること

GA4のコンバージョン（キーイベント）が突然0になったときに、最初の30分で“本当に0”か“計測/定義事故”かを確定して復旧の手戻りを減らす手順です。

著者: 川原更新: 2026-05-15アクセス分析RSS
Xで共有FacebookLinkedIn
料金相談

GA4のコンバージョンが突然0になったとき、最初にやるべきことは「原因を当てに行く」ではなく「“本当に売上/申込が0”なのか、“計測だけ0”なのかを15分で確定する」ことです。コンバージョンは集計や定義（キーイベント/イベント名/パラメータ）に依存するため、施策を打つ前に“どこが0になったのか”を固定して、復旧の手戻りを減らします。

0. まずやらないこと

  • いきなりイベント名/パラメータを一括変更する
  • GTMのタグを大量に追加/削除する（まず差分を最小に）
  • コンバージョン設定（キーイベント）を闇雲に触る
  • 0の原因を特定できていないのにLP/広告/価格を触る

最初の30分は「直す」より「切り分け」です。計測が壊れているのに施策を打つと、何が効いたかが永久に分からなくなります。

1. “どのコンバージョンが0か”を固定（5分）

まず「0になった対象」を固定します。ここが曖昧だと、復旧しても“見ている指標が違う”事故になります。

  • どのドメインの話か（複数サイト運営なら最優先）
  • どのGA4プロパティか
  • どの期間の話か（今日/昨日/先週同曜 など）
  • 何が0か（例: 購入数、リード数、キーイベント数、特定フォーム到達 など）
  • “0になった”のはどのレポートか（標準レポート/探索/広告/Looker Studio）

この時点で「見ているプロパティが違う」「探索のフィルタが残っている」などの“見方の問題”なら、作業は終了です。

2. “今も0か”を最短で確認（Realtime / DebugView）

過去データの集計遅延と、今の計測停止を混ぜると沼ります。まず“今の受信”を確認します。

  • GA4 > レポート > リアルタイム でイベント受信があるか
  • 可能なら DebugView で、自分の操作がイベントとして届くか
  • 端末を変えて再現するか（スマホ回線など）

Realtime/DebugViewが動いているのに「キーイベントだけ0」なら、“キーイベント定義”や“イベント名の変化”側が疑わしいです。

3. GA4以外で“本当に0か”をクロスチェック（5分）

“売上/申込が本当に0”か“GA4だけ0”かで、優先順位が変わります。

  • Stripe/決済/申込DB: 成功が0か（該当する場合）
  • Search Console: 同期間でクリック/表示が0に寄っているか
  • サーバ/Cloudflare: リクエスト数が0に寄っているか

GA4以外が生きているなら、まず「GA4計測の復旧」を最優先にします。

4. “キーイベント定義”の事故を除外（5分）

GA4ではコンバージョン相当は「キーイベント（Key event）」として扱います。0になったキーイベントが、そもそも“受信しているイベント”に紐づいているかを確認します。

  • 対象イベントが「イベント」一覧に出ているか
  • そのイベントが「キーイベント」になっているか
  • 直近でキーイベントのON/OFFや条件を変えていないか
  • 直近でイベント名を変えていないか（GTM側の変更含む）

5. “イベントが送れていない”を最短で確定（10分）

ここは深掘りしません。送れている/送れていないを確定します。

  • 本番ページでタグが読み込まれているか（最小確認）
  • 直近でGTMを触っていないか（公開履歴/差分）
  • CMP/同意（Consent）の設定変更で、計測が全面停止していないか

「送れていない」なら、次の優先順で原因を当てます。

  1. GTMの公開ミス（環境/ワークスペース/トリガー）
  2. イベント発火の条件が変わった（URL/クリック要素/フォーム仕様変更）
  3. CMP/同意の変更で計測が止まった
  4. CSP/セキュリティ/WAFでタグがブロックされた

6. 30分で出す“結論”の型

最初の30分で、次のどれかに分類して次の作業を固定します。

  1. 計測停止（GA4だけ0 / Realtimeも弱い）: GTM/CMP/タグ到達性を優先して復旧。
  2. 定義事故（イベントは来るがキーイベントだけ0）: キーイベント定義/イベント名/条件を修正。
  3. 本当に0（決済/申込も0）: 集客/障害/価格/フォーム不具合のどれか。サイト側を最優先で復旧。
  4. 見方の問題（Realtimeは動く）: 期間/フィルタ/探索条件/プロパティ取り違えを修正。

この分類ができれば、次の1時間で“正しい対象”にだけ手を入れられます。

SiteOpsで“0”を早期検知する（再発防止）

同じ事故を繰り返さないために、次からは「落ちた瞬間に気づく」仕組みを先に作っておくと、復旧の初動が一気に早くなります。

  • GA4 / Search Console / 決済などの主要シグナルを、毎朝の優先順位で見られる状態にする
  • “0”や急落が起きたら、まず「どのドメインで何が落ちたか」をすぐ確定できるようにする

状況が再現できない/原因が複合している場合は、相談だけ先に進めるのも有効です。

  • 料金・導入の概要を見る
  • 相談する

関連

  • /media/ga4-traffic-zero-first-30-minutes
  • /media/stripe-payment-failures-spike-first-30-minutes
  • /media/search-console-drop-first-30-minutes

参考にした一次情報

  • GA4 Help: Key events
  • GA4 Help: DebugView
  • GA4 Help: Realtime report

この記事を書いた人

川原

SiteOps編集チームの公開窓口として、検索、アクセス、収益データをもとにした運営判断の知見をまとめています。

著者情報

関連記事

GA4のコンバージョンが急に爆増したとき、最初の30分でやることアクセス分析更新: 2026-05-16GA4で(direct)/(none)が急に増えたとき、最初の30分でやることアクセス分析更新: 2026-05-14GA4のアクセスが突然0になったとき、最初の30分でやることアクセス分析更新: 2026-05-13
前の記事GA4のアクセスが突然0になったとき、最初の30分でやること次の記事GA4のコンバージョンが急に爆増したとき、最初の30分でやること

次にやること

複数サイトの検索、アクセス、収益データをまとめて見直すなら、SiteOpsのダッシュボードでサイト別に確認できます。

料金を見る相談したい / お問い合わせ