よくある質問

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

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

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

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

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

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

多変量キャンペーンや複数のバリアントを持つキャンバスの実行は、始めるのに最適な方法です。例えば、多変量キャンペーンを実行して、異なるコピーや件名を持つ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時間オーディエンスに属していることが要件というわけではありません。

例

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

別の例として、同じ日に送信予定の2つのキャンペーン（朝と夕方）を作成し、最初のキャンペーンを受信済みのユーザーのみが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時間前にスケジュールすることを強く推奨します。このようなキャンペーンは丸一日かけて送信する必要があるため、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はUTC午後3:30に対応するため、キャンペーンは属性が記録された後に実行されます。ニューヨークが夏時間（UTC-4）に移行すると、東部時間午前10:30はUTC午後2:30に対応するため、春の時間進行のDSTの日にはキャンペーンが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呼び出しを特定しやすくなります。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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