よくある質問

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

_ユニーク受信者数_が予想よりも多くなるのは、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分に相当するため、春の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: normalCSSを持つテキストコンポーネントでは、連続する複数のスペースが表示時に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はハードバウンスしたユーザー、メールの購読解除をしたユーザー、スパムとしてマークされたユーザー、プロファイルにメールアドレスがないユーザー、または必要な購読グループに購読していないユーザーを除外します。これらのチェックは送信時に実行されるため、セグメントに含まれるユーザーでも実際の送信カウントから除外される場合があります。
• CSVインポートのタイミング：セグメントのメンバーシップがCSVインポートで管理されている場合、スケジュール済みキャンペーンの送信後に追加されたメールアドレスは、その送信ではリーチされません。Brazeは送信時のセグメントメンバーシップのスナップショットを保持しないため、現在のセグメントサイズが実際にメッセージを送信されたユーザー数を超える場合があります。
• グローバルフリークエンシーキャップ：ワークスペースレベルのキャップにより、対象のユーザーが同じウィンドウ内で別のメッセージを受信できなくなる場合があり、実際の送信数が減少します。
• 新しくインポートされたユーザー：条件を満たすようになったばかりのプロファイルは、次の評価または送信パスまで受信しない場合があるため、カウントは後の実行で追いつきます。
• プッシュの到達可能性：プッシュキャンペーンの場合、オーディエンスが正しいアプリに対してプッシュが有効であることを確認してください。プッシュ有効なユーザーでフィルタリングしない場合、推定オーディエンスにプッシュを受信できないプロファイルが含まれる可能性があります。より正確な運用上の推定値については、ターゲットユーザーステップのリーチ可能なユーザーを確認してください。
• レート制限：配信速度レート制限は、Brazeが1回の送信発生あたり1分間に送信するメッセージ数を制限します。Brazeはより長いウィンドウに配信を分散するため、一部の送信が遅延したり、カウントにまだ反映されていなかったり、対象オーディエンスに対して制限が低い場合は完了しない場合があります。
• 再適格ウィンドウ：まだ再適格でないユーザーはクールダウン中に再度受信しないため、その期間の推定オーディエンスサイズよりも送信数が少なくなります。
• レポーティングウィンドウ：分析の時間範囲にすべての送信が含まれていない場合があります。
• セグメントの再評価：送信時に再評価するアクションベースまたはスケジュール済みキャンペーンの場合、キャンペーンがキューに入れられた時点でセグメントに含まれていたユーザーが、メッセージが実際に送信される時点では条件を満たしていない場合があります。
• 送信キャップ：ターゲットオーディエンスの最大ユーザー数（または同様のキャップ）は、キャップに達すると配信を停止します。
• 厳格なデバイスまたはブラウザフィルター：最新のアプリバージョンやブラウザのみに一致するフィルターは、広範なセグメントプレビューと比較して、送信時のリーチ可能なセットを縮小します。

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

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

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

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

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

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

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

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

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

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

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

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

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