競合状態

競合状態とは、結果が他のイベントのシーケンスやタイミングに依存する概念です。

例えば、「イベントA」→「イベントB」という順序が望ましいが、「イベントA」が先に来ることもあれば、「イベントB」が先に来ることもあります - これは競合状態として知られています。

新規ユーザーをターゲットにする

Braze で最も一般的な競合状態の1つは、新しく作成されたユーザーをターゲットとするメッセージで発生します。ここで、予想されるイベントの順序は次のとおりです。

1. ユーザーが作成される
2. 同じユーザーが即座にメッセージのターゲットとなり、カスタムイベントを実行するか、カスタム属性を記録する。

しかし、場合によっては、2番目のイベントが先にトリガーされることもあります。これは、まだ作成されていないユーザーにメッセージが送信されようとしていることを意味し、その結果、そのユーザーはメッセージを受け取りません。イベントや属性が、まだ存在しないユーザープロファイルに記録されようとしている場合も同様です。

複数の API エンドポイントを使用する

複数の API エンドポイントがこの競合状態を引き起こすシナリオもいくつかあります。以下のような場合です。

• 別々の API エンドポイントを使用してユーザーを作成し、キャンバスやキャンペーンをトリガーする
• カスタム属性、イベント、または購入を更新するために、/users/track エンドポイントに複数の個別の呼び出しを行う

ユーザー情報が /users/track エンドポイントを経由して Braze に送信される場合、処理に数秒かかることがあります。その結果、/users/track とメッセージングエンドポイントに同時にリクエストがあった場合、メッセージが送信される前にユーザー情報が更新される保証は今のところありません。

前述のどちらのシナリオでも、これらのリクエストが同じ API リクエストで行われるのであれば、問題はないはずです。

スケジュールされたメッセージ API リクエストを送信する場合、これらのリクエストは別個のものでなければならず、スケジュールされた API リクエストを送信する前にユーザーを作成しなければならないことに注意してください。

競合状態を回避する

この競合状態を回避する1つの方法は、ユーザの作成と、キャンバスまたはキャンペーンによるそのユーザーのターゲティング、またはユーザープロファイルへの属性またはイベントのログの取得の間に、1分程度の遅延を追加することです。

同様に Attributes オブジェクトを使用してユーザーを追加、作成、または更新し、/canvas/trigger/send エンドポイントまたは /campaign/trigger/send エンドポイントを使用してターゲットにすることができます。この API リクエストは、ユーザーをターゲットにする前に、attributes オブジェクトを処理します。

このオブジェクトに含まれる属性は、Braze がキャンペーンの送信を開始する前に処理されます。send_to_existing_only フラグが false に設定され、external_user_id が Braze データベースに存在しない場合、Braze がキャンペーンの送信を開始する前に、external_user_id のユーザープロファイルを作成し、ユーザープロファイルに関連付けられた属性を処理します。また、send_to_existing_only フラグが false に設定されている場合、ユーザーを作成するためには、属性オブジェクトが含まれていなければなりません。send_to_existing_only フラグは、ユーザーのエイリアスでは使えません。

アクションベースのトリガーとオーディエンスフィルターのマッチング

アクションベースのキャンペーンまたはキャンバスを、オーディエンスフィルターと同じトリガー (変更された属性やカスタムイベントを実行した場合など) で構成した場合、別の一般的な競合状態が発生する可能性があります。ユーザーは、トリガーイベントを実行した時点ではオーディエンスにいない可能性があります。つまり、キャンペーンを受け取ることもキャンバスに入ることもありません。この場合、Braze では、オーディエンスフィルターに一致するようにトリガーを構成しないことをお勧めしています。

競合状態を回避する

この競合状態を回避する一つの方法は、1分以上の遅延を追加して、ユーザーがキャンバスに入るのに十分な時間を与えることです。