チェックアウト遷移前にCookie情報を引き継ぐ（Cookie Bridging）

何をする工程か

Cookie Bridgingは、チェックアウト遷移前に識別子を注文側へ渡せる形で保存する工程です。
フロントで読むだけではなく、後段のWebhookが読める場所に残すことが重要です。

ダミー実装イメージ

const trackingPayload = [
  { key: "_ga", value: "GA1.1.1234567890.1234567890" },
  { key: "_origin_site", value: "example-store" }
];

await fetch("/api/cart/update-attributes", {
  method: "POST",
  headers: { "Content-Type": "application/json" },
  body: JSON.stringify({ cartId: "dummy-cart-id", attributes: trackingPayload }),
});

上記は説明用のダミー値です。実際のキーや値は公開しない運用を推奨します。

1. まず理解したい「Cookie Bridging」の目的

1-1. なぜ保存先が必要なのか

ブラウザのCookie情報はユーザーの端末内にあり、そのままではサーバー側のWebhook処理から参照できません。購入後にサーバーでCVを送るには、購入前の段階で識別子を注文に引き継げる場所へ一度保存しておく必要があります。ここを設計しないと、注文は取得できても計測に必要な紐付け情報が不足し、購入CVが抜ける原因になります。

1-2. 何を引き継ぐべきか

引き継ぐ情報は多ければ良いわけではなく、運用に必要な最小セットを明確にすることが重要です。初心者向けの実務では、分析識別子、サイト識別子、重複防止や補助判定に必要な情報の3カテゴリに分けると整理しやすくなります。最初から項目を増やしすぎると、デバッグやセキュリティ管理が難しくなるため段階導入が安全です。

1-3. いつ保存するのが適切か

保存タイミングは「購入フローを邪魔せず、かつ最新情報で確定できる瞬間」を選ぶことが大切です。一般的にはチェックアウト遷移ボタン押下時が最も扱いやすく、ユーザー意図が明確で実装ポイントも限定できます。早すぎる保存は古い情報を残しやすく、遅すぎる保存は未保存のまま遷移するリスクがあるため、実行順序を固定化しておくと安定します。

2. 非プログラマーでも押さえたい実装ルール

2-1. fail-open（購入を止めない）

Cookie保存に失敗した場合でも、購入導線を止めない fail-open 方針はEC運用で非常に重要です。計測品質を守ることも大切ですが、売上機会を失う設計は本末転倒になりやすいためです。実務では「購入は継続、失敗は記録して後で改善」が基本になります。これにより、顧客体験を損なわずに計測精度を段階的に高められます。

2-2. ホワイトリスト制御

保存APIで受け取るキーを無制限にすると、意図しないデータ混入や不正入力のリスクが高まります。ホワイトリスト方式で許可キーを明示し、想定外の項目は受け付けない設計にすることで、安全性と保守性を両立できます。特に非プログラマー運用では、受け入れ条件が明確なほどトラブル時の切り分けがしやすく、担当者間の認識ズレも減らせます。

2-3. 入力長と形式の制限

保存値に長さ制限や形式制限を設けると、異常データの流入を初期段階で止められます。制限がないまま運用すると、ログ肥大化、解析失敗、監視ノイズ増加といった二次障害につながりやすくなります。初心者向けの設計では「短い値」「定義された形式」「必要最小限」の三原則を徹底すると、後工程の運用コストを大きく抑えることができます。

2-4. ログ設計

ログは「原因調査に必要な情報だけを残す」ことが重要です。成功/失敗、エラー種別、処理時刻などは記録し、個人情報や秘密値は残さない方針にします。情報を残しすぎるとセキュリティリスクが増え、残さなすぎると障害調査ができません。非エンジニア運用では、調査に使う項目を事前にテンプレート化しておくと、対応品質を均一化しやすくなります。