独立站のGA4導入：イベント計測、EC計測、クロスドメイン、デバッグ

独立站のGA4導入：イベント計測、EC計測、クロスドメイン、デバッグ

1. GA4の全体コード：gtagを直接設置するかGTM経由か

多くのチームが「gtag.jsを直接貼るか、GTMコンテナを使うか」で悩みます。判断基準はただ1つ、エンジニア以外がタグを変更する必要があるかどうかです。マーケティング担当が自分でピクセルを追加したりコンバージョンイベントを変更したりするならGTM。自分1人で運用するならgtag.jsの直接設置のほうが軽く、コンテナが1層減る分だけ故障点も減ります。

直感に反するかもしれませんが、GTMは万能薬ではありません。小規模チームがGTMを使うと、かえってデバッグの手間が増えます。タグ、トリガー、変数の3層が入れ子になるため、問題が起きたらどの層で切れたのかをまず切り分ける必要があります。B2Bの独立サイトは1年に何度もタグを変更しないので、gtagを直接設置するほうが運用コストは低くなります。GTM自体の整理方法はこちらGTMのタグ・トリガー・変数の管理。

2. イベント計測：自動イベントとカスタムイベントの使い分け

GA4はpage_view、session_start、first_visit、scroll、click、view_search_resultsなど、いくつかのイベントを自動で収集します。これらはコードを書かなくても取得できますが、粒度が足りません。独立サイトで自分で定義すべきイベントは4つだけです。フォーム送信（generate_lead）、ファイルダウンロード（file_downloadをカスタム定義）、CTAクリック（cta_click）、動画再生（video_start）です。イベントは多ければよいわけではなく、カスタムイベントが15個を超えるとレポートが見づらくなります。

イベント名はGA4が推奨するsnake_caseを使い、すべて小文字でアンダースコア区切りにします。公開後に名前を変えると過去のデータが途切れます。GA4は古いイベント名を新しい名前に自動で対応付けできないため、イベントの変更で手動でマッピングを作成するしかなく、しかも将来のデータにしか反映されません。イベント名のルールはこちらを参照構造化データのSchemaマークアップ一覧の命名ルール。

三、ECトラッキング：B2Bサイトに必要か

問い合わせ専門のB2Bサイトでは「カートもないのにECトラッキングなんて無意味」と考える人が多い。これは誤りだ。GA4のECイベントはpurchaseだけではない。view_itemやview_item_listからbegin_checkoutまで、要は「ユーザーが製品カタログをどこまで進んだか」を測る仕組みだ。オンライン決済がなくても、B2Bサイトならview_item（製品詳細ページの閲覧）とview_item_list（製品一覧ページの閲覧）は実装すべきだ。そうして初めて、どの製品ページが本当に読まれているかが分かる。

実際にオンラインで販売する場合（サンプル注文や部品注文など）、purchaseイベントにはcurrencyとvalueの2つのパラメータが必須だ。どちらか欠けるとGA4は収益を計算できない。currencyはUSDのような3文字コード、valueは数値で通貨記号は付けない。トラッキングとフォームの連携方法はこちらを参照。問い合わせフォームの信頼性とスパム対策。

四、クロスドメイン計測：サブドメインと外部決済ページの設定

独立サイトで最も多いクロスドメインの問題は、メインサイトがwww.example.comにあり、問い合わせフォームがcrm.example.comに送信される、あるいは決済がpay.example.comに遷移するケースだ。クロスドメインを設定しないと、メインサイトからサブドメインへ移動した時点でGA4は新しいセッションとして扱い、流入元も失われる。

設定方法はGA4管理画面の「データストリーム→タグ設定→ドメインのクロスドメイン計測を設定」でexample.comを追加する。ただし、第三者の決済ドメイン（stripe.comなど）は追加しないこと。あれは他人のドメインだ。設定後は必ず実測する。メインサイトからフォームでサブドメインへ移動し、DebugViewでsession_idが変わらないか確認する。CRM連携のフィールドマッピングはこちらを参照。サイトリードのCRM連携。

五、デバッグと検証：検証しなければ実装していないのと同じ

デバッグの三種の神器は、GA4 DebugView、ChromeのGA4 Debugger拡張機能、GTMプレビューモードです。公開手順は必ず次の通りにします。まずDebugViewを開き、自分でサイト上を一周します。トップページの閲覧、商品ページ、フォーム送信、ファイルダウンロードと進み、各ステップで対応するイベントがDebugViewに表示されるか、パラメータが揃っているかを確認します。

見落としがちな検証ポイントがもう一つあります。イベントの重複排除です。フォーム送信ボタンにトリガーが二重に設定されていると、ユーザーが一度クリックしただけでgenerate_leadが2件送信され、データがそのまま倍になります。DebugViewで一度だけクリックし、イベント数がちょうど1件かどうかを確認してください。検証後は3日間リアルタイムレポートを継続して観察し、テストトラフィックだけではないことを確かめます。サイトの日次モニタリングチェックリストはこちらサイト監視とアラート。

六、公開後の月次レビュー：データのズレをどう見つけるか

GA4は導入して終わりではありません。毎月必ず一度データの健康診断を行い、次の3つの異常に注目します。セッション数が突然半分に落ちたら、ほぼ間違いなくコードがキャッシュに上書きされたか、CDNのルールが変更されています。あるカスタムイベントが2週間連続でゼロなら、ユーザーが突然操作しなくなったのではなく、トリガーが機能しなくなっています。流入元に突然未知のチャネルが増えたら、UTMが悪用されていないかを確認します。

月次レビューを公式サイト保守で毎月やる6つのことのチェックリストに入れ、毎月1日に必ず実行することをおすすめします。B2Bサイトは流入が少ないため、1週間のデータでは問題が見えません。週次で前週比、月次で前年同月比を比較して初めて異常が浮かび上がります。レビューのたびにスクリーンショットを1枚保存しておき、3か月後に見返して傾向を比べると、数字そのものを見るより役に立ちます。

FAQ よくある質問

最後に

GA4の導入は、技術的には難しくありません。本当に難しいのは「設置後に誰が検証するか」です。多くのチームはgtagを貼った時点で完了とみなしますが、3か月後に振り返るとフォームイベントが一度も発火しておらず、それまでのデータに基づく意思決定がすべて絵に描いた餅だったと気づきます。

実施は3ステップ。第一に、グローバルコードはgtag直設置かGTMのどちらか一方にし、両方は使わない。第二に、カスタムイベントは4から8個に抑え、それぞれを1つの業務課題に対応させる。第三に、公開当日にDebugViewで全経路を確認し、3日目にリアルタイムレポートを照合し、7日目にデータ集計が正常か確認する。データ経路が通って初めて、独立サイト技術その他の最適化に測定の土台ができます。

覚えておきたい一言。GA4の計測をDebugViewで確認せずに公開するのは、電力量計を取り付けても配線しないのと同じ。明かりがつくかどうかは永遠にわかりません。