ブラウザピクセルはアトリビューションの中で最初に機能しなくなる部分です。AppleのIntelligent Tracking PreventionはサードパーティCookieを制限してリファラーを劣化させ、広告ブロッカーはピクセルのネットワーク呼び出しがページを離れる前に取り除き、iOS 14.5のApp Tracking Transparencyは、Metaのシグナル品質をiPhoneトラフィックで大きく低下させたため、Meta自身がブラウザピクセルをバックアップとして扱うようになりました。
サーバーサイドのコンバージョントラッキングは、誰もが同意する答えです。実装こそが人々が誤る部分です。この記事では、URLショートナーがclick_idを所有する際のアーキテクチャを説明します - ショートナーが何をするか、バックエンドが何をするか、広告プラットフォームが何を期待するか、そしてブラウザとサーバーの両方のイベントが発火した際の重複カウントを防ぐ重複排除の形について説明します。
ほとんどのチームが転送する3つのプラットフォーム：Meta CAPI、GA4 Measurement Protocol、TikTok Events API。Mixpanel、Klaviyo、Pinterestもベンダー固有のフィールド名で同様の形式を受け入れます。MetaとGA4については予算の大部分を占めているため具体的に説明します。他のものも同じテンプレートに従います。
なぜサーバーサイドなのか#
短い答え：ブラウザはもはや信頼できるシグナルソースではありません。長い答えは重複排除の設定方法を形成するため理解する価値があります。
ブラウザサイドのコンバージョンを劣化させる3つのこと：
Cookieのパーティショニングと有効期限の制限。 SafariのITPはトップレベルサイトごとにCookieをパーティションし、スクリプトが設定したファーストパーティCookieを7日間に制限します（既知のクロスサイトトラッカーが検出された後は24時間）。FirefoxのTotal Cookie Protectionも同様のパーティショニングを行います。Braveとプライバシー拡張機能のコホートはさらに進んでいます。2018年に機能していたファーストパーティCookieのアトリビューションフローは、2026年には機能しません。
広告ブロッカー。 uBlock Origin、AdBlock Plus、Pi-hole、NextDNS、そしてネットワークレベルのブロッカーは connect.facebook.net、googletagmanager.com、analytics.tiktok.com、その他のマーケティングタグのデフォルトルールを搭載しています。ピクセルは発火せず、コンバージョンは記録されません。
iOS App Tracking TransparencyとiOS 17のリンクトラッキング変更。 ATTはMetaのシグナル品質を低下させました。iOS 17のLink Tracking Protectionは、プライベートブラウジングとMailのクエリパラメータにこれを拡張し、リンクが開かれる前に fbclid、gclid などのリストを削除します。
iOSが多いトラフィックを持つ一般的なShopifyショップへの累積的な影響：ブラウザサイドのピクセルでは25〜40%のコンバージョンが見逃されています。正確な数はトラフィックの構成によって異なります。iOSが多い美容品やアパレルブランドは上限に近い傾向があります。回収された収益の計算がエンジニアリング作業を正当化します - iOS重視のトラフィックで年間€10Mの収益を上げているショップで、ピクセルアトリビューションのギャップが30%ある場合、そのギャップの半分だけを回復しても€1.5Mの帰属可能な収益をそれを促進したプラットフォームに還元できます。
サーバーサイドのコンバージョン転送はギャップの大部分を埋めます。すべては埋めません - click_idが一度も取得されなかったコンバージョン（オーガニック、ダイレクト、ブランド検索）はCAPIでは回収できません - しかしブラウザサイドのブロッキングによるギャップを埋めます。
アーキテクチャ#
データフローは4つのホップです：広告 → 短縮リンク → サイト → サーバーサイド転送。
広告プラットフォーム → 短縮リンク。 MetaまたはGoogle Adsのクリエイティブの転送先は短縮リンクです。ユーザーがクリックすると、短縮リンクのエッジハンドラーがクリックイベントをキャプチャし、click_idを付加した転送先URLにリダイレクトします。
短縮リンク → サイト。 転送先URLには ?elido_click=<id> が付加されています（ワークスペースごとに設定可能）。サイトのタグマネージャーまたはテーマコードがそれを読み取り、ファーストパーティCookieに書き込みます。より重要なのは、カートまたは注文のカスタム属性に書き込むことです。
サイト → 注文。 ユーザーが注文を確定させると（Shopifyのカートが送信され、WooCommerceの注文が作成され、ヘッドレスカートが変換される）、click_idが注文レコードの属性/メタデータに記録されます。これが耐久性のある引き渡しポイントです - click_idが注文に記録されると、Cookieの有効期限やブラウザセッションの有効期限の影響を受けません。
注文 → サーバーサイド転送。 コマースプラットフォームから注文支払いWebhookが発火します。バックエンド（またはElidoに委任している場合はElido）がclick_idを読み取り、コンバージョン転送の認証情報を検索し、接続された各広告プラットフォームにコンバージョンをPOSTします。プラットフォームはコンバージョンを受信し、元のキャンペーンにクレジットします。
ショートナーの役割は、ホップ2でのclick_idとホップ4でのオーケストレーションです。前者は単純で、後者が統合の価値を発揮するところです。
重複排除：誰も本番まで言及しないこと#
最もよく見る本番インシデントは二重カウントです。ブラウザサイドのピクセルがまだページに残っており（Safari以外のトラフィックにブラウザフォールバックが欲しかったためチームが無効化しなかった）、サーバーサイド転送も発火します。Metaが両方のイベントを取り込みます。コンバージョンが二重にカウントされ、予算配分担当者が過剰に引き出し、次のキャンペーン予算レビューで「なぜ報告されたROASが売上の3倍なの?」と気づきます。
修正は重複排除識別子です。Meta CAPIは event_id を受け入れます。GA4 Measurement Protocolは client_id と transaction_id を受け入れます。TikTok Eventsは event_id を受け入れます。ブラウザとサーバーの両方が同じ重複排除IDで同じイベントを送信すると、プラットフォームは一方をクレジットし、もう一方を無視します。
重複排除IDは両側で同じ値でなければなりません。注文IDは購入イベントに機能します - ブラウザサイドのピクセルとサーバーサイドの転送の両方が見ることができます。click_idは上流のイベント（リード、カートへの追加、コンテンツの閲覧）に機能します。これはまだ注文が存在しない場合です。
Metaの重複排除ドキュメントはマッチングウィンドウを説明しています。同じ event_id を持つ48時間以内に受信されたイベントは重複として扱われます。GA4のclient_idベースの重複排除は原則として似ていますが、ドキュメントが少なめです。
運用ルール：すべてのサーバーサイドコンバージョンは重複排除IDを持ち、その重複排除IDはブラウザサイドのピクセルが発行したものと同じでなければなりません。これを省略することは、機能するCAPI統合と、誰かが気づくまで3ヶ月間静かに報告数を膨らませるものの違いです。
ハッシュ化要件#
Meta CAPIとTikTok Eventsはどちらも、メールと電話の識別子を送信前にSHA-256でハッシュ化することを要求します。GA4は厳密には要求しませんが受け入れます。ハッシュ化は顧客識別子に対して行います - em（メール）、ph（電話）、fn（名）、ln（姓）、ge（性別）、db（生年月日）、ct（市区町村）、st（都道府県）、zp（郵便番号）、country（国） - イベントのメタデータではありません。
2つの注意点。第1に、ハッシュ化の前に形式を正規化する必要があります - 小文字、トリム済み、電話から国コードを除去、ダッシュを削除。[email protected] をハッシュ化すると [email protected] をハッシュ化した値とは異なります。プラットフォームは後者を期待します。Metaのパラメータ要件ページにはフィールドごとの正規化ルールが記載されています。
第2に、ハッシュはスペースなしの小文字の16進数でなければなりません。SHA256("[email protected]") は a3b6... を生成します。APIは a3b6... を期待し、A3B6... でも \xa3\xb6... でもありません。ほとんどの言語のSDKはデフォルトで大文字の16進数を返すため、結果を小文字にする必要があります。
Elidoの POST /v1/conversions エンドポイントを経由してルーティングしている場合、ハッシュ化はプラットフォーム側で処理されます - 生のメール/電話をPOSTすると、Elidoがプラットフォーム要件ごとに正規化とハッシュ化を行い、転送します。利点は、バックエンドが維持する正規化ルールが3つのプラットフォーム分ではなく1セットになることです。コストは、転送の瞬間に生のPIIをElidoに信頼することです。リクエストは転送中に暗号化され、サーバーサイドに永続化されませんが、信頼モデルはワイアリングの前に理解する価値があります。
Meta CAPIのPOSTの実例#
プラットフォームが実際に要求するもの。エンドポイントは POST https://graph.facebook.com/v21.0/{pixel_id}/events です。ボディはJSONです。
{
"data": [
{
"event_name": "Purchase",
"event_time": 1716480000,
"event_id": "order-acme-2026-05-23-001847",
"action_source": "website",
"event_source_url": "https://acme.example/checkout/thanks?order=001847",
"user_data": {
"em": ["a3b6...sha256 of email"],
"ph": ["c4d7...sha256 of phone"],
"client_user_agent": "Mozilla/5.0 ...",
"client_ip_address": "203.0.113.42",
"fbc": "fb.1.1716470000.AbCdEf",
"fbp": "fb.1.1716470000.987654321"
},
"custom_data": {
"currency": "EUR",
"value": 89.5,
"content_ids": ["sku-spring-jeans-32-blue"],
"content_type": "product",
"num_items": 1
}
}
],
"test_event_code": "TEST12345",
"access_token": "EAAxxxxxxx"
}
注目すべき3点：
event_id は重複排除キーです。注文IDに設定します。ブラウザサイドの Purchase ピクセルも同じ値を設定します。Metaは48時間のマッチングウィンドウ内で重複排除を行います。
fbc と fbp はMetaのCookie識別子です。fbc はクリック識別子（ランディングURLからの fbclid、プレフィックス付き）で、fbp は _fbp CookieのブラウザID です。どちらもドメインの観点からファーストパーティであり、ランディングページからの永続化後にサーバーサイドでキャプチャできます。これらがない場合はMetaのマッチレートが下がります。ある場合はマッチレートが優れています。
test_event_code はプロダクションのレポートにカウントされないテストイベントを発火させます。必ず最初にこれをワイアリングします。プロダクションのトラフィックを切り替える前にEvents Manager Test Eventsで確認してください。
Elido APIの同等物：POST /v1/conversions に {click_id, event_name: "Purchase", value, currency, order_id, customer: {email, phone}} を送信します。ElidoはMetaの仕様に従って正規化とハッシュ化を行い、クリックイベントからワークスペースの fbc/fbp を検索し、CAPIペイロードを構築します。
GA4 Measurement ProtocolのPOSTの実例#
GA4のワイア形式は形が似ていますが、フィールド名が異なります。エンドポイント：POST https://www.google-analytics.com/mp/collect?measurement_id=G-XXX&api_secret=xxx。
{
"client_id": "click-id-as-fallback-if-no-ga4-cookie",
"user_id": "user-acme-12847",
"events": [
{
"name": "purchase",
"params": {
"transaction_id": "order-acme-2026-05-23-001847",
"value": 89.5,
"currency": "EUR",
"items": [
{
"item_id": "sku-spring-jeans-32-blue",
"item_name": "Spring Jeans 32 Blue",
"quantity": 1,
"price": 89.5
}
],
"engagement_time_msec": 1
}
}
]
}
注記：
client_id は存在する場合のGA4 Cookieの _ga 値です。ない場合はclick_idが使えるフォールバックになります（GA4がそれに対してセッションを作成するため）。
transaction_id は重複排除キーです - 注文IDに設定し、ブラウザの gtag purchase イベントと同じ値にします。GA4はセッションウィンドウ内で重複排除を行います。
engagement_time_msec はアトリビューションにカウントされるために存在し、正の値でなければなりません。1に設定することで要件を満たします。
api_secret はワークスペースレベルです。GA4 MPドキュメントに認証情報の設定方法が記載されています。
リトライのセマンティクス#
プラットフォームはリトライを受け入れますが、盲目的にリトライすることはできません。3つのパターンが機能します。
重複排除IDのべき等性。 プラットフォームの event_id / transaction_id が注文IDである場合、同じペイロードをリトライしても、プラットフォームが重複排除します - 2番目の送信は黙って無視されます。安全です。
5xxに対する指数バックオフ。 MetaとGA4はどちらも時々5xxを返します。バックオフ付きでリトライします（1秒、2秒、4秒、8秒、最大60秒、その後あきらめる）。リトライは同じ event_id を保持し、プラットフォームが部分的に成功したケースを重複排除できるようにします。
4xxはリトライしない。 4xxのレスポンスはペイロードが不正または認証情報が間違っていることを意味します。リトライしても修正できません。リトライはレートリミットのバジェットを消費するだけです。ログに記録し、アラートを出し、上流の問題を修正してください。
Elidoを経由してルーティングしている場合、リトライ/バックオフは処理されます - POST /v1/conversions はすぐに返り、プラットフォームへのファンアウトはバックグラウンドで行われ、リトライの状態は GET /v1/conversions/{id} で観察できます。独自実装する場合は、キューレイヤー（RabbitMQ、Kafka、AWS SQS）がリトライの形状が置かれる場所です。
テストモードとドライラン#
チームが犯す最大の間違いは、ドライランをスキップすることです。
MetaにはTest Eventsがあります。ペイロードに test_event_code を設定すると、イベントが数秒以内にTest Eventsパネルに表示され、形状と重複排除を確認できます。プロダクションのイベントは同じエンドポイントを通りますが、test_event_code はありません。
GA4にはDebugViewがあります。イベントパラメータに debug_mode: 1 を設定すると、イベントがDebugViewに表示され、プロダクションのトラフィックを切り替える前に確認できます。
TikTokも同様のテストモードをEvents Managerインターフェースで持っています。
検証チェックリストは短いです。テスト注文を行い、注文支払いWebhookを観察し、コンバージョン転送の発火を観察し、プラットフォームのテストパネルに着地するのを観察します。event_idがブラウザサイドのピクセルの値と一致することを確認します。値、通貨、content_idsが正しいことを確認します。その後、テストモードを無効にして最初の10件のプロダクション注文を観察します。
これをスキップすると、3日後にレポートがフラットになって統合が壊れていることがわかります。ドライランのスキップは、私が見る最も一般的な単一の失敗モードです。
よくある障害モード#
注文にclick_idがない。 最も一般的なものです。ecommerceコーナーストーンでカバーされています。修正はclick_idをカートから注文までつなぐことです。
ハッシュの不一致。 正規化なしで [email protected] をハッシュ化すると [email protected] とは異なる値が生成されます。プラットフォームはマッチを拒否し、コンバージョンは識別子マッチングなしで着地し、Metaのレポートでは「unmatchedに帰属」となります。修正はMeta CAPIパラメータドキュメントの正規化ルールです。よりクリーンな答えはルールが一箇所に住むようにショートナーにハッシュ化を委任することです。
fbcがキャプチャされていない。 ユーザーがMetaの広告からランディングすると、URLに fbclid が含まれます。ページはそれをキャプチャして永続化する必要があります（通常は注文のカスタム属性に）。fbc がないと、Metaのマッチレートが大幅に低下します。修正は fbc をファーストパーティCookieまたはカート属性に書き込むランディングページのタグマネージャーステップです。
重複排除IDが一致しない。 ブラウザサイドのピクセルが注文IDを使用し、サーバーサイドが転送時に生成したUUIDを使用しています。両方のイベントが取り込まれ、どちらも重複排除されません。修正は、サーバーサイドの転送がブラウザサイドのピクセルが発行したものと同じ event_id 値を使用するようにすることです - 購入に対する注文IDが標準的な答えです。
通貨の不一致。 ブラウザが USD を送信し（gtagの設定がデフォルトでUSDのため）、サーバーが EUR を送信しています（注文がEURのため）。GA4とMetaはどちらも一部のマッチングコンテキストでイベントシグネチャの一部として通貨を扱い、コンバージョンは着地しますがクリーンに集計されません。修正は通貨をページレベルの設定ではなく注文から取得することです。
データプレーンでのこの位置づけ#
コンバージョン転送はより広いアトリビューションパイプラインの一部です。周囲のパイプラインのコーナーストーンはCDPなしでUTMキャンペーンをエンドツーエンドで追跡する方法です - その記事ではワークスペースのUTMテンプレート、キャンペーンレベルのオーバーライド、一括インポート、ドライラン検証ステップを詳しく説明しています。この記事はループを閉じるサーバーサイドのファンアウトのより深い掘り下げです。
運用ガイドについては、コンバージョン転送ドキュメントがステップバイステップです。Elidoがプラットフォームのレートリミットを超えずにファンアウトする方法の詳細については、クリック取り込みアーキテクチャの記事がファイア・アンド・フォーゲットパイプラインをカバーしています。
クラスターを読む#
featuresクラスターの兄弟記事：スマートリンクの説明（コーナーストーン）、リンクイベントのWebhook（より広いイベントの形状）、Meta CAPIへのコンバージョン転送（より深いMeta固有の掘り下げ）。ペルソナ向けのバージョンについてはsolutions/marketersがそのページで、コンバージョントラッキング機能ページが製品のサーフェスです。
ブログの関連記事#
Elidoを試す
URLを貼り付けて短縮リンクを取得
登録不要。リンクは30日間有効。永久に保存するには登録してください。
Free、登録不要 · 1日あたり2件