【SMFC】「うざい配信」を卒業！Frequency Cappingで顧客エンゲージメントを高める設計・実装ガイド

Salesforce Marketing Cloud（SFMC）を運用する上で、最も回避すべきは、同一顧客への過剰なメッセージ送信による「ブランド毀損」と「購読解除」です。本ガイドでは、標準機能である頻度キャップ、AIを活用したEinstein Engagement Frequency、そして自由度の高いSQLを用いたカスタマイズ実装まで、実務担当者が直面する課題を解決するための具体的な手法を解説します。

SFMCにおける配信頻度管理の全体像

SFMCで配信頻度を制御する方法は、大きく分けて「AIによる自動最適化」と「ルールベースの強制制限」の2系統が存在します。それぞれの特性を理解し、ビジネス要件に合わせて組み合わせることが重要です。

標準機能とAI機能の比較

従来、配信頻度の管理は一律に「週に3通まで」といったルールベースで行われてきましたが、現在は顧客一人ひとりの反応（エンゲージメント）を学習し、個別に上限を変動させる手法が主流です。

【実装ガイド】Einstein 配信頻度の最適化（EEF）の設定手順

Einstein Engagement Frequency（EEF）は、SFMCのEinstein AI機能の一つであり、過去90日間のメール送信データとエンゲージメント（開封、クリック等）を分析し、各連絡先を「飽和（Over-saturated）」「最適（On Target）」「未達（Under-saturated）」の4つの層に分類します。

EEFの仕組みと分類ロジック

AIは単に送信数を見るのではなく、以下のエンゲージメントスコアに基づいて層を決定します。

• 飽和（Over-saturated）: 送信数が多すぎて、エンゲージメント率が著しく低下している層。
• 最適（On Target）: 現在の送信頻度で、最も効率よくエンゲージメントを獲得できている層。
• 未達（Under-saturated）: まだ送信の余地があり、追加配信によってエンゲージメント向上が見込める層。

Journey Builderへの組み込みステップ

EEFを利用して、飽和状態の顧客を自動的に配信から除外する手順は以下の通りです。

1. Einstein Frequency Split をジャーニーのキャンバス上にドラッグします。
2. パスの分岐設定で「飽和（Over-saturated）」を選択します。
3. 飽和層のパスの先を「待機」または「終了」に設定し、メッセージ送信アクティビティを回避させます。

【公式情報】

Einstein 配信頻度の最適化のヘルプ – Salesforce公式サイト

関連記事：高額MAツールは不要。BigQueryとリバースETLで構築する「行動トリガー型LINE配信」の完全アーキテクチャ

【高度な設計】SQLを用いた複数ジャーニーの横断制御

標準の頻度キャップ機能では「ジャーニーを跨いだ制限」が困難な場合があります。例えば、キャンペーンジャーニーAとリテンションジャーニーBの両方に合致した顧客が、同日に2通受け取ってしまう事態です。これを防ぐには、SQLを用いた共通配信ログの管理が必要です。

共有データエクステンション（DE）を用いた集計

まず、すべての配信アクティビティを記録する「送信履歴DE」を作成します。Automation Studioを使用して、毎日またはリアルタイムに近い頻度で以下のSQLを実行し、過去24時間以内に送信があった購読者を特定します。

SELECT SubscriberKey, COUNT(JobID) as SendCount
FROM _Sent
WHERE EventDate > DATEADD(day, -1, GETDATE())
GROUP BY SubscriberKey
HAVING COUNT(JobID) >= 1

Exclusion Script（除外スクリプト）によるリアルタイム判定

送信アクティビティの「除外スクリプト」欄にAMPscriptを記述することで、送信直前に上記の集計DEを参照し、既に本日配信済みの顧客をスキップさせることができます。

ROWCOUNT(LOOKUPROWS("Today_Sent_List", "SubscriberKey", _subscriberkey)) > 0

主要ツールの配信頻度制御機能スペック比較

SFMCと、他のエンゲージメントツールにおける頻度制限のスペックを比較します。SFMCはAIによる学習能力に強みがありますが、リアルタイム性の高い強制制限ではBraze等のツールが優位な面もあります。

関連記事：【図解】SFA・CRM・MA・Webの違いを解説。高額ツールに依存しない『データ連携の全体設計図』

トラブルシューティング：頻度制限が正しく動作しない時のチェックリスト

実装後に想定通りの挙動をしない場合、以下の項目を実務的に確認してください。

• データ保持ポリシー（Data Retention）の確認: 除外用のDEに保持期限が設定されており、データが消えていないか。
• タイムゾーンの不一致: SFMCのシステム時刻（通常CST）と、SQLで指定したGETDATE()の時間のズレにより、24時間の計算が狂っていないか。
• 連絡先キー（SubscriberKey）の重複: 同一人物が異なるキーで登録されている場合、頻度キャップは個別にカウントされてしまいます。
• Einsteinの学習期間: EEFを有効化してから十分なデータ（数千件以上の送信実績）が蓄積されるまで、AIの分類は有効になりません。

関連記事：高額なCDPは不要？BigQuery・dbt・リバースETLで構築する「モダンデータスタック」ツール選定と公式事例

まとめ：顧客体験を損なわないデータアーキテクチャの構築

「うざい配信」を卒業するためには、単一の機能を導入するだけでなく、全ジャーニー・全チャネルを横断して顧客が受けるメッセージ量を「可視化」し「制御」するデータアーキテクチャが不可欠です。Einsteinによる動的な最適化と、SQLによる静的な強制制限を組み合わせることで、エンゲージメントを最大化しつつ、購読解除リスクを最小限に抑えることが可能になります。

📚 関連資料

このトピックについて、より詳しく学びたい方は以下の無料資料をご参照ください：