外部カートシステムでのFacebook Conversion API(CAPI)連携でハマった話：クロスドメイン時のJSON送信の注意点

はじめに

某サブスクリプション向けカートシステムにおいて、Facebook Conversion API（以下、CAPI）をソケット通信機能で導入しようとした際、想定通りの通信ができずハマった事例がありました。
特定の環境下（クロスドメイン等）で発生しやすい事象のようでしたので、同様の構成で構築される方向けに技術的なTipsとして共有します。

遭遇した事象：Meta側で「400 Bad Request」が発生

カートシステムの管理画面から購入イベントをMetaに送信するソケット通信設定を行いましたが、テスト注文を行ってもMeta側では「400」エラーとなり、イベントが正常に記録されませんでした。

設定状況

• 通信方式：ソケット通信
• 送信形式：JSON
• 環境：LP（外部ドメイン）→ カート（標準ドメイン）のクロスドメイン構成

ハマりポイント1：クロスドメイン時のペイロード構造の変化

調査の結果、管理画面で設定したJSONが、送信時に意図しない構造に変化していることがわかりました。

正常な期待値:
dataキーの中に配列としてイベント情報が入る形式
実際の送信内容:
data[0][event_name] のような形式に変換されて送信されていた

カートシステムの仕様上、ドメインを跨ぐ際にトラッキング情報を引き継ぐための処理が介入し、その影響でJSONのBodyデータ構造が変換されてしまうケースがあるようです。

ハマりポイント2：Key/Value形式では要件を満たせない場合がある

JSONではなくKey/Value形式で送信を設定する回避策も検討しました。
しかし、MetaのCAPIはネストされた構造や配列を要求することが多く、単純なKey/Value形式では対応しきれないイベントデータ（詳細な商品パラメータなど）が存在するため、この構成要件では実用的ではありませんでした。

ハマりポイント3：管理画面からのデバッグの難しさ

システムの仕様上、ソケット通信履歴からはHTTPステータスコード（400など）しか確認できず、Meta側からの詳細なエラーレスポンスボディが見えませんでした。
CAPIの実装においては、詳細なエラーメッセージを見ることがデバッグの鍵となるため、ベンダー側に実際の送信リクエストとレスポンスログの調査を依頼する必要がありました。

補足：CAPI連携で役立つ変換用タグ

該当のシステムでCAPI連携を行う際、個人情報のハッシュ化やタイムスタンプの要件を満たすために以下のシステムタグが有用でした。

• @@email@@.sha256: メールアドレスを自動でSHA-256ハッシュ化して出力
• @@ordered_at@@.unixtime: 注文日時をUNIXタイムスタンプ（10桁）に変換して出力

まとめ

SaaS型のカートシステムでCAPIを導入する際、特にLPとカートでドメインが異なる構成を組む場合は、システム側の内部処理によってペイロードが干渉を受けないか事前検証することが重要です。
もし「400エラー」で詰まった場合は、管理画面の設定だけでなく、実際にどのようなBodyでリクエストが飛んでいるのかを確認（必要であればサポートにログ調査を依頼）することをお勧めします。