広告のコンバージョンが以前より少なく見えるとき、成果が落ちたのか、計測が届かなくなったのかを切り分けられていますか。Microsoft Advertisingは、サーバーから直接コンバージョンを送るConversions API（以下CAPI）の実装ガイドを公式ドキュメントとして公開し、8月に内容を更新しました。ブラウザの制限や広告ブロックで計測が欠けるときに備える手段として位置づけられており、必要な準備、送り方の選択肢、二重計上を避ける設計まで一通りが書かれています。日本ではまだ実務の話題になりにくい領域ですが、対応の考え方は他の広告プラットフォームにも共通します。ドキュメントに書かれている範囲で内容を整理します。
公開されたのは「サーバーから送る」ための手引き
ドキュメントの定義は明快です。CAPIは、広告主のシステムからコンバージョンや顧客の行動データをMicrosoft Advertisingへ直接送るための、サーバー側の仕組みだとされています。ヘルプ側のページでは、計測をサーバー側へ移すことで、ブラウザの制限、プライバシー設定、広告ブロックがクライアント側の計測を妨げる場合でも、より確実な計測を助けると説明されています。
ここで押さえておきたいのは、CAPIがUETタグ（Microsoft Advertisingのタグ計測の基盤）の代わりに置かれたものではない、という点です。ドキュメントは、可能な限りCAPIをUETと併用することを推奨しています。UETはブラウザ側の行動とページの文脈を捉え、CAPIはUETが発火したあとに起きる出来事や、ブラウザからは見えない詳細を送るための経路として説明されています。片方に寄せるのではなく、二つの経路を重ねる前提です。
もう一つ、ヘルプ側には「この機能はまだ全員が使えるわけではない」という注記が置かれています。アカウントによっては提供されていない段階だということです。始める前に、自社のアカウントで使える状態かどうかを確認するところからになります。
何を送れるのか：4種類のイベントを1つの設定に
ドキュメントが挙げているのは、ウェブサイトのイベント、CRMのイベント、オフラインの販売取引、モバイルのイベントの4種類です。これらを1つの設定でまとめて送れることが、CAPIを使う理由の一つとして書かれています。広告主が使う理由として並んでいるのは、コンバージョン計測の精度を上げること、オンライン・オフライン・CRM・アプリのイベントを1つの設定で送れること、アトリビューションの網羅性を上げること、動的リマーケティング向けのオーディエンス作成を支えること、ブラウザだけに依存した計測を減らすこと、そしてプライバシー要件の変化に備えることです。
送るイベントは2種類に分かれます。ページ読み込みのイベント（pageLoad）と、カスタムイベント（custom）です。ページ読み込みのイベントは、ページビューやシングルページアプリケーションの画面遷移ごとに1件送り、ページのURL、リファラー、タイトル、キーワードといったページの文脈を含みます。カスタムイベントは、購入完了、フォーム送信、カートの操作、検索結果の表示、商品の閲覧といった、より具体的な行動を送るためのものです。カスタムイベントがあるページ読み込みに対応するときは、同じpageLoadIdを含めることで、その行動がどのページで起きたのかを結び付けられると書かれています。
売上金額の扱いには一つ癖があります。ページ読み込みのイベントには売上の値を直接載せられないため、遷移先URLを条件にした目標へ変動売上を渡したい場合は、売上の値だけを持つカスタムイベントを別に送り、pageLoadIdを一致させる必要があります。実装のときに気付きにくい部分です。
導入は4つの段階に分かれている
ドキュメントは実装の流れを4段階に整理しています。第1段階は準備の確認です。アカウント、UETタグ、認証トークン、コンバージョン目標、同意の扱い、識別子、検証の担当者がそろっているかを、着手前に確かめます。第2段階は、データをどの経路で送るかを決めることです。第3段階で、どのイベントを送るのか、それぞれのイベントがどの目標に対応するのか、必須の項目は何か、照合・アトリビューション・同意・ID Sync・重複排除にどの入力が要るのかを定義します。第4段階は公開後の検証と監視で、イベントが受理されているか、エラーが出ていないか、コンバージョンとオーディエンスが想定どおりに動いているかを見続けます。
順序として注目したいのは、第1段階が技術ではなく在庫確認だという点です。タグのIDやトークンだけでなく、同意の扱いをどうするか、誰が検証するかまでを最初の関門に含めています。実装が終わってから「同意が無い利用者の分をどう扱うか決めていなかった」と気付くと、送信済みのデータをさかのぼって整理することになります。
3つの送り方と、選び方の目安
データの送り方は3つ示されています。1つ目は直接APIを実装する方法で、エンジニアリングの体制があり、独自のデータモデルや直接の制御が必要な場合に向くとされています。例として、小売事業者が自社の受注システムから購入と決済のイベントを直接送る形が挙げられています。2つ目はパートナー連携で、すでに顧客データ基盤（CDP）や外部ツールでコンバージョンデータを集めている場合の経路です。ただし、パートナー側が設定やマッピングを担っても、正しいアカウント、UETタグ、トークン、コンバージョン目標、同意の扱い、識別子を用意するのは広告主側だと明記されています。3つ目はタグマネージャー（サーバーサイドのタグマネージャーを含む）で、独自開発を抑えて早く始めたいウェブ中心の広告主向けとされています。
現時点のパートナーとして名前が挙がっているのは、Commanders Act、Freshpaint、Invoca、MetaRouter、Segment/Twilio、Stape.io、Tealiumです。Adobe Real-Time CDPとSwitch Growthは「coming soon」と書かれています。自社が使っている基盤が並んでいれば、直接実装より短い道があるということです。
二重計上と取りこぼしを防ぐ仕組み
UETとCAPIを併用すると、同じコンバージョンが二重に数えられる恐れがあります。ドキュメントの答えは、両方に同じeventIdを渡し、eventNameをそろえることです。加えて、同じUETタグIDを使うことも重複排除の条件として挙げられています。再送するときも同じeventIdを保つように、と書かれています。エラーからの復旧手順に、重複を作らないための条件が組み込まれている形です。
逆に、取りこぼしを減らすための仕掛けも複数あります。1つはMSCLKID（Microsoftのクリック識別子）です。自動タグ付けが有効なとき、広告クリック後の遷移先URLにmsclkidが付与されます。CAPIで送る場合はこの値を自分で保存し、以降のイベントに最新の値を含めることが求められています。保存先はファーストパーティのCookie、ローカルストレージ、サーバー側のいずれでもよく、推奨される保持期間は90日、形式はUUIDです。
もう1つはID Syncです。これは広告主側の訪問者IDとMicrosoft側のIDを結び付ける仕組みで、動的リマーケティングでは必須、コンバージョン計測の品質のためにも推奨とされています。重要なのは、これをサーバー側ではなくクライアント側のピクセルとして実装するよう明記されている点です。サーバーから呼ぶとブラウザの文脈が読めないためで、できるだけ多くのページ、少なくともセッションに1回、できれば最初のページビューで発火させるよう書かれています。そしてID SyncのVIDと、CAPIで送るanonymousIdは一致している必要があります。
個人を特定しうる値の扱いも決められています。メールアドレスと電話番号はハッシュ化して送ります。メールは前後の空白を落とし、ユーザー名部分のドットを除き、プラス記号以降の別名を外し、全体を小文字にしてからSHA-256で処理し、小文字の16進数で表記します。電話番号は国番号付きのE.164形式に正規化してからSHA-256です。生のメールアドレス、生の電話番号、実際のユーザーIDを送ってはならないと繰り返し書かれています。同意の状態はadStorageConsentで表し、既定では許諾ありとして処理されます。拒否を表す値で送られたイベントは、コンバージョンのアトリビューションやリターゲティングを含め、広告目的には使われないとされています。
送信の条件と、成功したように見える失敗
送信先はcapi.uet.microsoft.comのエンドポイントで、UETタグIDをパスに含め、認証トークンをBearer方式でヘッダーに入れたPOSTリクエストとして送ります。成功するとHTTP 200、失敗するとHTTP 400またはHTTP 401がエラーの詳細とともに返ります。イベントは1件ずつでもまとめてでも送れますが、リアルタイムでの送信が推奨されており、1回のバッチ送信で送れるイベントの上限は1,000件です。イベントの時刻は直近7日以内である必要があり、これを外れると無効なイベントとして扱われます。
実務で気を付けたいのは、検証の扱いが2段階になっていることです。必須項目の欠落や不正なイベント種別、不正な時刻は「検証エラー」となり、既定ではバッチ全体が処理されずHTTP 400が返ります。一方、リファラーURLの形式不正、ハッシュ形式が正しくない識別子、対応していない通貨といった任意項目の問題は「検証の警告」として扱われ、その項目だけが取り除かれたうえでイベントは処理されます。このとき返るのはHTTP 200です。つまり、成功の応答を受け取っていても、送ったつもりの識別子が落ちている状態がありえます。ドキュメント自身が、警告が付いた応答は「データの一部が失われた」と見なすよう促しています。監視するのは成功率だけでは足りず、警告の内容まで記録しておく必要があります。
なお、バッチのうち一部だけを通したい場合はcontinueOnValidationErrorという指定があり、有効なイベントが1件でもあればHTTP 200が返って、除外されたイベントの詳細が応答に含まれます。ただし、これを有効にすると不良データが見えにくくなるため、除外された件数を別に監視するよう書かれています。
日本の実務者が参考にできる点
第一に、この仕組みが解こうとしている問題は、プラットフォームを問わず同じだということです。ブラウザ側の制限が強まるほど、クリックと成果を結ぶ線は切れやすくなります。サーバー側から送る経路を持つかどうかは、Microsoft広告に出稿しているかどうかとは別に、自社の計測設計の論点になります。まず確認すべきは、購入や申し込みの確定を自社のサーバーが把握しているか、その時点でクリック識別子や注文IDを保持できているか、という点です。ここが無ければ、どのプラットフォームのサーバー側計測も始められません。
第二に、準備の中身が技術以外にも及ぶことです。ドキュメントが最初の関門に置いたのは、同意の扱いと検証の担当者でした。日本でも、個人に関わる値を送る場合は、取得時の説明とプライバシーポリシーの記載が実態と合っているかを先に確認する必要があります。ハッシュ化すればそのまま送ってよい、という話ではありません。何を送るかを決める前に、送ってよい範囲を決める順序になります。
第三に、二重計上への備えです。タグとサーバーの両方から同じコンバージョンを送る構成では、識別子を共通化しない限り数が膨らみます。CAPIの答えは共通のeventIdでしたが、これは他のプラットフォームでも同じ形の仕掛けが用意されています。サーバー側計測を検討するときは、送る方法より先に、同じ成果を一意に指す値を自社の受注データの中に持てるかを確かめるのが近道です。
留意点として、ここに書いた内容はすべてMicrosoftの公式ドキュメントの記載であり、実際の計測精度がどれだけ改善するかを示す数値は、この出典には含まれていません。また、機能の提供範囲が全アカウントではないことがヘルプに明記されています。自社で使えるかどうか、料金や契約上の条件があるかどうかは、この出典からは確認できませんでした。
出典と注記
この記事はMicrosoft Advertisingの公式ドキュメント（Microsoft Learn）のみを出典とし、項目名・上限値・日数は原文の表記のまま記載しました。単位や通貨の換算は行っていません。ドキュメントは更新される前提で公開されているため、実装前に最新の記載を確認してください。日本国内での提供状況、および導入による効果の数値は、この記事の出典からは確認できませんでした。
この分野の実務を相談したい方へ
記事で扱っている内容は、当社が実務として支援している領域です。 自社で進めるか外部に任せるかの判断からご相談いただけます。