> ## Documentation Index > Fetch the complete documentation index at: https://moengage.com/docs/llms.txt > Use this file to discover all available pages before exploring further. # 定期キャンペーンおよびトリガー型キャンペーンのメッセージ制限 > MoEngage のメッセージ制限を使用して、ユーザーが Periodic キャンペーンまたは Event-Triggered キャンペーンを受信する回数を制御します。ローリングウィンドウを使用し、制限がリセットされるまで繰り返しの送信をブロックします。 ## 概要 Limit Messages per User を使用すると、個々のユーザーが特定の Periodic キャンペーンまたは Event-Triggered キャンペーンを受信する回数を、定義した期間内で制御できます。この設定を使用して過剰な露出を防ぎます。たとえば、ユーザーがクーポンオファー、プロモーションプッシュ、またはリマインダーメッセージを目にする回数を制御できます。 この設定は、キャンペーン作成フローの **Delivery Control** セクションで、新規キャンペーンと既存キャンペーンの両方に対して利用できます。デフォルトではオフになっているため、明示的に有効にしない限り、キャンペーンは現在とまったく同じように動作します。 Campaigns API を使用して Limit Message を設定する場合は、[Push](/docs/ja/api/create-campaigns/create-campaign-draft-v5#body-one-of-0-delivery-controls-limit-send-config) または [Email](/docs/ja/api/create-campaigns/create-campaign-draft-v5#body-one-of-1-delivery-controls-limit-send-config) の API リファレンスにある `limit_send_config` スキーマを参照してください。 ## ユースケース マーケターは、キャンペーン自体が継続的に実行されている場合や、ユーザーの行動によって繰り返しトリガーされる場合でも、クーポンコード、期間限定オファー、特典などのベネフィットがユーザーに一定の回数だけ届くようにする必要があることがよくあります。 例: * クーポンコードキャンペーンをユーザーに送信する回数を **30 日間に 2 回まで** に制限し、ユーザーが意図した以上の割引コードを受け取らないようにする。 * カート放棄リマインダーをユーザーごとに **週 1 回まで** 送信する。 * ウェルカムオファーをユーザーごとに生涯で **1 回のみ** 送信する。 この機能がない場合、マーケターはカスタム属性と追加のロジックを使用して送信頻度を追跡・制御する回避策を構築する必要がありました。Limit Messages per User は、追加の設定なしでこの制御をネイティブに提供します。 ## サポートされているキャンペーンとチャネル | チャネル | Periodic | Event-Triggered | | - | - | - | | Push | サポート対象 | サポート対象 | | SMS | サポート対象 | サポート対象 | | WhatsApp | サポート対象 | サポート対象 | | Email | サポート対象 | サポート対象 | | Cards | サポート対象 | サポート対象外 | | Connectors | サポート対象 | サポート対象 | ## 知っておくべきこと * この設定は、すべての新規キャンペーンでデフォルトでオフになっています。 * 制限と頻度の設定は、配信速度や送信パイプラインのその他の部分には影響しません。 * この機能は Frequency Capping とは独立して、かつ併用して動作します。一方を有効にしても、もう一方の動作は変わりません。 * 設定できる頻度ウィンドウの最大値は 1 年です。 * この機能は既存のキャンペーンでもサポートされています。 * この機能はトランザクションキャンペーン (トランザクションメールキャンペーンなど) には適用されません。 * この機能は Flows には適用されません。 ## 制限のカウント方法 ### 「メッセージ受信」としてカウントされるもの チャネルと配信タイプごとに、MoEngage が制限の消化をカウントする仕組みが異なります。以下は、チャネルに応じて配信成功を判断するために使用される特定のイベントです。 | チャネル | 送信のカウントに使用されるイベント | フォールバックイベント (プライマリイベントが利用できない場合) | | - | - | - | | Push | Notification Received (Android / iOS / Web) | Notification Sent – iOS (iOS の配信トラッキングが設定されていない場合にのみ使用) プラットフォーム | | SMS | SMS Delivered | 配信コールバックが設定されている場合は *SMS Delivered* が使用され、設定されていない場合は代わりに *SMS Sent* が使用されます | | Email | Email Delivered (Amazon SES および SendGrid の場合) | Email Sent (カスタムコネクタおよびその他のネイティブコネクタで使用) | | WhatsApp | WhatsApp Message Delivered | — | | Cards | Card Campaign Sent | — | | Connectors | Connector Sent | — | > **注:** このイベントベースのカウントロジックは、上記のチャネルにのみ適用されます。 **Push** と **Cards** の場合、制限はユーザーレベルではなく **プラットフォームレベル** で適用されます。つまり、カウントはユーザーごとに 1 つの合算値としてではなく、**Android**、**iOS**、**Web** の各プラットフォームごとに個別に追跡されます。 **例:** プッシュキャンペーンに **7 日間に 2 件のメッセージ** という制限を設定したとします。 * この場合、ユーザーは同じ 7 日間のウィンドウ内で、**Android** で最大 2 件、**iOS** で最大 2 件、**Web** で最大 2 件のメッセージを、それぞれ独立して受信できます。 * メッセージが Android と iOS のユーザーに送信された場合、それぞれのプラットフォームでカウントが 1 つ消費されます。 * 同じユーザーの Android と iOS に別のメッセージが送信された場合、それぞれでさらに 1 つカウントが消費されます。これで両方のプラットフォームが上限の 2 に達します。 * 3 件目のメッセージが Web のみをターゲットにしている場合、Android と iOS はこのウィンドウですでに上限に達していても、Web はまだ上限に達していないため、Web には配信されます。 つまり、あるプラットフォームで上限に達しても、同じユーザーの他のプラットフォームへの送信はブロックされません。 ### スライディングウィンドウの動作 制限は固定のカレンダー期間ではなく、**スライディングウィンドウ** で機能します。ユーザーへの送信がトリガーされるたびに、システムは現在の時点からさかのぼって、定義されたウィンドウ内でそのユーザーがキャンペーンを正常に受信した回数を確認します。 **例:** 制限が 7 日間に 2 件のメッセージに設定されているとします。 * 送信が行われる直前に毎回、システムは「過去 7 日間に、このユーザーはこのキャンペーンからすでに 2 件のメッセージを受信しているか?」を確認します。 * ユーザーの受信件数が 2 件未満の場合、メッセージは送信され、次の送信試行時にウィンドウが再評価されます。 * ユーザーが直近 7 日間にすでに 2 件受信している場合、以前の送信のいずれかが 7 日間のウィンドウの外に出るまで十分な時間が経過するまで、そのユーザーへのメッセージはブロックされます。 つまり、ウィンドウは固定スケジュール (毎週月曜日や毎月 1 日など) でリセットされるのではなく、時間の経過とともに継続的に前方へ「スライド」します。 * 定期キャンペーンの送信時刻の遅延は、翌日の配信に影響する可能性があります: ウィンドウは、キャンペーンのスケジュール時刻からではなく、ユーザーの前回の送信成功の正確な時刻から測定されます。そのため、ある日に遅延が発生すると、翌日にユーザーがスキップされる可能性があります。 **例:** 定期キャンペーンが毎日午前 8:00 に送信されるようにスケジュールされており、制限が **1 日に 1 件のメッセージ** に設定されているとします。 * 1 日目、送信が遅延して **午前 8:15** に送信されます。ユーザーは午前 8:15 に受信します。 * 2 日目、キャンペーンはスケジュールどおり午前 8:00 に実行され、このユーザーは **午前 8:01** に受信する予定です。 * ユーザーの前回の配信成功 (前日の午前 8:15) から 23 時間 46 分しか経過していないため、24 時間のウィンドウがまだ完了していません。送信はブロックされ、ユーザーはその日キャンペーンを受信しません。 この動作は、送信の遅延が発生しやすいキャンペーンで、1 日に 1 件のメッセージなどの厳しい制限を設定している場合に発生しやすくなります。 * カレンダー上の月は日数が異なるため、月次キャンペーンの配信に影響する可能性があります: 日数で定義された頻度 (例: 30 日) は、カレンダー上の月ではなく正確な日数として測定されます。カレンダー上の月の日数が設定された頻度より少ない場合、ユーザーは次回の配信対象にならない可能性があります。 **例:** キャンペーンが毎月 15 日に送信されるように設定されており、制限が **30 日間に 1 件のメッセージ** に設定されているとします。 * ユーザーは **2 月 15 日** にキャンペーンを受信します。 * 2 月 15 日から 3 月 15 日までは 30 日未満です (年によって 28 日または 29 日)。 * その結果、3 月 15 日の時点で 30 日間のウィンドウが完了しておらず、ユーザーはその回のキャンペーンを受信する対象になりません。 これを回避するには、月次キャンペーンでは同等の日数ではなく **Month(s)** の頻度単位を使用してください。 ## Limit Messages per User を設定する limit_message1.png 1. Periodic キャンペーンまたは Event-Triggered キャンペーンを作成または編集します。 2. チャネル固有の配信設定が表示される、キャンペーン作成フローの **Step 3** に移動します。 3. **Delivery controls** で、**Limit messages per user** トグルをオンにします。 4. 有効にすると、**Prevent a user from receiving the campaign more than a set number of times** が表示され、その後に設定行が表示されます: * **No more than \[ ] messages in \[ ] \[unit] per user** * 最初のフィールドは、ユーザーがこのキャンペーンから受信できるメッセージの最大数です (最大 **100**)。 * 2 番目のフィールドとドロップダウンで時間ウィンドウを定義します。数値と、**Day(s)**、**Week(s)**、**Month(s)**、または **Year** の単位を組み合わせます。どの単位を選択しても、ウィンドウは **1 年** を超えることはできません (たとえば、最大 365 日、最大 52 週、または最大 12 か月)。 たとえば、これを **no more than 9 messages in 1 Year per user** に設定すると、ユーザーは任意のローリング 1 年間にこのキャンペーンを最大 9 回受信できます。 5. キャンペーンを保存または公開します。 公開後、キャンペーンの **Info** ページの **Scheduling** タブにある **Delivery control** の **Limit message** で、設定された制限を確認できます。たとえば、**"1 time in 1 day"** のように表示されます。 limit_message_info1.png ## 既存の制限を編集する メッセージ数や頻度は、スケジュール済みのキャンペーンとアクティブなキャンペーンの両方で、いつでも更新できます。 * **スケジュール済みのキャンペーン**: キャンペーンはまだ送信を開始していないため、編集は直接適用されます。 * **アクティブなキャンペーン**: 制限、頻度、またはオン/オフのトグルを変更すると、キャンペーンの **新しいバージョン** が作成されます。更新された設定は、この新しいバージョン以降で有効になります。 * キャンペーンがアクティブな間に頻度の日数または月数を変更すると、次の送信対象になるまでの各ユーザーの既存のカウントダウンも、新しい頻度の値を反映するように更新されます。 ## 制限をオフにする Limit messages per user は、スケジュール済み、アクティブ、一時停止中のキャンペーンで、同じ Delivery Control セクションからいつでもオフにできます。他の編集と同様に、アクティブなキャンペーンでこれをオフにすると新しいキャンペーンバージョンが作成され、その時点以降は制限が適用されなくなります。 ## 適用されている制限を表示する 設定した制限と頻度は、他の Delivery Control 設定とともにキャンペーンの情報ページにも表示されるため、編集フローを開かずに有効な設定をすばやく確認できます。 ## 制限により除外されたユーザーを表示する 設定された **Limit messages per user** の上限にすでに達したためにユーザーが送信から除外されると、キャンペーンの **Error breakdown** に、**Failed to Send** などのカテゴリでエントリとして記録されます。 このエラーの内訳は、サポートされているすべてのチャネルのキャンペーン分析ページで確認できます。 limit_message_error.png キャンペーンのリーチユーザー数の減少や落ち込みに気付いた場合は、このエラーの内訳を確認してください。配信の問題ではなく、単にそれらのユーザーが定義したウィンドウ内で許可された最大回数のキャンペーンをすでに受信していたことを意味している場合があります。これらの除外されたユーザーはキャンペーンの **failed-to-send** の数にもカウントされるため、失敗数にもそれらが反映されることが想定されます。 ## よくある質問 はい。2 つの設定は独立して動作し、一方を使用してももう一方の動作には影響しません。 いいえ。固定のカレンダー期間ではなく、送信試行ごとに現在時刻を基準に再計算されるスライディングウィンドウを使用します。 制限のカウントに **Sent** と **Delivered** のどちらを使用するかはチャネルとコネクタのタイプによって決まるため、それらに依存します。**Delivered** が使用される場合、失敗した送信や除外された送信はカウントされません。Push と Cards の場合、制限はプラットフォーム間で共有されず、プラットフォームごとに個別に適用されます。 詳細については、上記の[制限のカウント方法](/docs/ja/user-guide/settings/channels/delivery-controls/limit-messages-for-periodic-and-triggered-campaigns#how-the-limit-is-counted)を参照してください。 はい。日数/月数を更新すると、各ユーザーの既存のカウントダウンが新しい頻度を反映するように調整されます。