SNS広告のコンバージョントラッキングの不正確さをどう調査する？

広告管理画面ではコンバージョンが表示されているのに、サイト上では該当する問い合わせが見つからない。あるいは、注文が増えているのに広告プラットフォームのコンバージョン数はほぼゼロ。このような場合、すぐに予算を調整したり、トラッキングコードを再インストールしたりするのは避けましょう。データの差異は、計測基準の違いだけでなく、イベントの送信漏れや重複発火、アトリビューション設定の変更が原因の可能性もあります。原因によって対応が異なるため、安易に変更すると、その後のデータ比較がさらに難しくなることがあります。

調査では、まずフォーム送信の成功や注文の決済完了など、具体的なコンバージョンアクションを1つ選び、「ユーザーのアクション完了、サイトでの記録、イベント送信、プラットフォームでの受信、広告アトリビューション」の順に確認します。まず差異がどの段階で発生しているかを特定し、そのうえで運用担当者、Webサイト開発者、広告アカウント管理者の誰が対応するかを決めましょう。

比較しているものが同じかどうかを確認する

広告プラットフォーム、Webサイトのアクセス解析ツール、CRMの数値は、必ずしもそのまま比較できるとは限りません。広告プラットフォームは広告インタラクションが発生した時刻を基準にアトリビューションする場合がある一方、WebサイトやCRMはフォームの送信時刻を記録します。また、プラットフォームにはクリック後と表示後のアトリビューションによるコンバージョンが含まれることがありますが、CRMに記録されるのは実際にシステムへ登録されたリードです。トラッキングが正常でも、両者に差が生じる場合があります。

確認を始める前に、期間、タイムゾーン、コンバージョンの定義を統一します。特にB2Bサイトでは、「送信ボタンのクリック」「フォーム送信の成功」「有効な問い合わせ」を区別する必要があります。最初のものには入力チェックでエラーになった操作が含まれる可能性があり、最後のものは手作業や業務ルールによる選別が必要です。越境ECでも、注文の作成、決済の成功、返金後の注文を区別し、異なる段階のデータを比較しないようにしましょう。

広告プラットフォームで使用しているアトリビューション期間と、レポートに表示後のコンバージョンが含まれているかも確認します。最近のデータは、処理の遅延や後から行われるアトリビューション調整によって変わることがあります。比較する際は、ある程度の処理時間が経過したデータを使うのが望ましいでしょう。計測基準を確認できない場合は、まず各システムの設定を記録し、差異が異常かどうかを判断します。

実際のユーザー経路をたどって、データが途切れる箇所を特定する

管理可能なテスト環境またはテスト注文を使い、広告のランディングページからユーザーの経路に沿って目標アクションを完了します。テスト前に時刻、ページURL、使用したデバイスとブラウザーを記録します。フォームを送信する際は識別しやすいテスト情報を使用し、テストデータが通常のフォローアップ業務に入らないよう、営業担当者や注文処理担当者にもあらかじめ知らせておきましょう。

テストのたびに、配信中の広告をクリックする必要はありません。Webサイトのイベントが発火するかどうかは、ページに直接アクセスし、プラットフォームが提供するテストツールを使って確認できます。一方、広告アトリビューションが機能するかどうかは別の検証事項です。プラットフォームがサポートするテスト方法と、実際の広告インタラクション条件を踏まえて判断する必要があります。1回のテストで広告にアトリビューションされなかったとしても、それだけでトラッキングコードが機能していないとは言えません。

• Webサイトに記録がない：フォームの入力チェック、APIリクエスト、決済結果の返送、遷移先ページを確認し、ユーザーのアクションが実際に成功したかを確かめます。
• Webサイトには記録があるが、プラットフォームのテストツールにイベントが表示されない：コードの読み込み、イベントの発火条件、データ送信、ユーザーの同意状況を重点的に確認します。
• プラットフォームはイベントを受信しているが、広告レポートにコンバージョンがない：広告キャンペーンで選択されているコンバージョンイベント、アトリビューション条件、テストトラフィックの流入元、データ処理時間を確認します。
• プラットフォームの記録数がWebサイトより明らかに多い：イベントの重複発火、広すぎるイベント定義、表示後のアトリビューションなど、計測基準の違いを確認します。

テストツールでイベントの発火が確認できても、それが示すのは、そのテストでイベントが該当する段階まで届いたということだけです。正しいデータソースから送信されているか、イベント名が広告の最適化目標と一致しているか、実際のユーザーが同意している条件下でも正常に機能するかを、さらに確認する必要があります。

コードが正しく設置されていても、イベント設定が正しいとは限らない

Webサイトのリニューアル、テーマの変更、フォームプラグインの調整、ドメインの移行後には、トラッキングコードが抜け落ちたり、旧版と新版が同時に残ったりすることがあります。まず、プラットフォームのイベント診断ツール、ブラウザーの開発者ツール、またはタグ管理ツールのプレビューモードを使い、対象ページで想定したデータソースが読み込まれているか、アクション完了時にどのイベントが送信されるかを確認します。

フォームでの問い合わせでは、ボタンのクリックを送信成功として扱ってしまうのがよくある誤りです。必須項目が未入力の場合や、APIからエラーが返された場合、さらにはボタンが連続してクリックされた場合でも、数値が過大になることがあります。より確実なのは、Webサイト側で送信成功を確認した後にイベントを発火させる方法です。サンクスページを使用する場合は、ページの再読み込みや直接アクセスによって記録が重複する可能性も考慮しましょう。

ECサイトの注文では、イベントの発火タイミングと注文ステータスを確認します。「決済ページへの到達」を購入成功として扱うと、成約数が過大になります。一方、決済後にサイトへ戻ったページだけに依存すると、サイトへのリダイレクトが正常に完了しなかった注文を取りこぼす可能性があります。決済結果をWebサイトのバックエンドで確認している場合は、サーバーサイドから該当イベントを送信し、注文ステータスと照合する方法を検討できます。

ブラウザー側とサーバー側の両方でトラッキングを行う場合、同じコンバージョンが2つの経路から送信されることがあります。イベント名やイベントIDなど、プラットフォームが求める重複排除の条件が一致しているかを確認してください。プラットフォームによって必要なフィールドは異なるため、イベント発生時刻が近いというだけで、プラットフォームが重複排除すると決めつけてはいけません。多言語サイトでは、各言語のページやサブドメインを個別に確認し、メインサイトのバージョンだけ設定が完全という状態にならないようにします。

イベントが届いていても、アトリビューションの経路を確認する

ソーシャルプラットフォーム広告のコンバージョンでは通常、プラットフォームがイベントと、それ以前の広告インタラクションを関連付ける必要があります。ユーザーがデバイスをまたいでアクセスしたり、異なるブラウザーを使用したり、外部決済ページを経由したり、ブラウザーのプライバシー制限の影響を受けたりすると、関連付けが難しくなることがあります。プラットフォームが特定の注文を広告にアトリビューションしなかったからといって、その注文が広告の影響を受けていないとは限りません。反対に、プラットフォームが報告するアトリビューションコンバージョンも、広告だけがもたらした増分効果と同じではありません。

ランディングページへの遷移を確認する際は、リダイレクト、クロスドメイン遷移、決済ページとの往復の過程で広告パラメーターが失われていないかに注意します。タグ管理ツールでトラッキングを設定している場合は、実際にアクセスされるドメインとページパスが発火ルールの対象になっているかも確認します。サーバーサイドイベントを使用する場合、送信する照合情報はプラットフォームの要件と適用されるプライバシー規則に準拠する必要があります。ユーザーが同意していない、またはトラッキングを拒否している場合は、該当する設定に従って処理し、数値を補うために同意の仕組みを回避してはいけません。

最後にアカウント設定に戻り、広告キャンペーンがどのイベントを最適化対象にしているか、そのイベントが正しいWebサイトのデータソースから送信されているか、最近アトリビューション設定が変更されたかを確認します。修正後は変更日時とテスト記録を残し、同じ計測基準でその後のデータを観察します。差異が続く場合は、Webサイト上の実際の成約数、プラットフォームが受信したイベント数、プラットフォームがアトリビューションしたコンバージョン数をそれぞれ記録しましょう。3つの数値を無理に一致させるよりも、予算を判断するうえで役立ちます。