Advertising Studioにおける同期頻度の誤算：Salesforceコンサルタントとしての私の後悔

advertising studio で実際にやらかした判断

当時の私は、Salesforceコンサルタントとして、クライアントの「Sales Cloudで特定の行動をした顧客に、すぐにFacebook広告を出す／止める」という要望に対して、今思うと楽観的すぎる判断をしていました。

プロジェクトの初期フェーズ、まだ要件定義の詰めが甘い段階で、私はAdvertising StudioとSales Cloudの連携について「Marketing Cloud Connect (MCC) を使ってデータを同期すれば問題ないでしょう」と軽く考えてしまっていたのです。

クライアントの要望はシンプルでした。

• Sales Cloudで「商談フェーズが"契約済み"になった顧客」には、新製品の紹介広告をすぐに停止したい。
• Sales Cloudで「特定の商品を購入した顧客」には、その商品の関連アクセサリの広告をすぐに表示したい。

「すぐに」という言葉を、私は「翌日には反映される」程度に解釈していました。MCCの同期設定は通常、一日一回がデフォルトで、それで多くのユースケースはカバーできるという経験則があったからです。当時は、Marketing Cloudでのメール配信もキャンペーンも、だいたい日次で動かすことが多かったので、その感覚に引きずられていたのだと思います。

「すぐに」の解釈ミスとMCCの現実

私が提案したのは、Sales Cloudから特定のオブジェクト（取引先責任者やカスタムオブジェクト）のデータをMCC経由でMarketing Cloudのデータエクステンション (DE) に同期し、そのDEをAdvertising Studioのオーディエンスソースとして利用するという、ごく標準的なアーキテクチャでした。

しかし、ここで問題になったのが「同期頻度」と「広告プラットフォームへの反映タイムラグ」でした。

MCCのデータ同期は、Sales Cloudのレコードが変更されたとしても、リアルタイムでMarketing Cloudにプッシュされるわけではありません。設定にもよりますが、最も頻繁な同期設定でも、Sales Cloud側のデータがMarketing Cloud側に反映されるまでに数時間から半日程度のタイムラグが発生します。これはSales CloudのAPIコール制限 (Governor Limits) やMarketing Cloud側の処理負荷を考慮した設計であり、無理にリアルタイムに近づけようとすると、パフォーマンス問題やエラーのリスクが高まります。

加えて、Marketing CloudのオーディエンスがAdvertising Studioを通じてFacebookやGoogleといった広告プラットフォームに連携されても、そのプラットフォーム側でオーディエンスリストが更新され、実際に広告のターゲティングに反映されるまでにさらに数時間、場合によっては一日近くかかることがあります。

当時の判断：優先度を間違えた「シンプルさ」

この「同期のタイムラグ」と「広告プラットフォームの反映タイムラグ」の二重の遅延について、私はクライアントに明確な説明を怠っていました。なぜか？当時の私の思考は「いかにシンプルに、既存の機能で要望を満たすか」に傾倒していたからです。複雑なリアルタイム連携を提案して、プロジェクトのスコープが広がり、コストが増えることを避けたいという思いが強かった。結果的に、それがクライアントの期待値との大きなギャップを生む原因となりました。

クライアントは「商談がクローズした瞬間に広告が止まる」「商品を購入した瞬間に新しい広告が表示される」という、非常にリアルタイムに近い顧客体験を求めていました。これは、Sales Cloudでのデータ更新がトリガーとなり、数分以内にMarketing Cloud、そしてAdvertising Studio、最終的に広告プラットフォームまで連携されるような、かなりアグレッシブな設計が求められることを意味します。

後から「やらなければよかった」と思った設計

結果として、クライアントからは「なぜ広告がすぐに止まらないのか」「購入したはずなのに、まだ同じ広告が表示されている」といったクレームが頻発しました。

私が後悔したのは、以下の点です。

1. 「すぐに」の定義の曖昧さ: クライアントの言葉を鵜呑みにせず、具体的な時間軸（分単位、時間単位、日単位）での合意形成を最初に行うべきでした。
2. MCCの限界説明の不足: MCCがリアルタイム連携ツールではないことを、もっと丁寧に、技術的な制約（Governor Limits等）と合わせて説明すべきでした。
3. 代替案の検討不足: 当時、MCC以外の方法（例えば、Sales Cloudから特定のイベントをトリガーとしてMarketing CloudのAPIをコールし、Marketing Cloud内でオーディエンスを即時更新、Advertising StudioのAPIを使ってオーディエンスをプッシュするなどのカスタム連携）も考えられましたが、コストと複雑性を理由に検討候補から外してしまいました。今なら、この「リアルタイム性」がビジネスにとってどれほど重要かを見極め、代替案とそのコストを提示するでしょう。
4. Advertising Studio側の制約説明の不足: 広告プラットフォーム側でのオーディエンス更新にタイムラグがあることも、明確に伝えるべきでした。

当時の私は、Salesforceの標準機能の適用範囲を広げすぎて、クライアントの期待値をコントロールしきれませんでした。MCCを使えば「できる」という判断は正しかったのですが、「どれくらいの速度でできるか」という最も重要な部分を見誤っていたのです。

これは当時の自分向けのメモだ。