よくある質問

この記事では、キャンペーンに関するよくある質問への回答を提供します。

マルチチャネルキャンペーンの作成方法

設定手順とサポートされているチャネルについては、キャンペーンを作成のマルチチャネルキャンペーンを参照してください。

マルチチャネルキャンペーンにコントロールグループを追加できますか？

キャンペーンを作成のコントロールグループを参照してください。クロスチャネルのテストには、キャンバスを使用してください。

キャンペーンのテストと最適化を始めるにはどのような方法がありますか？

多変量キャンペーンの実行や、複数のバリアントを持つキャンバスの実行は、始めるのに最適な方法です。例えば、多変量キャンペーンを実行して、異なるコピーや件名を持つ1つのメッセージをテストできます。複数のバリアントを持つキャンバスは、ワークフロー全体のテストに役立ちます。

キャンペーンの開封率が低下したのはなぜですか？

開封率の低下は、必ずしも技術的な問題と相関しているわけではありません。メールのクリッピングによってトラッキングピクセルが欠落する問題が発生している場合があります。ただし、コンテンツの問題やオーディエンスサイズの変更により、メールを開封するユーザーが減少している可能性もあります。

キャンペーンのオーディエンスはどのように評価されますか？

デフォルトでは、キャンペーンはエントリ時にオーディエンスフィルターを確認します。遅延のあるアクションベースのキャンペーンでは、送信時にセグメント条件を再評価するオプションがあり、メッセージ送信時にユーザーがまだターゲットオーディエンスに含まれていることを確認できます。

特定のキャンペーンまたはキャンバスのユニーク受信者数と送信数に差異があるのはなぜですか？

考えられる説明の1つとして、キャンペーンまたはキャンバスで再適格性がオンになっていることが挙げられます。つまり、セグメントと配信設定に適格なユーザーは、メッセージを複数回受信できます。再適格性がオンになっていない場合、送信数とユニーク受信者数の差異は、ユーザーがプロファイルに関連付けられた複数のデバイスをプラットフォーム間で持っていることが原因と考えられます。

例えば、iOSとWebプッシュ通知の両方を含むキャンバスがある場合、モバイルとデスクトップの両方のデバイスを持つユーザーは、複数のメッセージを受信する可能性があります。

ユニーク受信者がターゲットしたユーザー数よりも多いのはなぜですか？

ユニーク受信者は、Brazeがレポート用に日次のユニーク受信者を追跡しているため、想定したオーディエンスよりも多くなることがあります。これにより、Brazeはユーザーがメッセージを受信するたびにコンバージョンウィンドウ内のコンバージョンを紐付けることができ、複数の受信を1つのライフタイムカウントに集約する（コンバージョンの計算が歪む）代わりに正確な計測を行えます。

例えば、ユーザーが月曜日にキャンペーンを受信し、金曜日に再度受信して、それぞれの送信後にコンバージョンした場合、Brazeはこれを2回の受信と2回のコンバージョンとしてレポートできます。もしBrazeが両方の送信にわたって1つのライフタイム「ユニーク」しかカウントしなかった場合、有効なコンバージョンが欠落するか、1人の受信者に対して二重カウントされることになり、キャンペーンのパフォーマンスが読みづらくなります。

同じパターンは繰り返しキャンペーンと再適格性にも適用されます。2人のユーザーがそれぞれ今日と明日に繰り返し送信を受信した場合、ユニーク受信者は4つの日次受信者行をカウントし、2つのプロファイルではありません。

マルチチャネルキャンペーンでコンバージョン数がユニークユーザー数を超えることがあるのはなぜですか？

キャンペーンを作成のコンバージョンとレポート、およびコンバージョンイベントのコンバージョントラッキングルールを参照してください。

キャンペーンのリーチ可能なユーザーベースが、キャンペーンに使用しているセグメントよりも少ないのはなぜですか？

グローバルコントロールグループを設定している場合、リーチ可能なオーディエンスの一定割合がキャンペーンの受信対象から除外されます。つまり、キャンペーンが同じセグメントを使用していても、セグメントのリーチ可能なユーザー数がキャンペーンのリーチ可能なユーザー数よりも多くなることがあります。

ローカルタイムゾーン配信とは何ですか？

ローカルタイムゾーン配信を使用すると、ユーザー個別のタイムゾーンに基づいてメッセージングキャンペーンをセグメントに配信できます。ローカルタイムゾーン配信を使用しない場合、キャンペーンはBrazeでの会社のタイムゾーン設定に基づいてスケジュールされます。

例えば、ロンドンを拠点とする企業が午後12時にキャンペーンを送信すると、アメリカ西海岸のユーザーには午前4時に届きます。アプリが特定の国でのみ利用可能な場合、これは問題にならないかもしれません。そうでない場合は、ユーザーに早朝のプッシュ通知を送信することを避けることを強くお勧めします。

Brazeはどのようにユーザーのタイムゾーンを認識しますか？

Brazeはデバイスからユーザーのタイムゾーンを自動的に判定します。これにより、タイムゾーンの正確性とユーザーの完全なカバレッジが保証されます。User APIまたはその他の方法でタイムゾーンなしで作成されたユーザーは、SDKによってアプリで認識されるまで、会社のタイムゾーンがデフォルトのタイムゾーンとして設定されます。

会社のタイムゾーンは、ダッシュボードの会社設定で確認できます。

Brazeはローカルタイムゾーン配信のユーザーをいつ評価しますか？

Brazeは、以下のタイミングでユーザーのエントリ適格性を評価します。

• スケジュールされた日のサモア時間（UTC+13）
• スケジュールされた日のローカルタイム

ユーザーがエントリの資格を得るには、両方のチェックに適格である必要があります。例えば、キャンバスが2021年8月7日午後2時のローカルタイムゾーンで起動するようにスケジュールされている場合、ニューヨークにいるユーザーをターゲットにするには以下のチェックが必要です。

• 2021年8月6日午後9時（ニューヨーク時間）
• 2021年8月7日午後2時（ニューヨーク時間）

エントリするには、ユーザーは両方の評価タイミングでオーディエンスとフィルターに一致する必要があります。最初のチェックでユーザーが適格でない場合、Brazeは2回目のチェックを実行しません。起動前にセグメントに所属していなければならない最低期間はありません。各チェック時点での適格性のみが重要です。

この評価動作は、ダッシュボードでキャンペーンをどれくらい前にスケジュールするかとは別のものです。少なくとも24時間前にスケジュールすることは、メッセージが24時間のローカルタイムゾーンウィンドウ全体にわたって配信されるのを助ける推奨事項であり、各ユーザーが24時間オーディエンスに属していなければならないという要件ではありません。

例

例えば、キャンペーンが午後7時UTCに配信されるようにスケジュールされている場合、タイムゾーンが特定されるとすぐにキャンペーン送信のキューイングを開始します（サモアなど）。これはメッセージの送信準備であり、キャンペーンの送信ではありません。適格性チェック時にユーザーがフィルターに一致しない場合、ターゲットオーディエンスには含まれません。

別の例として、同じ日に送信されるようにスケジュールされた2つのキャンペーン（1つは朝、もう1つは夕方）を作成し、ユーザーが最初のキャンペーンをすでに受信している場合にのみ2番目のキャンペーンを受信できるフィルターを追加したいとします。ローカルタイムゾーン配信では、一部のユーザーが2番目のキャンペーンを受信しない場合があります。これは、ユーザーのタイムゾーンが特定されたときに適格性がチェックされ、スケジュールされた時間がそのユーザーのタイムゾーンでまだ到来していない場合、最初のキャンペーンを受信していないため、2番目のキャンペーンの対象にならないためです。

以下のタイムラインは、時間制限のあるメンバーシップウィンドウを含むセグメント定義を想定しています。この例では、ユーザーは参加してから24時間後にセグメントを離脱します。このフィルター動作が、ユーザーが最初のチェックに合格しても2回目で不合格になる理由の1つです。

タイムラインの説明

1. ユーザーAが午後6:59 PST（サモア時間午後4:59）にセグメントに参加します。
2. Brazeは午後7時（サモア時間）にセグメントメンバーシップをチェックし、次の24時間以内にキャンペーンを受信する資格のあるユーザーを特定します。この時点でユーザーAはセグメントに含まれています。
3. セグメントには24時間のウィンドウがあるため、ユーザーAは参加してから24時間後の午後6:59 PST（サモア時間午後4:59）にセグメントを離脱します。
4. ローカルタイムキャンペーンは午後7時PSTに送信されますが、ユーザーAはすでにセグメントを離脱しています。

ローカルタイムゾーンキャンペーンのスケジュール方法

前のセクションでは、Brazeがローカルタイムゾーン配信の適格性を評価するタイミング（2回のチェック）について説明しました。このセクションでは、ダッシュボードでキャンペーンスケジュールを設定するタイミング（スケジュールのリードタイム）と、24時間未満の通知でスケジュールした場合にどのユーザーがメッセージを受信するかについて説明します。

キャンペーンをスケジュールする際に、指定した時間に送信するよう選択し、ユーザーのローカルタイムゾーンでキャンペーンを送信を選択します。

Brazeは、すべてのローカルタイムゾーンキャンペーンを24時間前にスケジュールすることを強くお勧めします。このようなキャンペーンは丸1日かけて送信する必要があるため、24時間前にスケジュールすることで、メッセージがセグメント全体に届くことを保証できます。ただし、必要に応じて24時間未満前にこれらのキャンペーンをスケジュールすることも可能です。Brazeは送信時間を1時間以上過ぎたユーザーにはメッセージを送信しないことにご注意ください。

例えば、現在午後1時で、ローカルタイムゾーンキャンペーンを午後3時にスケジュールした場合、キャンペーンはローカルタイムが午後3時から午後4時の間のすべてのユーザーに即座に送信されますが、ローカルタイムが午後5時のユーザーには送信されません。また、キャンペーンに選択した送信時間は、会社のタイムゾーンでまだ到来していない必要があります。

24時間未満前にスケジュールされたローカルタイムゾーンキャンペーンを編集しても、メッセージのスケジュールは変更されません。ローカルタイムゾーンキャンペーンを後の時間（例：午後6時ではなく午後7時）に送信するように編集した場合、元の送信時間が選択された時点でターゲットセグメントに含まれていたユーザーは、元の時間（午後6時）にメッセージを受信します。ローカルタイムゾーンを早い時間（例：午後5時ではなく午後4時）に送信するように編集した場合、キャンペーンは引き続き元の時間（午後5時）にすべてのセグメントメンバーに送信されます。

ユーザーがキャンペーンの再適格性を許可されている場合、元の時間（午後5時）に再度受信します。ただし、キャンペーンの以降のすべての送信では、更新された時間にのみメッセージが送信されます。

ローカルタイムゾーンキャンペーンの変更はいつ反映されますか？

ローカルタイムゾーンキャンペーンのターゲットセグメントには、セグメント全体への配信を保証するために、時間ベースのフィルターに少なくとも48時間のウィンドウを含める必要があります。例えば、以下のフィルターで2日目のユーザーをターゲットにするセグメントを考えてみましょう。

• アプリの初回使用が1日以上前
• アプリの初回使用が2日未満前

ローカルタイムゾーン配信では、配信時間とユーザーのローカルタイムゾーンによっては、このセグメントのユーザーを逃す可能性があります。これは、ユーザーのタイムゾーンが配信をトリガーする時点で、すでにセグメントを離脱している場合があるためです。

スケジュールされたキャンペーンの起動前にどのような変更ができますか？

キャンペーンがスケジュールされている場合、メッセージの送信キューに入る前に、メッセージの作成以外のすべての編集を行う必要があります。すべてのキャンペーンと同様に、起動後にコンバージョンイベントを編集することはできません。

スケジュールされたキャンペーンを更新したのに、起動しなかったのはなぜですか？

これは、キャンペーンが更新されたのとまったく同じ時間に起動するようにスケジュールされている場合に発生することがあります。例えば、現在午後3:10で、キャンペーンを午後3:10に起動するように変更してキャンペーンを更新を選択した場合、すでに午後3:10を過ぎているため、起動予定時間が過ぎたことになります。同じ時間にキャンペーンをスケジュールする代わりに、キャンペーン開始後すぐに送信を選択してください。

スケジュールされたキャンペーンのメッセージがキューに入る前の「セーフゾーン」とは何ですか？

以下の時間内に変更を行うことをお勧めします。

• 1回限りのスケジュールされたキャンペーン：スケジュールされた送信時間まで編集可能です。
• 繰り返しスケジュールされたキャンペーン：スケジュールされた送信時間まで編集可能です。
• ローカル送信時間キャンペーン：スケジュールされた送信時間の24時間前まで編集可能です。
• 最適送信時間キャンペーン：キャンペーンの送信予定日の24時間前まで編集可能です。

これらの推奨事項以外のタイミングで変更を行った場合、送信されるメッセージに更新が反映されない場合があります。例えば、午後12時のローカルタイムにキャンペーンの送信がスケジュールされている3時間前に送信時間を編集した場合、以下が発生する可能性があります。

• Brazeは送信時間を1時間以上過ぎたユーザーにはメッセージを送信しません。
• 事前にキューに入れられたメッセージは、調整された時間ではなく、元のキュー入れ時間に送信される場合があります。

変更が必要な場合は、現在のキャンペーンを停止することをお勧めします（これによりキューに入れられたメッセージがキャンセルされます）。その後、キャンペーンを複製し、必要な変更を加えて、新しいキャンペーンを起動できます。最初のキャンペーンをすでに受信したユーザーをこのキャンペーンから除外する必要がある場合があります。タイムゾーン送信に対応するため、キャンペーンのスケジュール時間を再調整してください。

日次スケジュールキャンペーンに夏時間の日にユーザーがエントリしなかったのはなぜですか？

夏時間（DST）の切り替え日には、時計が進むか戻るかによって、日次スケジュールキャンペーンが通常より最大1時間早くまたは遅く実行される場合があります。セグメントがスケジュールされた送信時間の1時間以内のタイムスタンプを持つカスタム属性やイベントに依存している場合、DSTの日にキャンペーンが適格性を評価するときに、それらのユーザーがまだ適格でない可能性があります。

例えば、ユーザーが通常午後3時UTCにカスタム属性の更新を受け取り、キャンペーンがニューヨーク（東部時間）で毎日午前10:30に実行されるとします。ニューヨークが標準時間（UTC-5）の間、午前10:30 ETはUTC午後3:30に対応するため、キャンペーンは属性がログに記録された後に実行されます。ニューヨークが夏時間（UTC-4）に移行すると、午前10:30 ETはUTC午後2:30に対応するため、春の時間進行のDSTの日にはキャンペーンが午後3時UTCの属性更新の前に実行される可能性があります。適格条件となる属性がまだ存在しないため、それらのユーザーはフィルタリングされます。再適格性がオフの場合、前日にエントリしたユーザーは再エントリできず、その日のエントリがゼロになります。

これを回避するには、カスタム属性やイベントの更新がキャンペーンのスケジュールされた送信時間の1時間以上前に行われるようにしてください。

キャンペーンにエントリするユーザー数が想定数と一致しないのはなぜですか？

キャンペーンにエントリするユーザー数は、オーディエンスとトリガーの評価方法により、想定数と異なる場合があります。Brazeでは、オーディエンスはトリガーの前に評価されます（属性の変更トリガーを使用する場合を除く）。これにより、トリガーアクションが評価される前に、ユーザーが選択したオーディエンスに最初から含まれていない場合、キャンペーンから脱落する原因になります。

キャンペーンを編集した後、ユーザーがキャンペーンを2回受信したのはなぜですか？

ライブキャンペーンを停止せずに編集すると、ユーザーがメッセージを2回受信する可能性があります。これは、ライブキャンペーンを編集すると、元のキューがまだ処理中の間に、更新されたバージョンに対してユーザーが再キューイングされるために発生します。元のメッセージをまだ受信していないユーザーが、両方のキューに入る可能性があります。これを防ぐには、変更を加える前に必ずキャンペーンを停止してください。

キャンペーン分析ページのCSVエクスポートユーザーデータとCSVエクスポートメールアドレスオプションの違いは何ですか？

CSVエクスポートメールアドレスオプションを選択すると、メールアドレスを持つユーザーのデータのみがダウンロードされます。例えば、100,000人のユーザーのセグメントがあり、そのうち50,000人のみがメールアドレスを持っている場合、CSVエクスポートメールアドレスをクリックすると、エクスポートには50,000行のデータのみが含まれます。一方、CSVエクスポートユーザーデータを選択すると、すべてのユーザーデータがエクスポートされます。

キャンペーンをAPI識別子で検索できますか？

はい、キャンペーンページでフィルターapi_id:YOUR_API_IDを使用して、API識別子でキャンペーンを検索できます。詳細については、キャンペーンの検索を参照してください。

入力フィールドと表示テキストで空白の表示が異なるのはなぜですか？

入力フィールドと表示テキストコンポーネントでの空白の処理が異なるのは、CSSスタイリングのためです。デフォルトのwhite-space: normal CSSを持つテキストコンポーネントでは、連続した複数のスペースは表示時に1つのスペースに折りたたまれます。これはレンダリングされたテキストの標準的なHTML動作です。

入力フィールドでは、正確なデータ入力のために入力したとおりの間隔を確認して編集する必要があるため、複数のスペースがそのまま保持されます。これは、複数のスペースを含むテキストが、入力フィールド（すべてのスペースが保持される）で表示される場合と、ダッシュボードの他の部分（CSSが複数のスペースを折りたたむ場合がある）で表示される場合とで、異なって見える可能性があることを意味します。

例えば、入力フィールドにキャンペーン名やUTMパラメーターを複数のスペースを含めて入力すると、すべてのスペースが保持されて表示されます。ただし、同じテキストが検索結果、キャンペーンリスト、またはその他のテキストコンポーネントに表示される場合、CSSの空白処理により複数のスペースが1つのスペースとして表示される場合があります。

APIキャンペーンとAPIトリガーキャンペーンの違いは何ですか？

APIトリガーキャンペーンでは、キャンペーンのコピー、多変量テスト、再適格性ルールをBrazeダッシュボード内で管理しながら、コンテンツの配信を自社のサーバーやシステムからトリガーできます。これらのメッセージには、リアルタイムでメッセージにテンプレート化される追加データも含めることができます。

APIキャンペーンは、APIを使用して送信されたメッセージを追跡するために使用されます。ほとんどのキャンペーンとは異なり、メッセージ、受信者、スケジュールを指定するのではなく、API呼び出しに識別子を渡します。

APIトリガーキャンペーンをユーザーが受信したことを確認するにはどうすればよいですか？

キャンペーンを受信フィルターを使用してセグメントを作成し、確認したい特定のAPIトリガーキャンペーンを選択します。セグメントを保存した後、/users/export/segmentエンドポイントを使用してそのセグメントのユーザーをエクスポートします。

キャンペーンを削除できますか？

いいえ。ただし、キャンペーンをアーカイブすることは可能です。

アクションベースキャンペーンとAPIトリガーキャンペーンの違いは何ですか？

アクションベース

アクションベース配信キャンペーン（イベントトリガーキャンペーン）は、トランザクションメッセージや達成ベースのメッセージに非常に効果的で、ユーザーが特定のイベントを完了した後にメッセージの送信をトリガーできます。

メリット	デメリット
• メッセージアクティビティログを通じて、プラットフォームに入ってくるJSONペイロードの可視性（テストユーザーによるイベントトリガーの場合） • パーソナライゼーション要素がカスタムイベントプロパティに含まれる • カスタムイベントを使用して、メッセージ対象となるユーザーのセグメントを作成可能	• データポイントを消費する

APIトリガー

APIトリガーおよびサーバートリガーキャンペーンは、より高度なトランザクション処理に最適で、自社のサーバーやシステムからキャンペーンコンテンツの配信をトリガーできます。メッセージをトリガーするAPIリクエストには、リアルタイムでメッセージにテンプレート化される追加データも含めることができます。

メリット	考慮事項
• データポイントを記録しない • パーソナライゼーション要素がJSONペイロードプロパティに含まれる	• JSONペイロードプロパティで、メッセージ対象となるユーザーのセグメントを作成できない • メッセージアクティビティログで入ってくるJSONペイロードを確認できない

「リクエストタイムアウト」エラーのサポートチケットを送信する際に何を含めるべきですか？

キャンペーンまたはキャンバスの作成・編集中に「リクエストタイムアウト」エラーが発生し、Brazeサポートに連絡する必要がある場合は、解決を迅速化するために以下の情報を含めてください。

• 画面録画: エラーが発生する前に行ったステップの録画（ページ遷移を含む）。
• タイムスタンプとタイムゾーン: エラーが発生した正確な時刻とタイムゾーン。
• ブラウザとバージョン: 使用しているブラウザ（例: Chrome 120、Safari 17）、および別のブラウザでエラーを再現できるか試したかどうか。
• 再現手順: エラーをトリガーするアクションの明確な説明（関連する特定のキャンペーンやキャンバスの設定を含む）。
• ネットワークログ（任意）: ブラウザの開発者ツール（Network タブ）を開き、エラーを再現して、ネットワークログをHTTPアーカイブ（HAR）ログファイルとしてエクスポートします。これにより、サポートチームがタイムアウトしているAPI呼び出しを特定しやすくなります。

送信分析が設定した最大受信者数制限と一致しないのはなぜですか？

アクティブなキャンペーンに最大受信者数制限を追加または変更した場合、以下の理由で送信分析に制限が反映されない場合があります。

• 起動後の制限追加：キャンペーンの起動時に最大受信者数制限が設定されていない場合、制限を適用する前にすでにキューに入れられたメッセージは引き続き送信されます。制限は、変更を保存した後にキューに入れた送信に対してのみ有効になります。
• レート制限との相互作用：キャンペーンにレート制限も設定されている場合、メッセージがより長い時間ウィンドウにわたって配信される場合があります。最大受信者数制限はメッセージがキューに入れられるときに評価され、配信されるときではありません。メッセージがすでにキューに入っている間に制限が変更された場合、元の制限がそれらのメッセージに適用されます。
• 繰り返しキャンペーン：繰り返しキャンペーンの場合、スケジュールされた各送信が最大受信者数制限を独立して評価します。送信間で制限を変更しても、以前の送信カウントが遡及的に調整されることはありません。

不一致を避けるには、キャンペーンを起動する前に最大受信者数制限を設定し、送信の進行中は変更を避けてください。

送信数が推定オーディエンスサイズよりも少ないのはなぜですか？

送信数が推定オーディエンスサイズよりも少なくなる要因はいくつかあります。

• セグメントサイズの推定値：セグメントカウントは、Brazeが送信時にメンバーシップを評価するまでは近似値です。推定値の計算方法と正確なカウントの実行タイミングについては、セグメントサイズの測定を参照してください。
• アクションベース配信：ユーザーはトリガーを実行した後にのみ送信が生成されるため、送信は時間の経過とともに蓄積され、キャンペーンの最初の構築時に表示される初期推定値に遅れることがあります。
• 起動後のオーディエンス編集：起動後にエントリまたはターゲットフィルターを変更すると、推定オーディエンスのスナップショットが、後の送信で実際に適格な人と同期しなくなる可能性があります（例：ユーザーが再エントリの資格がない場合）。
• オーディエンスパスステップ：キャンバスの場合、オーディエンスパスステップは、ユーザーが適格な最も優先度の高いブランチに一致するユーザーにのみメッセージを送信するため、フラットなセグメントカウントと比較して送信数が減少する場合があります。
• コントロールグループ：グローバルコントロールグループまたはキャンペーンレベルのコントロールグループが使用されている場合、オーディエンスの一部が配信から除外されます。
• 配信タイミングとウィンドウ：ローカルタイムゾーンまたはスケジュールされたキャンペーンの場合、ユーザーはエントリ時と送信時の両方で適格である必要があります。特定のタイムゾーンのユーザーが配信ウィンドウの外に出る場合があります。
• メールの重複排除：キャンペーンまたはキャンバスが、一致するメールアドレスを持つ複数のユーザーをターゲットにしているため、送信時にそのメールアドレスを持つランダムなユーザーが選択されます。メッセージは1回のみ送信され、同じメールアドレスに複数回送信されないように重複排除されますが、推定オーディエンスサイズにはすべてのユーザーが含まれます。
• メール配信到達性フィルター：メールキャンペーンの場合、Brazeはハードバウンスした、メールの購読を解除した、スパムとしてマークされた、プロファイルにメールアドレスがない、または必要な購読グループに登録されていないユーザーを除外します。これらのチェックは送信時に実行されるため、セグメントに含まれるユーザーが実際の送信カウントから除外されることがあります。
• CSVインポートのタイミング：セグメントメンバーシップがCSVインポートで維持されている場合、スケジュールされたキャンペーンの送信後に追加されたメールアドレスはその送信では届きません。Brazeは送信時のセグメントメンバーシップのスナップショットを保持しないため、現在のセグメントサイズが実際にメッセージが送信されたユーザー数を超える場合があります。
• グローバルフリークエンシーキャップ：ワークスペースレベルのキャップにより、適格なユーザーが同じウィンドウ内で別のメッセージを受信できなくなり、実際の送信数が減少することがあります。
• 新しくインポートされたユーザー：適格になったばかりのプロファイルは、次の評価または送信パスまで受信しない場合があるため、カウントは後の実行で追いつきます。
• プッシュのリーチ可能性：プッシュキャンペーンの場合、オーディエンスが正しいアプリのプッシュが有効であることを確認してください。プッシュ有効ユーザーでフィルタリングしていない場合、推定オーディエンスにプッシュを受信できないプロファイルが含まれる場合があります。より運用に近い推定値については、ターゲットユーザーステップのリーチ可能なユーザーを確認してください。
• レート制限：配信速度レート制限は、1回の送信発生中にBrazeが1分あたりに送信するメッセージ数を制限します。Brazeは配信をより長いウィンドウに分散させるため、一部の送信が延期されたり、カウントにまだ反映されていなかったり、適格なオーディエンスに対して制限が低い場合は完了しないことがあります。
• 再適格性ウィンドウ：まだ再適格でないユーザーはクールダウン期間中に再度受信しないため、その期間の推定オーディエンスサイズに対して送信数が少なくなります。
• レポートウィンドウ：分析の時間範囲がすべての送信を含んでいない場合があります。
• セグメントの再評価：送信時に再評価するアクションベースまたはスケジュールされたキャンペーンの場合、キャンペーンがキューに入れられた時点でセグメントに含まれていたユーザーが、メッセージが実際に送信されるときには適格でなくなっている場合があります。
• 送信キャップ：ターゲットオーディエンスのユーザーの最大数（または類似のキャップ）により、キャップに達すると配信が停止します。
• 厳格なデバイスまたはブラウザのフィルター：最新のアプリバージョンやブラウザのみに一致するフィルターは、広範なセグメントプレビューと比較して、送信時のリーチ可能なセットを縮小します。

送信時に特定のユーザーがスキップされた理由を確認するには、メッセージアクティビティログを確認してください。

グローバルフリークエンシーキャップに関するよくある質問はどこにありますか？

カレンダー日、サイレントプッシュ、Webhook、キャンバスの動作、および関連トピックに関する質問については、レート制限とフリークエンシーキャップのよくある質問を参照してください。

キャンペーンの送信率が低下しているのはなぜですか？

日次スケジュールキャンペーンの送信ユーザー数が時間の経過とともに減少している場合、以下を確認してください。

• 再適格性がオンになっているか確認する：再適格性がない場合、Brazeは各ユーザーに1回のみメッセージを送信します。日次スケジュールキャンペーンでは、オーディエンスに一致し、まだメッセージを受信していないユーザーのみが各送信の対象になります。メッセージを受信するユーザーが増えるにつれて、後の各送信の対象ユーザーが少なくなり、送信量が減少します。
• オーディエンスが固定メンバーシップかどうか確認する：固定ユーザーリスト（セグメントフィルターとして使用されるCSVインポートなど）から構築されたオーディエンスは、自動的に新しいメンバーを獲得しません。新規エントリがなければ、ユーザーにメッセージが送信されるにつれて送信量は回復できません。

配信速度レート制限および1回の送信で送信数を減少させるその他の要因については、送信数が推定オーディエンスサイズよりも少ないのはなぜですか？を参照してください。

メールとSMSでユニーク受信者が送信数を超えることがあるのはなぜですか？

メールとSMSの場合、Brazeはユニーク受信者をESPの送信試行前にインクリメントし、送信数をESPからの成功レスポンスの後にインクリメントします。恒久的なエラー（無効なメールアドレスなど）や重複アドレスにより、ユニーク受信者が送信数を超える場合があります。

最終送信日時がスケジュールされた送信時間と一致しないのはなぜですか？

1回のスケジュール送信のキャンペーンの場合、最終送信日時は起動時間と一致します。ローカルタイムゾーンで送信が有効な繰り返しキャンペーンの場合、より早いタイムゾーンのユーザー（例：PSTに対するGMT）への送信がワークスペースのスケジュール時間よりも先に完了するため、最終送信日時がスケジュールされた時間よりも早く表示されることがあります。

停止した過去のキャンペーンの指標が分析ページに表示されなくなったのはなぜですか？

分析タブはデフォルトで過去90日間を表示します。キャンペーンの最終送信がそのウィンドウ外の場合、分析ページの日付範囲をキャンペーンが送信された時期を含むように調整するまで、指標がゼロとして表示される場合があります。詳細については、キャンペーン分析を参照してください。

インタラクションデータの復元は、キャンペーン分析を復元するものではありません。リターゲティングフィルターとユーザーインタラクション履歴にのみ適用されます。詳細については、メッセージングインタラクションデータを参照してください。