競合状態

競合状態は、結果が複数の事象の順序またはタイミングに依存する場合に発生します。例えば、「イベントA」→「イベントB」という順序が望ましいが、「イベントA」が先に来ることもあれば、「イベントB」が先に来ることもあります - これは競合状態として知られています。これらのイベントは、共有リソースやデータにアクセスするために競合するため、予期せぬ結果やエラーにつながる可能性があります。

Braze では、ユーザーデータやイベントに基づいて複数のアクションが同時にトリガーされると、競合状態が発生する可能性があります。例えば、ユーザーが複数のキャンペーン (ニュースレターへの登録や購入など) をトリガーした場合、正しい順序でメッセージを受け取れない可能性があります。

競合状態のタイプ

最も一般的な競合状態は、以下のような場合に発生する可能性があります。

• 新規ユーザーをターゲットにする
• 複数の API エンドポイントを使用する
• アクションベースのトリガーとオーディエンスフィルターのマッチング

以下のシナリオを検討し、これらの競合状態を回避するためのベストプラクティスを実施します。

シナリオ1:新規ユーザーをターゲットにする

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

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

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

ベストプラクティス

遅延を導入する

新規ユーザーが作成された後、ターゲットキャンペーンやキャンバスを送信する前に遅延を追加することができます。このタイミング遅延により、ユーザープロファイルが作成され、メッセージ受信の適格性を決定する可能性のある関連属性が更新されます。

例えば、ユーザーがアプリに登録した後、24時間後にプロモーションオファーを送ることができます。あるいは、ユーザーを作成したり、カスタム属性をログに記録している場合は、この競合状態を避けるために、処理を進める前に1分間の遅延を加えることができます。

シナリオ2：複数の API エンドポイントを使用する

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

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

ユーザー情報が /users/trackエンドポイント[を使用して Braze に送信される場合、処理に数秒かかることがあります。つまり、/users/track と /campaign/trigger/send のようなメッセージングエンドポイントに対して同時に要求が行われた場合、メッセージが送信される前にユーザー情報が更新される保証はありません。

ベストプラクティス

複数のエンドポイントを使用する場合は、リクエストを1つずつ送信します。

複数のエンドポイントを使用している場合は、リクエストをずらして、次のリクエストが始まる前に各リクエストが完了するようにしてみるとよいです。これにより競合の可能性を減らすことができます。例えば、ユーザー属性を更新してメッセージを送信する必要がある場合、エンドポイントを使用してメッセージを送信する前に、まずユーザープロファイルが完全に更新されるのを待ちます。

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

トリガーに主要データを含める

複数のエンドポイントを使用する代わりに、campaign/trigger/send エンドポイントを使用して、単一の API 呼び出しにユーザー属性とトリガープロパティを含めることができます。

これらのオブジェクトがトリガーに含まれている場合、メッセージがトリガーされる前に属性が最初に処理されるため、競合状態になる可能性がなくなります。トリガープロパティはユーザープロファイルを更新するのではなく、メッセージのコンテキストの中だけで使われることに注意してください。

POST を使用する：ユーザー (一括) エンドポイントの追跡

この/users/track/sync/エンドポイントを使用して、カスタムイベントと購入を記録し、ユーザープロファイル属性を同期的に更新します。このエンドポイントを使用して、1回の呼び出しでユーザープロファイルを同時に更新すると、競合状態の可能性を防ぐのに役立ちます。

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

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

ベストプラクティス

遅延後にオーディエンスをチェックする

トリガー条件を含むオーディエンスフィルターの使用を避けるため、配信前にオーディエンスをチェックすることをおすすめします。例えば、キャンバスメッセージステップで追加チェックとして配信検証を使用してメッセージ送信時にオーディエンスが配信基準を満たしていることを確認できます。また、キャンバスの終了条件を活用することで、ユーザージャーニー中のどの時点でも、条件を満たしたユーザーを終了させることができます。

キャンペーンでは、終了イベントを使用して、トリガーイベントのあるキャンペーンが遅延中に終了イベントを実行するユーザーへのメッセージを中止できるようにすることができます。

トリガーイベントでユニークなフィルターを使用する。

フィルターを構成するときに、「念のため」冗長フィルターを追加することをおすすめします。しかし、この冗長性はさらなる問題を引き起こす可能性ありますその代わり、可能な限りトリガーを含むフィルターの使用は避けます。これが競合状態を避けるための最も安全なルートです。

たとえば、キャンペーントリガーが「購入済み」で、オーディエンスフィルターが 「何らかの購入を行った」の場合、この冗長性によって競合状態が発生する可能性があります。

トリガーイベントが更新されたと仮定するオーディエンスフィルターは避けます。

このベストプラクティスは、トリガーイベントで冗長なフィルターを回避することと似ています。通常、トリガーイベントがユーザープロファイルに更新されたと仮定するフィルターは失敗します。

Liquid aborts を使用する (属性のみ）

キャンペーンおよびキャンバスのステップでは、エントリスケジュールでトリガー属性を含むオーディエンスフィルターの使用を避けるために、Liquid aborts を使用します。例えば、「好きな色」という配列属性があり、その属性配列を任意の値で更新し、更新完了後に配列に「青」という色が入っているユーザーをターゲットにしたいとします。この例でオーディエンスフィルターを使用すると、競合状態が発生し、配列に「青」を初めて追加したユーザーを見逃すことになります。

このケースでは、キャンペーンでトリガー遅延を実装するか、キャンバスで遅延ステップを使用し、一定期間ユーザープロファイルを更新できるようにしてから、次の Liquid abort ロジックを使用します。

1
2
3
4
{%assign colors={{custom_attribute.$(Favorite Color)|split:”,”}}%}
{%unless colors contains ‘Blue’%}
{%abort_message(Blue not present)%}
{%endunless%}