広告の前に確認すべき、計測の30分チェック

入札や予算、ターゲティングを調整する前に、必ず同じ確認作業を行っています。所要時間は 30分ほどですが、3件に1件くらいの割合で、その後の進め方そのものが変わります。

前提はシンプルです。誤った計測にもとづく最適化は、何もしないより悪い結果になります。 自動入札は、こちらが報告したコンバージョンを正解として学習します。誤った値を渡せば、 誤った相手に確信を持って予算を配分していきます。

手順1：タグが実行されているか

「ソースに入っているか」ではなく、実際に動いているかを見ます。

1. 広告ブロッカーを無効にした状態でサイトを開く
2. 開発者ツールのネットワークタブを開く
3. 各媒体のドメインで絞り込む
4. スーパーリロードしてリクエストを確認する

数秒待ってもリクエストが出なければ、タグは動いていません。管理画面上は「有効」と 表示されているケースも多いため、ここで初めて気づくことがよくあります。

もっとも多い不具合

スクリプトは読み込まれているが、初期化されていないパターンです。Metaピクセルで言えば、 fbevents.js はネットワークタブに出ているのに fbq('init', …) が呼ばれていない状態を 指します。管理画面ではピクセルが検出済みと表示され、データは1件も溜まっていません。

LinkedInの場合は、パートナーIDをグローバル変数に代入しているものの、タグが実際に参照 している配列に追加していない、という形で現れます。

どちらもコードを眺めただけでは正しく見えます。そして、どちらも動きません。

手順2：いつ発火しているか

表示速度を重視した実装では、計測タグをアイドル時間まで遅延させることがあります。意図は 妥当ですが、遅らせすぎるとデータが失われます。

発火タイミング	遅延	データへの影響
head内で即時	なし	欠損なし・速度は最も不利
DOMContentLoaded	ミリ秒	ほぼ欠損なし
window.load	数百ミリ秒	軽微な欠損
requestIdleCallback	最大2秒程度	早い離脱が記録されない

最後の方式では、3秒以内に離脱した訪問者が記録されません。広告経由の流入では例外的な ケースではなく、費用を払って獲得したセッションの相当な割合にあたります。しかも残った データは、関与の深いユーザーに偏ります。

手順3：正しい行動を数えているか

順番に3つ確認します。

• その行動は本当に費用を払う価値があるか。 フォーム送信は相談予約ではありません。 送信の3割が連絡不通になるなら、フォーム送信への最適化は不通の獲得に最適化することを 意味します。
• 重複していないか。 同じイベントを2つのタグが送っていれば、コンバージョン数は 2倍、CPAは半分に見えます。
• 実態と一致するか。 管理画面のコンバージョン数と、同じ期間にCRMへ入った問い合わせ 件数を突き合わせます。完全一致はしませんが、3倍ずれていてよい理由はありません。

手順4：同意管理

EEAや英国からの流入が一定量ある場合は、同意モードv2が4つのシグナルすべてで実装されて いるかを確認します。

新しく追加された2つが見落とされがちです。ad_user_data が許可されていない場合、 Googleは拡張コンバージョンのデータを警告なく破棄します。 エラーは表示されず、 コンバージョン数が静かに減るだけなので、広告の不調と区別がつきません。

// gtag.jsの読み込み前に実行する必要があります。
// タグは発火時点の同意状態を参照するため、
// 後から設定した初期値は無視されます。
gtag('consent', 'default', { /* ... */ });

遅延スクリプトの内部で初期値を設定してしまう実装は、この失敗の典型例です。コードは 存在していて、順序だけが誤っているため、結果として機能していません。

見つかった後にすること

まず計測を直し、そのあと待ちます。2〜4週間ほど正しいデータを溜めてから、成果の判断や 構成の変更を行ってください。自動入札には再学習の時間が必要で、修正後のアカウントを 壊れていた頃の履歴と比べると、良い方にも悪い方にも判断を誤ります。

立ち上がりは遅く見えます。それでも、実態のない数値をもとにもう一四半期を費やすより、 確実に速い方法です。