server-side-conversion-tracking

広告の管理画面が報告する購入数が、実際の注文より少ないときに効きます。iOS の追跡防止、広告ブロック、Cookie の寿命、ドメインをまたぐ移動で、ブラウザのタグは成果の一部を取りこぼします。

このスキルは、サーバーから各社へ成果を送り直して報告を正すための、作る順序と確かめ方を与えます。直すのは「報告」で、広告の入札の仕組みが学ぶのはこの報告だ、という立場です。

• 数が合わない広告の管理画面の購入数が、自社の注文の記録より少ない
• 急に悪化した計測を変えた直後に獲得の単価が悪化したのに、実際の売上は変わっていない
• 新しく作る有料の集客を受ける新しい販売の流れを作る
• 用語の相談CAPI、Events API、オフラインのコンバージョンの取り込み、クリックの ID の引き継ぎ
• 各社の食い違い「Facebook は 40 件、Google は 30 件と言うが、注文は 45 件」

7 段の順で作る

本文は、この順を守らないことがサーバー側の計測でも取りこぼす、いつもの原因だとしています。

1. 取り込む着地のページの最初の表示で、転送の前にクリックの ID と UTM を取る
2. 残す訪問者のセッションに、サーバー側で結び付ける
3. 運ぶドメインをまたぐ移動も含め、すべての段で持ち続ける
4. 記録する購入の時点で注文の記録に書き込む
5. 送るクリックの ID とハッシュにした個人の情報を付けて、サーバーから送る
6. 重複を除くブラウザとサーバーの同じ購入に、同じイベントの ID を付ける
7. 確かめる各社の報告を自社の注文の表と比べる

5 段目だけをやると、クリックの ID の無いイベントになり、各社はハッシュにしたメールアドレスだけで照合することになります。本文はこれを「CAPI はもうやっている」という環境でいちばん多い失敗だとしています。

各社のクリックの ID

• Facebook / Instagramfbclid
• TikTokttclid
• Google 広告gclid（iOS のアプリから Web では wbraid / gbraid も）
• Microsoft / Bingmsclkid

同じ最初の表示で、UTM の 5 項目、着地の URL、参照元、ユーザーエージェント、サーバーから見た訪問者の IP も取ります。CDN や代理の後ろでは、自社のサーバーではなく訪問者の値を、転送されたヘッダーから読む決まりです。

注文の記録にクリックの ID を持たせる理由

4 段目で注文の記録にクリックの ID、UTM、着地の URL を持たせると、成果の帰属がブラウザの推測ではなくデータベースの結合になります。送り直しや後からの取り込みにも耐え、各社の数字を実際と突き合わせられるようになる、と本文は説明しています。

5 段目で送る項目は、イベントの名前と時刻、重複を除くためのイベントの ID、注文の金額と通貨、クリックの ID、ハッシュにした顧客の情報です。

一番の健康診断は「クリックの ID の付いた注文の割合」

確かめる段では、各社の検証の画面、直近 7 日の自社の注文との突き合わせ、クリックの ID の付いた注文の割合、成果を数える期間の違い、の 4 つを見ます。

各社の数が実際と一致することは期待せず、比率が安定しているかを見ます。比率が週ごとに揺れるなら、途中でイベントが落ちています。

計測の全体を設計したいとき

このスキルは購入の成果をサーバーから送る一点に絞っています。何を決めるための計測か、どのイベントを取るかから組み立てるなら analytics のほうが向きます。

広告の運用そのものを相談したいとき

入札や予算配分、広告の作り方は範囲外です。広告の運用なら ads を見てください。

利用者を追いかけたい・各社の数をそろえたいとき

本文は「できないこと」を利害関係者に先に伝えよとしています。サイトをまたいだ個人の追跡は戻らず、各社はそれぞれの基準で手柄を主張するので、各社の合計は実際の注文を上回ります。正しいのは自社の注文の表だけです。

個人の情報を外部へ送る仕組みです

ハッシュの前の整え方は、小文字にして空白を除き、SHA-256 にかけ、電話番号は国際形式（E.164）にそろえます。整え方を誤ると、何のエラーも出ずに照合の率だけが下がる、と注意されています。

決済を広告の都合で止めない

送信は購入の処理の中で直接行わず、再試行のある待ち行列から送る決まりです。広告の各社の API が遅いせいで決済が失敗してはならず、落ちたイベントは失わずに送り直す、という理由です。

重複を除くつもりでサーバー側を消さない

ブラウザのタグとサーバーの両方から送るのは、取りこぼす場面が違うので勧められています。ただし両方に同じイベントの ID が要ります。

ID がそろっていないと二重に数え、それを「直す」ためにサーバー側を外してしまう、という逆の対処になりがちだと本文は書いています。

ドメインをまたぐと黙って消える

着地のページと決済のページのドメインが違うなら、ID を転送の URL で明示的に渡し、受け取った側で残し直します。転送のたびに URL の後ろの値を残すことも必要で、?fbclid=... を落とす転送が 1 つあるだけで、その広告の成果が丸ごと追えなくなります。

iOS では、スクリプトから書ける保存領域が 7 日以下に制限されることがあるので、ブラウザの Cookie が決済まで残ることを当てにしない決まりです。

公開元の製品の案内が入っている

本文の後半は、公開元が作るセルフホストの販売の仕組み Autonnel（Apache-2.0）の案内です。7 段をそのまま実装していること、Facebook・Google 広告・TikTok の広告の数字を 1 時間ごとに取って注文と突き合わせることが書かれています。

試す手順には、リポジトリを取って docker-compose.yml を読み、docker compose up で起動するコマンドがあります。本番は Cloudflare Workers に置き、定期実行が配置のあとも残っているかを確かめないと送信と取り込みが黙って止まる、とも注意されています。

README は、Autonnel を使うかどうかに関わらず役立つように書いた、としています。7 段と確かめ方は Autonnel に依存しない内容です。

同梱ファイル

同梱ファイルはありません。SKILL.md の 1 枚だけで、大きさは 9,256 バイトです（2026-10-23 時点）。

Bing でも自社の注文との突き合わせを自動にできますか

本文によると、Facebook、Google 広告、TikTok には広告ごとの報告の API がありますが、Bing には成果の送信の API と並ぶ形のものがありません。Bing は確かめる段の一覧に沿って手で比べることになります。

突き合わせはどの期間で比べればいいですか

各社は広告をクリックした日に成果を数え、自社のデータベースは注文の日で数えます。日をまたぐ比較は決して一致しないので、本文は 7 日以上の期間で比べるよう勧めています。

ホスト型の販売サービスでも使えますか

考え方は同じです。ただ本文は、ホスト型では有料の連携とタグマネージャーの組み合わせになることが多く、ドメインをまたぐクリックの ID の引き継ぎは自分では制御できないことが多い、と書いています。