よくある質問
この記事では、Campaignに関するよくある質問への回答を提供します。
マルチチャネルキャンペーンを作成するにはどうすればよいですか？
マルチチャネルキャンペーンを作成するには、Messaging > Campaignsを選択します。次に、Create Campaign > Multichannelを選択します。ここから、Content Cards、メール、LINE、プッシュ通知、SMS/MMS/RCS、Webhook、WhatsAppのメッセージングチャネルを選択できます。
マルチチャネルキャンペーンにコントロールグループを追加できますか？
いいえ、Campaignのコントロールグループは、メールAとメールBの比較など、単一チャネルのメッセージングを対象としています。代わりに、異なるチャネル、メッセージングコンテンツ、配信タイミングのテストにはCanvasの使用をお試しください。
キャンペーンのテストと最適化を始めるにはどのような方法がありますか？
多変量キャンペーンや複数のバリアントを持つCanvasの実行は、始めるのに最適な方法です。例えば、多変量キャンペーンを実行して、異なるコピーや件名を持つ1つのメッセージをテストできます。複数のバリアントを持つCanvasは、ワークフロー全体のテストに役立ちます。
キャンペーンの開封率が低下したのはなぜですか？
開封率の低下は、必ずしも技術的な問題と相関しているわけではありません。メールのクリッピングにより、トラッキングピクセルが欠落する問題が発生している可能性があります。ただし、コンテンツやオーディエンスサイズの変更により、メールを開封するユーザーが減少している可能性もあります。
キャンペーンのオーディエンスはどのように評価されますか？
デフォルトでは、Campaignはエントリ時にオーディエンスフィルターをチェックします。遅延のあるアクションベースのCampaignでは、送信時にSegment条件を再評価するオプションがあり、メッセージが送信される際にユーザーがまだターゲットオーディエンスに含まれていることを確認できます。
特定のCampaignまたはCanvasで、ユニーク受信者数と送信数に差があるのはなぜですか？
考えられる説明の1つは、CampaignまたはCanvasで再エントリが有効になっていることです。これは、Segmentと配信設定の条件を満たすユーザーがメッセージを複数回受信できることを意味します。再エントリが有効になっていない場合、送信数とユニーク受信者数の差は、ユーザーがプラットフォームをまたいで複数のデバイスをプロファイルに関連付けていることが原因と考えられます。
例えば、iOSとWebプッシュ通知の両方を含むCanvasがある場合、モバイルデバイスとデスクトップデバイスの両方を持つユーザーは、複数のメッセージを受信する可能性があります。
ユニーク受信者数がターゲットにしたユーザー数よりも多いのはなぜですか？
ユニーク受信者数が予想よりも多くなることがあります。これは、Brazeがレポートのために日次のユニーク受信者を追跡しているためです。これにより、Brazeはユーザーがメッセージを受信するたびにコンバージョン期間内のコンバージョンを帰属させることができ、複数の受信を1つの生涯カウントに集約する（コンバージョンの計算が歪む）のではなく、正確に計測できます。
例えば、ユーザーが月曜日にCampaignを受信し、金曜日に再度受信して、それぞれの送信後にコンバージョンした場合、Brazeはこれを2回の受信と2回のコンバージョンとしてレポートできます。Brazeが両方の送信にわたって1つの生涯「ユニーク」のみをカウントした場合、有効なコンバージョンを失うか、1人の受信者に対して二重カウントすることになり、Campaignのパフォーマンスが読みにくくなります。
同じパターンは、定期的なCampaignや再エントリにも適用されます。2人のユーザーがそれぞれ今日と明日に定期送信を受信した場合、ユニーク受信者数は2つのプロファイルではなく、4つの日次受信者行をカウントします。
マルチチャネルキャンペーンで、コンバージョン数がユニークユーザー数を超えることがあるのはなぜですか？
マルチチャネルCampaignでは、Brazeはユーザーごとではなくチャネルごとにコンバージョンをカウントします。ユーザーがコンバージョン期間内に1回のコンバージョンアクションを実行すると、Brazeはそのコンバージョンをユーザーがメッセージを受信した各チャネルに帰属させます。つまり、ユーザーが複数のチャネル（例えば、メールとプッシュの両方）でメッセージを受信してコンバージョンした場合、Brazeは各チャネルに1つずつ、複数のコンバージョンをカウントします。その結果、合計コンバージョン数がコンバージョンしたユニークユーザー数を超えることがあります。
例えば、マルチチャネルCampaignがユーザーにメールとプッシュ通知の両方を送信し、そのユーザーが両方のメッセージを受信した後、コンバージョン期間内に1回のコンバージョンアクションを実行した場合、Brazeはこれを2つのコンバージョンとしてカウントします。1つはメールに帰属し、もう1つはプッシュに帰属しますが、同じユーザーによる1回のアクションです。
Campaignに使用しているSegmentよりも、Campaignの到達可能なユーザー群が少ないのはなぜですか？
グローバルコントロールグループを設定している場合、到達可能なオーディエンスの一定割合がCampaignの受信から除外されます。つまり、Campaignが同じSegmentを使用していても、Segmentの到達可能なユーザー数がCampaignの到達可能なユーザー数よりも大きくなることがあります。
ローカルタイムゾーン配信とは何ですか？
ローカルタイムゾーン配信を使用すると、ユーザーの個別のタイムゾーンに基づいてSegmentにメッセージングCampaignを配信できます。ローカルタイムゾーン配信を使用しない場合、CampaignはBrazeでの会社のタイムゾーン設定に基づいてスケジュールされます。
例えば、ロンドンに拠点を置く会社が午後12時にCampaignを送信すると、アメリカ西海岸のユーザーには午前4時に届きます。アプリが特定の国でのみ利用可能な場合、これはリスクにならないかもしれません。そうでない場合は、早朝のプッシュ通知をユーザー群に送信することを避けることを強くお勧めします。
Brazeはユーザーのタイムゾーンをどのように認識しますか？
Brazeはユーザーのデバイスからタイムゾーンを自動的に判定します。これにより、タイムゾーンの正確性とユーザーの完全なカバレッジが確保されます。User APIを通じて作成されたユーザーや、タイムゾーンが設定されていないユーザーは、SDKによってアプリで認識されるまで、会社のタイムゾーンがデフォルトのタイムゾーンとして設定されます。
会社のタイムゾーンは、ダッシュボードの会社の設定で確認できます。
Brazeはローカルタイムゾーン配信のユーザーをいつ評価しますか？
Brazeは以下のタイミングでユーザーのエントリ資格を評価します：
- サモア時間（UTC+13）でのスケジュールされた日
- スケジュールされた日のローカル時間
ユーザーがエントリの資格を得るには、両方のチェックで資格を満たす必要があります。例えば、Canvasが2021年8月7日午後2時ローカルタイムゾーンで起動するようにスケジュールされている場合、ニューヨークにいるユーザーをターゲットにするには、以下の資格チェックが必要です：
- ニューヨーク 2021年8月6日午後9時
- ニューヨーク 2021年8月7日午後2時
エントリするには、ユーザーは両方の評価時点でオーディエンスとフィルターに一致する必要があります。最初のチェックでユーザーが資格を満たさない場合、Brazeは2回目のチェックを実行しません。ユーザーが起動前にSegmentに含まれている必要がある最低期間はありません。各チェック時点での資格のみが重要です。
この評価動作は、ダッシュボードでCampaignをどのくらい前にスケジュールするかとは別のものです。少なくとも24時間前にスケジュールすることは、メッセージがローカルタイムゾーンの24時間の時間枠全体にわたって配信されるようにするための推奨事項であり、各ユーザーが24時間オーディエンスに含まれている必要があるという要件ではありません。
例
例えば、CampaignがUTC午後7時に配信されるようにスケジュールされている場合、タイムゾーンが特定されるとすぐに（サモアなど）Campaign送信のキューイングを開始します。これはメッセージを送信する準備をしているのであり、Campaignを送信しているわけではありません。資格チェック時にユーザーがフィルターに一致しない場合、ターゲットオーディエンスには含まれません。
別の例として、同じ日に送信されるようにスケジュールされた2つのCampaign（1つは朝、もう1つは夕方）を作成し、最初のCampaignを既に受信したユーザーのみが2番目のCampaignを受信できるフィルターを追加したいとします。ローカルタイムゾーン配信では、一部のユーザーが2番目のCampaignを受信しない場合があります。これは、ユーザーのタイムゾーンが特定された時点で資格をチェックするため、スケジュールされた時間がそのユーザーのタイムゾーンでまだ到来していない場合、最初のCampaignを受信しておらず、2番目のCampaignの資格を満たさないためです。
以下のタイムラインは、時間制限のあるメンバーシップ期間を含むSegment定義を想定しています。この例では、ユーザーは参加から24時間後にSegmentを離脱します。このフィルター動作は、ユーザーが最初のチェックに合格しても2回目のチェックに不合格になる理由の1つです。
タイムラインの説明
- ユーザーAがPST午後6:59（サモア時間午後4:59）にSegmentに入ります。
- Brazeがサモア時間午後7時にSegmentメンバーシップをチェックし、次の24時間以内にCampaignを受信する資格のあるユーザーを判定します。この時点でユーザーAはSegmentに含まれています。
- Segmentには24時間の期間があるため、ユーザーAは参加から24時間後のPST午後6:59（サモア時間午後4:59）にSegmentを離脱します。
- ローカルタイムCampaignがPST午後7時に送信されますが、ユーザーAは既にSegmentを離脱しています。
ローカルタイムゾーンCampaignをスケジュールするにはどうすればよいですか？
前のセクションでは、Brazeがローカルタイムゾーン配信の資格を評価するタイミング（2回のチェック）について説明しました。このセクションでは、ダッシュボードでCampaignのスケジュールを設定するタイミング（スケジュールのリードタイム）と、24時間未満の通知でスケジュールした場合にどのユーザーがメッセージを受信するかについて説明します。
Campaignをスケジュールする際、指定した時間に送信することを選択し、Send campaign to users in their local time zoneを選択します。
Brazeは、すべてのローカルタイムゾーンCampaignを24時間前にスケジュールすることを強くお勧めします。このようなCampaignは丸一日かけて送信する必要があるため、24時間前にスケジュールすることで、メッセージがSegment全体に届くことが保証されます。ただし、必要に応じて24時間未満前にスケジュールすることも可能です。Brazeは送信時間を1時間以上過ぎたユーザーにはメッセージを送信しないことに注意してください。
例えば、午後1時にローカルタイムゾーンCampaignを午後3時にスケジュールした場合、Campaignはローカル時間が午後3時から午後4時の間のすべてのユーザーに即座に送信されますが、ローカル時間が午後5時のユーザーには送信されません。また、Campaignに選択した送信時間は、会社のタイムゾーンでまだ到来していない時間である必要があります。
24時間未満前にスケジュールされたローカルタイムゾーンCampaignを編集しても、メッセージのスケジュールは変更されません。ローカルタイムゾーンCampaignをより遅い時間に送信するように編集した場合（例えば、午後6時ではなく午後7時）、元の送信時間が選択された時点でターゲットSegmentに含まれていたユーザーは、引き続き元の時間（午後6時）にメッセージを受信します。ローカルタイムゾーンをより早い時間に送信するように編集した場合（例えば、午後5時ではなく午後4時）、Campaignは引き続きすべてのSegmentメンバーに元の時間（午後5時）に送信されます。
Canvasコンポーネントの場合、ローカルタイムゾーン配信でユーザージャーニーの次のコンポーネントを受信するために、ユーザーがそのコンポーネントに24時間含まれている必要はありません。
ユーザーがCampaignの再エントリを許可されている場合、元の時間（午後5時）に再度受信します。ただし、Campaignのそれ以降のすべての発生では、メッセージは更新された時間にのみ送信されます。
ローカルタイムゾーンCampaignの変更はいつ有効になりますか？
ローカルタイムゾーンCampaignのターゲットSegmentには、Segment全体への配信を保証するために、時間ベースのフィルターに少なくとも48時間の期間を含める必要があります。例えば、以下のフィルターで2日目のユーザーをターゲットにするSegmentを考えてみましょう：
- アプリの初回使用が1日以上前
- アプリの初回使用が2日未満前
ローカルタイムゾーン配信では、配信時間とユーザーのローカルタイムゾーンに基づいて、このSegmentのユーザーを見逃す可能性があります。これは、ユーザーのタイムゾーンが配信をトリガーする時点で、ユーザーがSegmentから離脱している可能性があるためです。
起動前にスケジュールされたCampaignにどのような変更を加えることができますか？
Campaignがスケジュールされている場合、メッセージの送信をキューに入れる前に、メッセージの構成以外の編集を行う必要があります。すべてのCampaignと同様に、起動後にコンバージョンイベントを編集することはできません。
スケジュールされたCampaignを更新しましたが、起動しなかったのはなぜですか？
これは、Campaignが更新されたのとまったく同じ時間に起動するようにスケジュールされている場合に発生することがあります。例えば、現在午後3:10で、Campaignを午後3:10に起動するように変更し、Update campaignを選択した場合、既に午後3:10を過ぎているため、スケジュールされた起動時間が過ぎています。Campaignを同じ時間にスケジュールする代わりに、Send as soon as campaign launchを選択してください。
スケジュールされたCampaignのメッセージがキューに入れられる前の「セーフゾーン」とは何ですか？
以下の時間内にメッセージの変更を行うことをお勧めします：
- 1回限りのスケジュールされたCampaign：スケジュールされた送信時間まで編集可能。
- 定期的なスケジュールされたCampaign：スケジュールされた送信時間まで編集可能。
- ローカル送信時間Campaign：スケジュールされた送信時間の24時間前まで編集可能。
- 最適送信時間Campaign：Campaignが送信されるようにスケジュールされた日の24時間前まで編集可能。
これらの推奨事項の範囲外で変更を行った場合、送信されるメッセージに更新が反映されない可能性があります。例えば、ローカル時間午後12時に送信されるようにスケジュールされたCampaignの3時間前に送信時間を編集した場合、以下のことが発生する可能性があります：
- Brazeは送信時間を1時間以上過ぎたユーザーにはメッセージを送信しません。
- 事前にキューに入れられたメッセージは、調整された時間ではなく、元のキューに入れられた時間に送信される可能性があります。
変更が必要な場合は、現在のCampaignを停止することをお勧めします（これにより、キューに入れられたメッセージがキャンセルされます）。その後、Campaignを複製し、必要な変更を加え、新しいCampaignを起動できます。最初のCampaignを既に受信したユーザーをこのCampaignから除外する必要がある場合があります。タイムゾーン送信に対応するために、Campaignのスケジュール時間を再調整してください。
夏時間の日に、毎日スケジュールされたCampaignにユーザーがエントリしなかったのはなぜですか？
夏時間（DST）の切り替え日には、毎日スケジュールされたCampaignが、時計が進むか戻るかに応じて、通常より最大1時間早くまたは遅く実行される可能性があります。Segmentがスケジュールされた送信時間の1時間以内のタイムスタンプを持つカスタム属性やイベントに依存している場合、DSTの日にCampaignが資格を評価する時点で、それらのユーザーがまだ条件を満たしていない可能性があります。
例えば、ユーザーが通常UTC午後3時にカスタム属性の更新を受け取り、Campaignがニューヨーク（東部時間）の午前10:30に毎日実行されるとします。ニューヨークが標準時間（UTC-5）の間、東部時間午前10:30はUTC午後3:30に相当するため、Campaignは属性がログされた後に実行されます。ニューヨークが夏時間（UTC-4）に移行すると、東部時間午前10:30はUTC午後2:30に相当するため、春の時計が進むDSTの日にはCampaignがUTC午後3時の属性更新の前に実行される可能性があります。条件を満たす属性がまだ存在しないため、それらのユーザーはフィルタリングされます。再エントリが無効になっている場合、前日にエントリしたユーザーは再エントリできず、その日のエントリがゼロになります。
これを回避するには、カスタム属性またはイベントの更新がCampaignのスケジュールされた送信時間の1時間以上前に行われるようにしてください。
Campaignにエントリするユーザー数が予想と異なるのはなぜですか？
Campaignにエントリするユーザー数が予想と異なるのは、オーディエンスとトリガーの評価方法によるものです。Brazeでは、トリガーの前にオーディエンスが評価されます（属性の変更トリガーを使用している場合を除く）。これにより、トリガーアクションが評価される前に、選択したオーディエンスに最初から含まれていないユーザーはCampaignから除外されます。
Campaignのトラブルシューティングについてさらにサポートが必要な場合は、問題発生から30日以内にBrazeサポートにお問い合わせください。直近30日分の診断ログのみ保持しています。
Campaign分析ページの「ユーザーデータを CSV 形式でエクスポート」と「メールアドレスを CSV 形式でエクスポート」オプションの違いは何ですか？
メールアドレスを CSV 形式でエクスポートオプションを選択すると、メールアドレスを持つユーザーのデータのみがダウンロードされます。例えば、100,000人のユーザーのSegmentがあり、そのうち50,000人のみがメールアドレスを持っている場合、メールアドレスを CSV 形式でエクスポートをクリックすると、エクスポートには50,000行のデータのみが含まれます。一方、ユーザーデータを CSV 形式でエクスポートを選択すると、すべてのユーザーデータがエクスポートされます。
API識別子でCampaignを検索できますか？
はい、Campaignsページでフィルター api_id:YOUR_API_ID を使用して、API識別子でCampaignを検索できます。詳しくはCampaignの検索を参照してください。
入力フィールドと表示テキストで空白の表示が異なるのはなぜですか？
入力フィールドと表示テキストコンポーネントでは、CSSスタイリングにより空白の処理が異なります。デフォルトの white-space: normal CSSを持つテキストコンポーネントでは、連続する複数のスペースは表示時に1つのスペースに折りたたまれます。これはレンダリングされたテキストの標準的なHTMLの動作です。
入力フィールドでは、正確なデータ入力のために正確なスペースを確認・編集する必要があるため、入力したとおりに複数のスペースが保持されます。つまり、複数のスペースを含むテキストは、入力フィールド（すべてのスペースが保持される）で表示した場合と、ダッシュボードの他の部分（CSSにより複数のスペースが折りたたまれる場合がある）で表示した場合とで、異なって見える可能性があります。
例えば、Campaign名やUTMパラメーターに複数のスペースを入力した場合、入力フィールドではすべてのスペースが保持されて表示されます。しかし、同じテキストが検索結果、Campaignリスト、その他のテキストコンポーネントに表示される場合、CSSの空白処理により複数のスペースが1つのスペースとして表示されることがあります。
API CampaignとAPIトリガーCampaignの違いは何ですか？
APIトリガーCampaignでは、Campaignのコピー、多変量テスト、再エントリルールをBrazeダッシュボード内で管理しながら、自社のサーバーやシステムからそのコンテンツの配信をトリガーできます。これらのメッセージには、リアルタイムでメッセージにテンプレート化される追加データを含めることもできます。
API Campaignは、APIを使用して送信されたメッセージを追跡するために使用されます。ほとんどのCampaignとは異なり、メッセージ、受信者、スケジュールを指定するのではなく、識別子をAPIコールに渡します。
アクションベースのCampaignとAPIトリガーCampaignの違いは何ですか？
アクションベース
アクションベースの配信Campaignまたはイベントトリガーキャンペーンは、トランザクションメッセージや達成ベースのメッセージに非常に効果的で、ユーザーが特定のイベントを完了した後に送信をトリガーできます。
| メリット | デメリット |
|---|---|
| • メッセージアクティビティログを通じて、プラットフォームに入ってくるJSONペイロードを確認可能（テストユーザーによるイベントトリガーの場合） • パーソナライゼーション要素がカスタムイベントプロパティに含まれる • カスタムイベントを使用して、メッセージの受信資格のあるユーザーのSegmentを作成可能 |
• データポイントを消費する |
APIトリガー
APIトリガーおよびサーバートリガーCampaignは、より高度なトランザクションの処理に最適で、自社のサーバーやシステムからCampaignコンテンツの配信をトリガーできます。メッセージをトリガーするAPIリクエストには、リアルタイムでメッセージにテンプレート化される追加データを含めることもできます。
| メリット | 考慮事項 |
|---|---|
| • データポイントを消費しない • パーソナライゼーション要素がJSONペイロードプロパティに含まれる |
• JSONペイロードプロパティでメッセージの受信資格のあるユーザーのSegmentを作成できない • メッセージアクティビティログで入ってくるJSONペイロードを確認できない |
「リクエストタイムアウト」エラーのサポートチケットを送信する際に何を含めるべきですか？
CampaignまたはCanvasの作成・編集中に「リクエストタイムアウト」エラーが発生し、Brazeサポートに連絡する必要がある場合は、解決を迅速化するために以下の情報を含めてください：
- 画面録画：エラーが表示される前に行った手順（ページ遷移を含む）の録画。
- タイムスタンプとタイムゾーン：エラーが発生した正確な時間とタイムゾーン。
- ブラウザとバージョン：使用しているブラウザ（例：Chrome 120、Safari 17）と、別のブラウザでエラーの再現を試みたかどうか。
- 再現手順：エラーをトリガーするアクションの明確な説明（関連する特定のCampaignまたはCanvasの設定を含む）。
- ネットワークログ（オプション）：ブラウザの開発者ツール（Networkタブ）を開き、エラーを再現し、ネットワークログをHAR（HTTP Archive）ログとしてエクスポートします。これにより、サポートチームがどのAPIコールがタイムアウトしているかを特定できます。
送信分析が設定した最大受信者数の制限と一致しないのはなぜですか？
アクティブなCampaignに最大受信者数の制限を追加または変更した場合、以下の理由により送信分析に反映されない場合があります：
- 起動後に制限を追加した場合：Campaignの起動時に最大受信者数の制限が設定されていない場合、制限を適用する前に既にキューに入れられたメッセージは引き続き送信されます。制限は、変更を保存した後にキューに入れる送信にのみ有効になります。
- レート制限との相互作用：Campaignにレート制限も設定されている場合、メッセージはより長い時間枠にわたって配信される可能性があります。最大受信者数の制限は、メッセージが配信される時ではなく、キューに入れられる時に評価されます。メッセージが既にキューにある間に制限が変更された場合、それらのメッセージには元の制限が適用されます。
- 定期的なCampaign：定期的なCampaignでは、スケジュールされた各送信が最大受信者数の制限を独立して評価します。送信間で制限を変更しても、以前の送信数は遡って調整されません。
不一致を避けるために、Campaignを起動する前に最大受信者数の制限を設定し、送信が進行中の間は変更しないようにしてください。
送信数が推定オーディエンスサイズよりも少ないのはなぜですか？
送信数が推定オーディエンスサイズよりも少なくなる要因はいくつかあります：
- アクションベースの配信：ユーザーはトリガーを実行した後にのみ送信が生成されるため、送信は時間の経過とともに蓄積され、Campaignを最初に構築した際に表示される事前の推定値に遅れることがあります。
- 起動後のオーディエンス編集：起動後にエントリまたはターゲットフィルターを変更すると、推定オーディエンスのスナップショットが、後の送信で実際に条件を満たすユーザーと同期しなくなる可能性があります（例えば、ユーザーが再エントリの資格がない場合）。
- オーディエンスパスステップ：Canvasの場合、オーディエンスパスステップは、ユーザーが条件を満たす最も優先度の高いブランチにのみメッセージを送信するため、フラットなSegmentカウントと比較して送信数が減少する可能性があります。
- コントロールグループ：グローバルコントロールグループまたはCampaignレベルのコントロールグループが使用されている場合、オーディエンスの一部が配信から除外されます。
- 配信タイミングと時間枠：ローカルタイムゾーンまたはスケジュールされたCampaignでは、ユーザーはエントリ時と送信時の両方で条件を満たす必要があります。特定のタイムゾーンのユーザーは配信時間枠の外に該当する場合があります。
- メールの重複排除：CampaignまたはCanvasが同じメールアドレスを持つ複数のユーザーをターゲットにしている場合、送信時にそのメールアドレスを持つランダムなユーザーが選択されます。メッセージは1回だけ送信され、同じメールアドレスに複数回送信されないよう重複排除されますが、推定オーディエンスサイズにはすべてのユーザーが含まれます。
- メール配信フィルター：メールCampaignの場合、Brazeはハードバウンスしたユーザー、メールの配信停止をしたユーザー、スパムとしてマークされたユーザー、プロファイルにメールアドレスがないユーザー、または必要なサブスクリプショングループに登録していないユーザーを除外します。これらのチェックは送信時に実行されるため、Segmentに含まれているユーザーでも、実際の送信数からは除外される可能性があります。
- グローバルフリークエンシーキャップ：ワークスペースレベルのキャップにより、同じ時間枠内で別のメッセージを受信できない資格のあるユーザーが発生し、実際の送信数が減少します。
- 新しくインポートされたユーザー：資格を得たばかりのプロファイルは、次の評価または送信パスまで受信しない場合があるため、カウントは後の実行で追いつきます。
- プッシュの到達可能性：プッシュCampaignの場合、オーディエンスが正しいアプリでプッシュが有効になっていることを確認してください。プッシュ有効のユーザーでフィルタリングしていない場合、推定オーディエンスにプッシュを受信できないプロファイルが含まれる可能性があります。より正確な運用上の推定値については、Target UsersステップのReachable Usersを確認してください。
- レート制限：レート制限が適用されている場合、メッセージは時間をかけて配信され、一部の送信が遅延されるか、まだカウントに反映されていない場合があります。
- 再エントリの時間枠：まだ再エントリの資格がないユーザーはクールダウン期間中に再度受信しないため、その期間の送信数は推定オーディエンスサイズを下回ります。
- レポート期間：分析の時間範囲にすべての送信が含まれていない場合があります。
- Segmentの再評価：送信時に再評価するアクションベースまたはスケジュールされたCampaignでは、Campaignがキューに入れられた時点でSegmentに含まれていたユーザーが、メッセージが実際に送信される時点では条件を満たさなくなっている場合があります。
- 送信キャップ：Target Audiencesの最大ユーザー数（または同様のキャップ）により、キャップに達した時点で配信が停止されます。
- 厳格なデバイスまたはブラウザフィルター：最新のアプリバージョンやブラウザのみに一致するフィルターは、広範なSegmentプレビューと比較して、送信時の到達可能なセットを縮小します。