Skip to content

競合

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

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

競合の種類

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

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

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

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

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

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

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

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

アプリ内メッセージ

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

ベストプラクティス

遅延を導入する

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

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

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

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

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

  • 別々の API エンドポイントを使用してユーザーを作成し、キャンバスやキャンペーンをトリガーする場合
  • /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つの一般的な競合は、アクションベースのキャンペーンやキャンバスを、オーディエンスフィルターと同じトリガー（属性の変更やカスタムイベントの実行など）で設定した場合に発生する可能性があります。ユーザーがトリガーイベントを実行した時点でオーディエンスに含まれていない場合、キャンペーンを受信したりキャンバスに入ったりすることはありません。

ベストプラクティス

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

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

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

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

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

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

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

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

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

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

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

1
2
3
4

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

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

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

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

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