よくある質問

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

マルチチャネルキャンペーンを作成するにはどうすればよいですか？

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

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

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

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

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

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

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

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

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

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

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

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

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

_ユニーク受信者_が予想よりも多くなることがあります。これは、Brazeがレポート用に日次のユニーク受信者を追跡しているためです。これにより、Brazeはユーザーがメッセージを受信するたびにコンバージョンウィンドウ内のコンバージョンを帰属させることができ、複数の受信を1つの生涯カウントにまとめる（コンバージョン計算が歪む）代わりに正確な計測が可能になります。

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

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

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

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

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

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

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

ローカルタイムゾーン配信では、ユーザーの個別のタイムゾーンに基づいてセグメントにメッセージングキャンペーンを配信できます。ローカルタイムゾーン配信を使用しない場合、キャンペーンは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時間オーディエンスに所属している必要があるという要件ではありません。

例

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

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

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

タイムラインの説明

1. ユーザーAがPST午前6:59（サモア時間午前4:59）にセグメントに入ります。
2. Brazeはサモア時間午前7時にセグメントメンバーシップをチェックし、次の24時間以内にキャンペーンを受信する適格性のあるユーザーを判定します。この時点でユーザーAはセグメントに含まれています。
3. セグメントには24時間のウィンドウがあるため、ユーザーAは参加から24時間後のPST午前6:59（サモア時間午前4:59）にセグメントから退出します。
4. ローカルタイムキャンペーンはPST午前7時に送信されますが、ユーザー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日にキャンペーンが適格性を評価する時点で、それらのユーザーがまだ条件を満たしていない可能性があります。

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

これを回避するには、カスタム属性またはイベントの更新がキャンペーンのスケジュールされた送信時間の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呼び出しを特定しやすくなります。

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

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

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

不整合を避けるために、キャンペーンを起動する前に最大受信者制限を設定し、送信が進行中の間は変更しないようにしてください。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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