Skip to content

競合状態

競合状態は、結果が複数のイベントの順序またはタイミングに依存する場合に発生します。たとえば、期待されるイベントの順序が「イベントA」の後に「イベントB」であるにもかかわらず、「イベントA」が先に来ることもあれば、「イベントB」が先に来ることもある場合、これは競合状態と呼ばれます。これらのイベントが共有リソースやデータへのアクセスを競い合うため、予期しない結果やエラーが発生する可能性があります。

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

競合状態のタイプ

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

  • 新規ユーザーのターゲティング
  • 複数のAPIエンドポイントの使用
  • アクションベースのトリガーとオーディエンスフィルターの一致

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

シナリオ1：新規ユーザーのターゲティング

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

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

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

アプリ内メッセージの場合、トリガーされる前にユーザーのデバイスにアプリ内メッセージが読み込まれている必要があります。トリガーイベントがオンボーディングプロセスの一部である場合、またはユーザーが最初のセッションの一部としてカスタムイベントのSegmentから離脱する場合、ユーザーがアプリ内メッセージを見ることができない可能性が高くなります。

アプリ内メッセージ

アプリ内メッセージでは、状況がより複雑になることがあります。アプリ内メッセージは、トリガーされる前にSDKに配信されてキャッシュされる必要があります（通常はセッション開始時）。トリガーイベントがユーザー作成プロセスの一部である場合、またはアプリ内メッセージCampaignがユーザーが最初のセッション中にオーディエンス条件を満たす前（または満たさなくなった後）に配信される場合、アプリ内メッセージが表示されない可能性があります。

ベストプラクティス

遅延を導入する

新規ユーザーが作成された後、ターゲットCampaignやCanvasを送信する前に遅延を追加できます。このタイミング遅延により、ユーザープロファイルが作成され、メッセージの受信資格を決定する関連属性が更新される時間が確保されます。

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

この遅延は、新規ユーザーがCanvasにエントリするトリガーとなる特定のカスタムイベントに対してBraze SDKで追加することもできます。

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

複数のAPIエンドポイントでもこの競合状態が発生するシナリオがいくつかあります。たとえば以下の場合です。

  • 別々のAPIエンドポイントを使用してユーザーを作成し、CanvasやCampaignをトリガーする場合
  • /users/track エンドポイントに対してカスタム属性、イベント、または購入を更新するために複数の個別コールを行う場合

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

ベストプラクティス

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

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

スケジュールされたメッセージAPIリクエストを送信する場合、これらのリクエストは個別である必要があり、スケジュールされたAPIリクエストを送信する前にユーザーが作成されている必要があります。

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

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

これらのオブジェクトがトリガーに含まれている場合、メッセージがトリガーされる前に属性が先に処理されるため、潜在的な競合状態が排除されます。トリガープロパティはユーザープロファイルを更新せず、メッセージのコンテキストでのみ使用されることに注意してください。

POST: Track users (sync) エンドポイントを使用する

/users/track/sync/ エンドポイントを使用して、カスタムイベントと購入を記録し、ユーザープロファイル属性を同期的に更新します。このエンドポイントを使用してユーザープロファイルを同時に単一のコールで更新することで、潜在的な競合状態を防ぐことができます。

シナリオ3：アクションベースのトリガーとオーディエンスフィルターの一致

もう1つの一般的な競合状態は、アクションベースのCampaignやCanvasを、オーディエンスフィルターと同じトリガー（属性の変更やカスタムイベントの実行など）で設定した場合に発生する可能性があります。ユーザーがトリガーイベントを実行した時点でオーディエンスに含まれていない場合、Campaignを受信したりCanvasにエントリしたりすることはありません。

ベストプラクティス

遅延後にオーディエンスを確認する

トリガー条件を含むオーディエンスフィルターの使用を避けるために、配信前にオーディエンスを確認することをお勧めします。たとえば、Canvasのメッセージステップで配信バリデーションを使用して、メッセージ送信時にオーディエンスが配信条件を満たしていることを追加で確認できます。また、Canvasの離脱条件を活用して、ユーザージャーニーの任意の時点で条件を満たしたユーザーを離脱させることもできます。

Campaignでは、離脱イベントを使用して、トリガーイベントを持つCampaignが遅延中に離脱イベントを実行したユーザーへのメッセージを中止できるようにすることができます。

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

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

たとえば、Campaignのトリガーが「購入した」で、オーディエンスフィルターが「何らかの購入をした」の場合、この冗長性が競合状態を引き起こす可能性があります。

トリガーイベントが更新済みであることを前提とするオーディエンスフィルターを避ける

このベストプラクティスは、トリガーイベントとの冗長なフィルターを避けることと似ています。通常、トリガーイベントがユーザープロファイルに更新済みであることを前提とするフィルターは失敗します。

Liquidの中止を使用する（属性のみ）

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

この場合、Campaignでトリガー遅延を実装するか、Canvasで遅延ステップを使用してユーザープロファイルが一定期間更新されるのを待ち、次のLiquid中止ロジックを使用できます。

1
2
3
4

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

ユーザーデータの管理方法を確認する

Canvasのエントリ評価中に競合状態が発生すると、ユーザーが本来入るべきではないCanvasに入ってしまう可能性があります。たとえば、ユーザーのプロファイルがオーディエンスに含まれるように設定された後、Canvasがユーザーをキューに入れた後にオーディエンスの資格がなくなるように更新される場合があります。

ユーザーが同じ秒内にCanvasのエントリイベントを複数回トリガーした場合、Brazeはその秒に対して1回のエントリのみを許可します（再エントリが有効な場合でも）。これにより重複エントリが防止されるため、Canvasのエントリ総数はトリガーイベントの総数よりも少なくなる場合があります。

ユーザーデータがどのように管理・更新されているか、特に特定の属性がいつどのように更新されるか（SDK、API、バッチAPI、その他の方法など）を確認することをお勧めします。これにより、ユーザーがCampaignやCanvasに入った理由と、ユーザーのプロファイルが更新されたタイミングを特定し、明確にすることができます。
New Stuff!