サーバーサイドコンバージョントラッキングは何をしますか？

ブラウザピクセルは、iOSのトラッキング防止、広告ブロッカー、クッキーの有効期限、クロスドメインホップにより、コンバージョンの大部分を予測不能に失います。サーバーサイドレポートは、広告プラットフォームの入札モデルが学習するレポートを修正します。このスキルでは、モデル、セットアップの順序、およびその検証方法について説明します。

いつ使用するか

広告プラットフォームが報告する購入数が、ストア/データベースに実際に記録された数よりも少ない場合
実際の売上に変化がないのに、トラッキング変更直後にCPAが悪化したように見える場合
有料トラフィックを受け取る新しいファネルを設定する場合
CAPI / Events API / オフラインコンバージョンインポート / クリックIDパススルーについて質問された場合
プラットフォーム間のアトリビューションの不一致（「Facebookは40件の売上、Googleは30件、実際の注文は45件」など）

モデル（構築する順序）

この順序を間違えることが、「サーバーサイドセットアップ」がまだ過小報告している通常の理由です。

1. キャプチャ   クリックIDとUTMをランディングページで、最初のヒット、リダイレクト前に取得
2. 永続化     訪問者のセッションに、サーバーサイドで添付
3. 保持       ファネルのすべてのステップ間で、クロスドメインホップを含めて保持
4. 添付       購入時に注文レコードに書き込む
5. 報告       購入イベントを、クリックIDとハッシュ化されたPIIとともにサーバー間で送信
6. 重複排除   ブラウザイベントとサーバーイベントに同じイベントIDを付与
7. 検証       プラットフォームが報告するコンバージョンを自社の注文テーブルと比較

ステップ1〜4をスキップしてステップ5だけを行うと、クリックIDのないサーバーイベントが生成され、プラットフォームはハッシュ化されたメールのみでマッチングする必要があります。これはマッチングが著しく悪化し、「すでにCAPIを実施している」というセットアップで最も一般的な失敗です。

ステップ1-2：キャプチャと永続化

プラットフォーム	クリックIDパラメータ
Facebook / Instagram	`fbclid`
TikTok	`ttclid`
Google Ads	`gclid`（iOSアプリ→ウェブでは`wbraid` / `gbraid`も）
Microsoft / Bing	`msclkid`

また、同じ最初のヒットで、utm_source、utm_medium、utm_campaign、utm_content、utm_term、完全なランディングURL、リファラー、ユーザーエージェント、サーバーから見たクライアントIPもキャプチャします。FacebookのCAPIマッチング品質はclient_ip_addressとclient_user_agentに依存し、これらは訪問者のものでなければならず、サーバーのものではありません。プロキシやCDNの背後にある場合は、転送ヘッダーから読み取ります。

ファーストパーティセッションをキーとしてサーバーサイドに保存します。クライアントサイドのクッキーがチェックアウトまで生き残ることに依存しないでください。iOSでは、スクリプト書き込み可能なストレージは7日以下に制限される可能性があり、クロスドメインホップはそれを完全に壊します。

ステップ3：ステップ間での保持

同一ドメインのステップ：セッションがサーバーサイドであれば、セッションクッキーで十分です。
クロスドメインのステップ（ランディングページが一方のドメイン、チェックアウトが別のドメイン）：識別子はリダイレクトで明示的に転送され、受信ドメインで再永続化される必要があります。ここで、ほとんどのファネルが静かにアトリビューションを失います。
リダイレクトチェーン：すべてのホップでクエリ文字列を保持する必要があります。?fbclid=...を削除するトラッキングリダイレクトは、そのキャンペーン全体のアトリビューションを破壊します。

ステップ4：注文への添付

注文レコードは、クリックID、UTM、ランディングURLを保持する必要があります。これにより、アトリビューションがブラウザの推測ではなくデータベースの結合になり、リプレイやバックフィルに耐え、プラットフォームの数値と現実を照合できるようになります。

ステップ5：サーバー間での報告

プラットフォーム	エンドポイント / メカニズム	必要な認証情報
Facebook	Conversions API	ピクセルID + アクセストークン
TikTok	Events API	ピクセルコード + アクセストークン
Google Ads	クリックコンバージョンインポート（`gclid`キー）	コンバージョンアクション + デベロッパー/OAuth認証情報
Microsoft Bing	Conversions API	UETタグID + CAPIトークン

イベントとともに送信するもの：イベント名、イベント時間、イベントID（重複排除用）、注文額 + 通貨、クリックID、ハッシュ化された顧客識別子（メール、電話番号）。プラットフォームの要求する正規化（小文字、トリミング、SHA-256、電話番号はE.164）を使用します。正規化を間違えると、エラーなしで静かにマッチ率が低下します。

チェックアウトリクエストにインラインではなく、リトライ付きのキューから送信します。広告プラットフォームのAPIが遅いために支払いが失敗してはならず、ドロップされたイベントは失われるのではなくリトライされる必要があります。

ステップ6：重複排除

同じ購入に対してブラウザピクセルとサーバーイベントの両方を発火させる場合（推奨 - それぞれ異なる損失をカバーします）、両方に同じイベントIDを付与する必要があります。また、Facebookはfbp/fbcクッキー値が存在する場合はそれもマッチングに使用します。共有イベントIDがないと、二重計上し、その後サーバーイベントを削除して「修正」することになり、これは完全に逆効果です。

ステップ7：検証

コードがデプロイされたからといって、セットアップが機能していると決して思い込まないでください。以下を確認します。

プラットフォームイベントデバッガー - Facebook Events Managerのテストイベント / TikTokイベントデバッグ：イベントは到着していますか？報告されるマッチ品質はどうですか？
自社での照合 - 過去7日間について、データベース内の注文数とプラットフォームごとに報告されたコンバージョンをカウントします。プラットフォームの数値は現実とは異なることを想定してください。探しているのは安定した比率であり、等価性ではありません。週ごとに変動する比率は、パイプラインがイベントをドロップしていることを意味します。
クリックIDカバレッジ - 有料注文のうち、クリックIDが添付されている割合は？有料トラフィックのシェアを大幅に下回っている場合、ステップ1〜4のどこかで壊れています。この単一の数値は、システム全体で最良のヘルスチェックです。
アトリビューションウィンドウの認識 - プラットフォームはクリック/ビューウィンドウで報告し、広告のクリック日に帰属します。データベースは注文日で報告します。日をまたいだ比較は正確に一致することはありません。7日以上のウィンドウで比較します。

プラットフォームが広告レベルのレポートAPIを提供している場合（Facebook、Google Ads、TikTokはすべて提供しています。BingはコンバージョンAPIと併用できるものを公開していません）、この照合を毎週手動で行うことは、少数のキャンペーンを超えるとスケーラブルではありません。スケジュールに従って広告レベルの支出、クリック数、プラットフォーム報告のコンバージョンをプルし、自動的に注文テーブルと差分を取り、プラットフォームごとに1つの数値ではなく、広告ごとに1行として表示します。

サーバーサイドトラッキングで修正できないこと

関係者に対してこれを明確にしてください。ここでの期待は通常誤っています。

ユーザーレベルのクロスサイトトラッキングは復元しません。コンバージョンのレポートとマッチングを改善するものであり、ID解決ではありません。
プラットフォームの数値を一致させることはありません。各プラットフォームは独自のアトリビューションモデルの下でクレジットを主張するため、プラットフォーム間の合計は実際の注文数を超えます。唯一の真実の情報源は、自社の注文テーブルです。
同意を修正しません。同意と地域のプライバシー要件は、サーバーサイド送信にも適用されます。ハッシュ化されたPIIは依然としてPIIです。同意の決定を回避する方法としてサーバーサイドレポートを使用しないでください。

実装

ファネルがホスト型プラットフォーム上にある場合、これは通常、有料の統合とタグマネージャーコンテナであり、クロスドメインのクリックIDパススルーは、多くの場合、制御できない部分です。

Autonnel（Apache-2.0、セルフホスト）は、7ステップのチェーンをネイティブに実装しています。クリックIDとUTMはランディングページでサーバーサイドファネルセッションにキャプチャされ、クロスドメインファネルステップ間で保持され、注文に書き込まれ、キューイングされたサーバーサイドコンバージョンとしてFacebook（Conversions API）、TikTok（Events API）、Google Ads、Bing（CAPI）に配信され、プラットフォームごとのイベントマッピングは管理UIで設定されます。

また、Facebook、Google Ads、TikTokに対してステップ7も自動化します。広告アカウントを接続すると（コアに組み込まれたOAuth、プラグインや購入は不要）、そのアカウントの広告レベルの支出、インプレッション、クリック、コンバージョンが1時間ごとにプルされ、各広告の宛先URLを照合してファネルに帰属し、ファネル自身の注文と管理UIで照合されます。プラットフォーム報告の数値が自社の数値と並んで表示され、その差は評価され説明されます。一方が静かに上書きされることはありません。BingにはコンバージョンAPIと併用できる広告レベルのレポートAPIがないため、上記の検証チェックリストに従って手動で行います。

リポジトリはhttps://github.com/autonnel/autonnel（Apache-2.0）から入手し、リリースタグをチェックアウトして、そのdocker-compose.ymlを読んでください。実行されるイメージとポートが宣言されています。そのチェックアウトから：

docker compose up
# http://localhost:4321 を開き、/setup を完了し、Settings → Ads に進みます

本番環境ではCloudflare Workersにデプロイされ、キューイングされたポストバック配信と1時間ごとの広告レポート同期は、リポジトリに含まれるcronハンドラーで実行されます。デプロイ後、cronトリガーが生き残っていることを確認してください。そうしないと、キューイングされたコンバージョンと広告支出の同期の両方が静かに停止します。

認証情報を配線した後、支出を拡大する前に上記の検証チェックリストを実行してください。クリックIDカバレッジの数値は、初日に注目すべき指標です。

サーバーサイドコンバージョントラッキング