セグメントのトラブルシューティング

エラー数

ターゲットオーディエンスが複雑すぎて起動できない

このまれなエラーは、ターゲットオーディエンスに正規表現値が多すぎる、正規表現値が長すぎる、詳細すぎるフィルターs (“ は30,000 zip コード s” のいずれか)、またはフィルターs が多すぎる場合に発生します。これには、フィルターs が参照Segments 内にあるか、Target オーディエンス ステップでフィルターs として追加されたかにかかわらず、キャンペーンまたはキャンバスオーディエンス内のすべてのフィルターs が含まれます。

Segment フィルターsをキャンペーンまたはキャンバスに追加すると、これらのフィルターsはBrazeでクエリーに変換されます(これらのクエリーの文字数は、ダッシュボード ユーザーが表示する文字数の1:1ではありません)。Braze がキャンペーンまたはキャンバスを送信すると、ターゲットオーディエンス内のすべてのフィルターを結合するクエリーが実行されます。対象オーディエンスに対する結果の問合わせの文字数を制限するしきい値をアプリします。特定のキャンペーンまたはキャンバスについて、すべての追加フィルターs を含む、参照されるすべてのSegmentの文字数を合計します。与えられたSegmentに対して、すべてのフィルターsとフィルターの文字数を合計します。

キャンペーン、キャンバス、またはSegmentがしきい値を超えて起動できない場合、ダッシュボードにエラーが表示されます。このエラーが表示された場合は、次のように、目標オーディエンスを単純化してから再起動してください。

• オーディエンスが複数のSegmentを参照している場合は、Segmentに冗長性がないことを確認します。たとえば、複数のSegmentで同じフィルターがイヤーインをアプリするなどです。
• Segment フィルター s で古いデータを参照していないことを確認します。たとえば、古くなったフィルターは、キャンバスが数カ月間停止されているにもかかわらず、この1週間に特定のキャンバスステップを受け取っていないユーザーを探す場合があります。
• ユーザー ID s またはメール s (しばしば正規表現フィルターを使用) の単なるリストであるセグメントは、CSV インポート に変換して、単一のCSV フィルターに単純化できます。
• CDIがあれば、データウェアハウスから直接的にグループを引っ張るCDI Segmentを作成できるかもしれません。

また、サポートに問い合わせて、フィルター最適化の詳細を確認することもできます。

X 使用中または停止中のキャンペーンまたはキャンバスがオーディエンスの複雑性しきい値を超えている

このバナーは、キャンペーンまたはキャンバスリストの最上部に表示されます。このバナーは、アクティブまたは停止したキャンペーンまたはキャンバスに、オーディエンスの複雑さのしきい値を超えるオーディエンスs がある場合に常に表示されます。バナーを選択して、しきい値を超えたキャンペーンまたはキャンバスだけにリストをフィルターし、[ターゲットオーディエンスが複雑すぎて起動できないトラブルシューティングステップに従います。

フィルタが10,000 文字を超えているか、保存するには長すぎます

Brazeは、個々のSegment フィルターs を最大10,000 文字に制限します。フィルターがSegment内にあるか、キャンペーンまたはキャンバスに直接追加されているかにかかわらず、個々のフィルターが10,000 文字を超えると、警告アプリが表示されます。

このエラーはめったに起こりませんが、発生した場合は、通常、ユーザー IDs またはメールの住所の一覧を対象とする正規表現フィルターs を使用します。この場合、次のステップs に従ってフィルターs をCSV に変換できます。

1. 影響を受けるSegmentまたは固有の正規表現フィルターからユーザーs をエクスポートします。
2. 必要に応じてCSV をクリーニングします。Braze識別子またはAppboy識別子が必要ですが、必要でない場合は他のすべての列を削除できます。また、最新のデータを確認するために、データを確認することをお勧めします(たとえば、対象外になったユーザーを削除します)。
3. [CSVファイルを再度インポートします。これにより、ユーザーs が自動的に単一の高効率なCSV ベースのフィルターにまとめられます。

ユーザーの行動

ユーザーがセグメントから外れた

セグメントの作成中に、あるユーザーが使用できない場合、ユーザー自身のアクティビティや、以前に対話した他のキャンペーンやキャンバスの結果として、そのユーザーのセグメント適格性を決定するユーザーデータが変更された可能性があります。再適格性がオンになっている場合、ユーザープロファイルには受信したキャンペーンの最新データが表示されます。

フィルターで特定のアプリに絞り込んでいるときに、他のアプリのユーザーの情報が表示される

ユーザーは複数のアプリを持つことができるため、セグメンテーションページの [使用したアプリ] セクションで特定のアプリを選択すると、少なくともそのアプリを持っているユーザーの結果が表示されます。このフィルターでは、そのアプリだけを使用しているユーザーの結果は得られない。

フィルタリング

フィルタオプションの変更

フィルターオプションは、カスタム属性にBrazeに渡すフォーマット（データ型）に関連している。Brazeがカスタム属性用に認識しているデータ型を確認するには、「データ設定」>「カスタム属性」に移動する。

フィルターオプションが変更された場合は、データが以前とは異なるフォーマット（データ型）でBrazeに渡されていることを示している。各種データ型とそのフィルター設定オプションの詳細については、カスタム属性データ型を参照してください。

ダッシュボードでカスタム属性のデータタイプを変更すると、異なるフォーマットでBrazeに送信されたデータは拒否されることに留意してほしい。

分析とレポート

キャンペーンアナリティクスのメッセージ送信数またはユニーク受信者数がセグメント数と一致しない

キャンペーン分析で [送信済みメッセージ] または [ユニーク受信者数] の数がセグメントフィルター Has received message from campaign X のユーザー数と一致しない場合、次の 2 つの理由が考えられます。

1. キャンペーン開始後に、ユーザーが孤立したか、アーカイブまたは削除が行われた可能性がある。
   
   例えば、1,000人のユーザーがキャンペーンを受け、同じ日にCSVエクスポートを行ったとしよう。1,000人のユーザーが報告されていることがわかるだろう。翌月、1,000 人のユーザーのうち 50 人が削除されます (例えば、users/delete エンドポイントによる)。ここでもう一度 CSV エクスポートを行うと、950 人のユーザーが報告されますが、[キャンペーン分析] の [ユニーク受信者数] は 1,000 人のままです。
   
   言い換えれば、Unique Recipients（ユニーク受信者）メトリクスは、インクリメントされたカウントであり、セグメンターとCSVエクスポートは、現在存在するユーザーのカウントを提供する。
   
   

2. キャンペーンには再応募資格が設定されているため、ユーザーは何度もキャンペーンに再応募できる。
   
   例えば、あるメールキャンペーンで、再応募資格を0分に設定し（ユーザーはオーディエンスセグメントの条件を満たしている限り、キャンペーンに再応募できる）、キャンペーンを1ヶ月以上実施しているとしよう。このフィールドには重複したユーザーに送信されたメッセージが含まれるため、Campaign Analyticsの 送信メッセージ数はセグメントの数と一致しない。
   
   これは、Braze がユニークユーザーを日次ユニーク受信者数 (1 日に特定のメッセージを受信したユーザー数) としてカウントしているためです。つまり、「ユニーク」な期間は 1 日しかないため、再適格者はユニーク受信者として複数回カウントされます。その結果、日次ユニーク受信者数が CSV エクスポートのユーザープロファイル数より多くなることがあります。CSV ファイル内のユーザープロファイルは、真にユニークなものです。

1 つのアプリのみでセッションを記録しているにもかかわらず、ユーザが2 つのアプリに割り当てられている

Segmentを作成するときに、使用された固有のアプリs を持つユーザーs を対象にすることができます。ユーザーには、特定のセッションをアプリに割り当てるアプリが必要ですが、ログに記録されたセッションをアプリに残さずに、特定のアプリに割り当てることができる2 つのシナリオがあります。

最初のシナリオは、app_id フィールドが/users/track エンドポイントを使用するときに入力される場合です。具体的には、event またはpurchase object を使用する場合です。以下に例を示します。

1
2
3
4
5
6
7
8
9
10
{
    "events": [
    {
      "external_id": "john_doe123",
      "app_id": "my_web_app_id",
      "name": "Custom Event",
      "time": "2025-08-17T19:20:30+1:00"
    }
  ]
}

2 番目のシナリオは、app_id フィールドが/users/track エンドポイントを使用してプッシュチケットを移行するときに入力される場合です。以下に例を示します。

1
2
3
4
5
6
7
8
9
10
11
12
13
"app_group_id": "{YOUR_APP_GROUP_ID}",
"attributes": [
{
      "push_token_import": false,
      "external_id": "external_id1",
      "country": "US",
      "language": "en",
      "{YOUR_CUSTOM_ATTRIBUTE}": "{YOUR_VALUE}",
      "push_tokens": [
        {"app_id": "{APP_ID_OF_OS}", "token": "{PUSH_TOKEN_STRING}"}
      ]
  }
]