Personalization Builderでリアルタイム性にこだわりすぎてデータ連携で沼った話

personalization builder で実際にやらかした判断

当時、私はMarketing CloudとSalesforce Personalization (旧Interaction Studio) を組み合わせた、まさに「顧客が今、何を見ているか、何に興味を持っているか」を起点にしたリアルタイムパーソナライズの実現に燃えていました。顧客からは「Webサイト上の行動履歴だけでなく、メール開封や購入履歴といったMarketing Cloud内の統合された情報もすぐに反映させてパーソナライズしたい」という強い要望があり、開発者としてそれに応えようと必死でした。 私がやらかしたのは、この「すぐに」という言葉を真に受けすぎ、かつPersonalization側のデータ同期メカニズムを軽視しすぎたことです。 当初の設計では、Marketing Cloud側のデータエクステンション（DE）が更新されたら、それをトリガーにPersonalization側のプロファイル属性をAPIで即座に更新するというものでした。具体的には、DEトリガーのオートメーションや、SFMCのAPIイベントを契機に、Apexスクリプトや外部MuleSoft (当時は利用していた) を経由してPersonalizationのTrack API (Profile Attributes Update) を叩く形を考えていました。

「即時反映」を求めたAPI連携の泥沼

なぜこの判断に至ったかというと、当時の私は「Personalizationはリアルタイムで動くもの」という強い先入観があったからです。ウェブサイト上でのクリックやビューイベントはリアルタイムで収集される。だったら、Marketing Cloudのデータも同じ粒度で即時反映できるはずだ、と。 特に「メール開封後、すぐにその製品のレコメンドを強化する」といったユースケースでは、DEの更新からPersonalizationのプロファイル反映までの遅延を許容できない、と思い込んでいました。 実際に実装を進めると、すぐに問題に直面しました。 1. **API呼び出しのボトルネック**: Marketing CloudのDEが更新されるたびにPersonalization APIを叩くというのは、想像以上に負荷が高い操作でした。特に、購入履歴のようなトランザクションデータは一括で何百、何千件と更新されることが頻繁にあります。これらの更新イベントを捌ききれず、APIキューが滞留し、結果的にPersonalization側のプロファイル反映に数分から数時間の遅延が発生してしまいました。当時、`POST /api/v1/event` に `user_attribute` を含める形で更新を試みていましたが、単一プロファイルの小規模更新ならまだしも、数千単位のプロファイルの属性を同時に更新しようとすると、リトライ処理の実装やスロットリング管理が非常に複雑になりました。 2. **データ整合性の問題**: APIの遅延やリトライ、一部失敗が発生すると、Marketing CloudとPersonalizationの間でプロファイル属性の整合性が取れなくなる事態が発生しました。「メール開封フラグは立っているのに、Personalization側ではまだ未開封扱い」といった状況が頻発し、パーソナライズの精度が揺らぎ始めました。 3. **コストと複雑性**: このリアルタイム連携を実現するためには、MuleSoftの導入や、SFMC側での複雑なカスタムアクティビティ、エラーハンドリングロジックの実装が必要となり、開発コストと運用コストが跳ね上がりました。結局、リアルタイム性を維持するために、APIのバッチ処理や、SFTP経由での日次・時間単位のバルクアップロードを併用せざるを得なくなりました。つまり、当初目指していた「リアルタイム」は実現できず、最終的には準リアルタイムやバッチ処理に落ち着いたわけです。 使った機能としては、Marketing CloudのJourney BuilderのカスタムアクティビティでREST APIを呼び出したり、SSJSスクリプトからHTTPCalloutを使ったりしました。Personalization側では、Web SDK (Evergage.js) のイベント発行に加えて、バックエンドAPIを使ってプロファイル属性を更新する設計でした。 使わなかった選択肢としては、Personalizationのデータフィード連携（SFTP経由でのバルクアップロード）を当初からメインに据えることでした。なぜ選ばなかったかというと、これも「リアルタイム性」にこだわっていたからです。「SFTPだとタイムラグがある」という思い込みが強く、APIで直接連携することに固執していました。

今なら別の選択をする

今なら、この時の自分にこう助言します。「パーソナライズの真の目的は、顧客体験の向上であり、リアルタイムであることそのものが目的ではない」と。 当時の私なら、まずユースケースを徹底的に洗い出し、その「リアルタイム性」が本当にビジネス価値をもたらすのかを問い直します。そして、Marketing CloudとPersonalization間のデータ連携においては、それぞれのプラットフォームの特性を理解し、無理のない設計を心がけるでしょう。 * **ユースケースの深掘り**: 「メール開封後すぐにレコメンドを強化する」は本当に「秒速」で必要なのか？数分の遅延は許容できないのか？多くのケースで、数十分〜数時間の遅延は許容されるはずです。その遅延が許容できるなら、SFTP経由のデータフィード連携や、Personalization側のバッチインポート機能で十分です。 * **ストリーミングとバッチの使い分け**: ウェブサイト上の行動データはPersonalizationのWeb SDKでストリーミング的に収集し、Marketing Cloud内の統合データ（購入履歴、会員ランクなど）はバッチ処理で日次や時間単位で連携する。これが最も堅牢でスケーラブルな設計です。 * **APIの利用は限定的に**: どうしてもリアルタイムに近い更新が必要な、ごく一部の重要なプロファイル属性にのみAPI利用を限定し、それ以外はバルク処理に任せます。APIの呼び出し回数やペイロードサイズはGovernor Limits (⚠️ 公式ドキュメント確認が必要。Personalization APIには明示的なコールリミットは記載されていないが、サービスとしてスロットリングは発生する) を常に意識し、エラーハンドリングとリトライ戦略は入念に設計します。 あの頃の私は、Marketing CloudとPersonalizationの両方を使いこなせるという自信が、かえって過信を生み、「やればできる」と技術的な難易度を見誤っていました。結果的に、余計な工数とコストをかけ、期待したほどの効果も得られず、一部のパーソナライズは動かなくなるという苦い経験でした。 これは当時の自分向けのメモだ。リアルタイムと「ほぼリアルタイム」の区別をしっかりつけろ。