GA4 EC 計測 playbook
ストアのすべての転換判断がこの配管の上に立ちます。相当数のストアが、二重計上し、ステップを落とし、誤帰属するファネルで走り——そのゴミの上で自信満々に判断しています。
GA4 の EC モデルはイベントの列です——view_item、add_to_cart、begin_checkout、add_shipping_info、add_payment_info、purchase——それぞれ items 配列と金額パラメータを運びます。正しく作れば下流の分析はすべて機能し、微妙に間違えば下流のすべてが丁寧に嘘をつきます。この playbook はモデルを実装し、真実と照合し、ストアが変わっても誠実さを保つ検査を仕掛けます。
ステージ 1：イベントモデルを完全に実装
部分実装が常態であり問題です：begin_checkout なしの purchase はファネル不在。items 配列なしのイベントは商品別分析不在。value と currency の欠落は照合できない収益レポート。完全な列と完全なパラメータで実装し、プラットフォームのネイティブ統合が堅ければそれを使い——それでも監査します。ネイティブ統合は漂流するからです。
view_item から purchase までの完全なイベント列
全コマースイベントに完全な items 配列：id・name・category・price・quantity
お金の動くすべてのイベントに value と currency
注文システムと厳密一致する transaction ID——重複排除の要
ステージ 2：真実と照合
検査は照合です：同じ窓の GA4 購入収益対実注文。同意とブロッカーで小さな差は残ります。それを超えたら調査。次に買い物客としてデスクトップとモバイルでファネルを歩き、DebugView でイベント発火を見ます——各ステップ、各 1 回、正しいパラメータで。二重発火の purchase と幽霊のチェックアウトステップはここで名乗り出ます。
ステージ 3：信頼を保つ
計測も他と同じく劣化します：テーマ更新がタグを落とし、新テンプレートがイベントなしで公開され、アプリが重複を注入する。計画的に再照合し、大きなテーマ・チェックアウト変更のたびにファネルを歩き直し、検証済み状態を記録します——漂流は検出可能になり、数字への信頼が崩壊する危機の中で発見されずに済みます。
動作の流れ
モデルを完全実装
全イベント、完全パラメータ、一致する transaction ID——プラットフォーム統合経由、監査つき。
照合と歩行
収益を注文と照合し、DebugView で両デバイス階級のファネルを歩く。
再検査を予定化
リズムに沿った照合、構造的なストア変更のたびの再検証。
得られるもの
各ステップが実在し 1 回だけ発火するファネル
注文システムと照合できる収益レポート
必要なデータを実際に持つ商品別分析
危機でなく予定で捕まる漂流
担当するエージェント
連携できるツール
よくある質問
プラットフォームにネイティブ GA4 統合があります。完了？
完了というより開始です。ネイティブ統合の完成度はまちまち——チェックアウトステップと items 配列の質がよくある穴——で、プラットフォーム更新で漂流します。信頼する前に実際の発火を監査してください。
GA4 収益は注文とどこまで一致すべき？
あなたのトラフィック構成で同意モードとブロッカーが説明する差の内——よくあるのは 5〜15% の過少報告。安定して理解された差は問題なし。不安定・拡大する差は欠陥です。
サーバーサイド計測は価値ある？
ブロッカーの差を縮めデータの耐久性を上げますが、実際の構築コストがかかります。まず基礎を直すこと——壊れたイベントを忠実に転送するサーバーサイドの配管は、高価なゴミです。
どのエージェントが実行？
Analyst が監査・照合・予定された再検証を所有し、壊れた部分の正確な修正手順を生成します——報告の前に必ず検証します。悪いデータでの報告は無報告より悪いからです。