競合
競合は、結果が複数のイベントの順序またはタイミングに依存する場合に発生します。たとえば、期待されるイベントの順序が「イベントA」の後に「イベントB」であるにもかかわらず、「イベントA」が先に来ることもあれば、「イベントB」が先に来ることもある場合、これは競合と呼ばれます。これらのイベントが共有リソースやデータへのアクセスを競い合うため、予期しない結果やエラーが発生する可能性があります。
Brazeでは、ユーザーデータやイベントに基づいて複数のアクションが同時にトリガーされた場合に競合が発生することがあります。たとえば、ユーザーが複数のキャンペーン（ニュースレターへの登録や購入など）をトリガーした場合、メッセージが正しい順序で届かない可能性があります。
競合の種類
最も一般的な競合の種類は、以下の操作を行っているときに発生する可能性があります。
- 新規ユーザーのターゲティング
- 複数のAPIエンドポイントの使用
- アクションベースのトリガーとオーディエンスフィルターのマッチング
- 「ステップとのインタラクション」トリガーの使用
以下のシナリオを検討し、これらの競合を回避するためのベストプラクティスを実装してください。
シナリオ1：新規ユーザーのターゲティング
Brazeでは、最も一般的な競合の1つが、新しく作成されたユーザーをターゲットとするメッセージで発生します。想定されるイベントの順序は次のとおりです。
- ユーザーが作成される。
- 同じユーザーがすぐにメッセージのターゲットとなるか、カスタムイベントを実行するか、カスタム属性を記録する。
しかし、場合によっては2番目のイベントが先にトリガーされることがあります。これは、まだ存在していないユーザーにメッセージを送信しようとしていることを意味します。その結果、そのユーザーはメッセージを受信できません。これはイベントや属性にも当てはまり、まだ作成されていないユーザープロファイルに対してイベントや属性を記録しようとする場合も同様です。
アプリ内メッセージの場合、トリガーされる前にアプリ内メッセージがユーザーのデバイスに読み込まれている必要があります。トリガーイベントがオンボーディングプロセスの一部である場合や、ユーザーが最初のセッションの一環としてカスタムイベントのセグメントから外れた場合、ユーザーはアプリ内メッセージを見ることができない可能性が高くなります。
アプリ内メッセージ
アプリ内メッセージの場合、状況はより複雑になることがあります。アプリ内メッセージは、トリガーされる前にSDKに配信されてキャッシュされる必要があります（通常はセッションの開始時に行われます）。トリガーイベントがユーザー作成プロセスの一部である場合や、アプリ内メッセージキャンペーンがユーザーが最初のセッション中にオーディエンス条件を満たす前（または満たさなくなった後）に配信された場合、アプリ内メッセージが表示されない可能性があります。
ベストプラクティス
遅延を導入する
新規ユーザーが作成された後、ターゲットとなるキャンペーンやキャンバスを送信する前に遅延を追加できます。この遅延により、ユーザープロファイルが作成され、メッセージの受信資格を決定する関連属性が更新されるための時間が確保されます。
たとえば、ユーザーがアプリに登録した後、24時間後にプロモーションオファーを送信できます。または、ユーザーを作成したりカスタム属性を記録したりする場合、この競合を回避するためにプロセスを進める前に1分間の遅延を追加できます。
また、新規ユーザーがキャンバスに入るトリガーとなる特定のカスタムイベントに対して、Braze SDKでこの遅延を追加することもできます。
シナリオ2: 複数のAPIエンドポイントの使用
Brazeでは速度と柔軟性を最大化するために非同期処理を使用しています。つまり、APIコールが個別に送信された場合、送信された順序で処理されることは保証されません。
複数のAPIエンドポイントを使用する場合にも、次のような状況でこの競合が発生する可能性があります。
- 別々のAPIエンドポイントを使用してユーザーを作成し、キャンバスやキャンペーンをトリガーする場合
/users/trackエンドポイントに対して複数の個別コールを行い、カスタム属性、イベント、または購入を更新する場合
/users/trackエンドポイントを使用してBrazeにユーザー情報を送信した場合、処理に数秒かかることがあります。つまり、/users/trackとメッセージングエンドポイント（/campaign/trigger/sendなど）に同時にリクエストを送信した場合、メッセージが送信される前にユーザー情報が更新される保証はありません。
ユーザー属性とイベントが同じリクエストで送信された場合（/users/trackまたはSDKから）、Brazeはイベントの処理やメッセージの送信を試みる前に、属性を先に処理します。
ベストプラクティス
複数のエンドポイントを使用する場合、リクエストを1つずつ送信する
複数のエンドポイントを使用している場合、各リクエストが完了してから次のリクエストを開始するように、リクエストをずらして送信することを試みてください。これにより、競合が発生する可能性を減らすことができます。例えば、ユーザー属性を更新してメッセージを送信する必要がある場合、まずユーザープロファイルが完全に更新されるのを待ってから、エンドポイントを使用してメッセージを送信してください。
スケジュールされたメッセージAPIリクエストを送信する場合、これらのリクエストは別々にする必要があり、スケジュールされたAPIリクエストを送信する前にユーザーを作成しておく必要があります。
キーデータをトリガーに含める
複数のエンドポイントを使用する代わりに、campaign/trigger/sendエンドポイントを使用して、ユーザー属性とトリガープロパティを単一のAPIコールに含めることができます。
これらのオブジェクトがトリガーに含まれている場合、メッセージがトリガーされる前に属性が先に処理されるため、潜在的な競合が排除されます。なお、トリガープロパティはユーザープロファイルを更新するものではなく、メッセージのコンテキスト内でのみ使用されます。
POST: ユーザー追跡（同期）エンドポイントを使用する
/users/track/sync/エンドポイントを使用して、カスタムイベントと購入を記録し、ユーザープロファイル属性を同期的に更新します。このエンドポイントを使用して、ユーザープロファイルを同時に単一のコールで更新することで、潜在的な競合を防ぐことができます。
This endpointは現在ベータ版です。ベータ版への参加にご興味がある場合は、Braze account マネージャーまでお問い合わせください。
シナリオ3：アクションベースのトリガーとオーディエンスフィルターの一致
もう1つの一般的な競合は、アクションベースのキャンペーンまたはキャンバスを、オーディエンスフィルターと同じトリガー（属性の変更やカスタムイベントの実行など）で設定した場合に発生する可能性があります。ユーザーがトリガーイベントを実行した時点でオーディエンスに含まれていない場合、そのユーザーはキャンペーンを受信したり、キャンバスにエントリしたりすることはありません。
ベストプラクティス
遅延後にオーディエンスを確認する
トリガー基準を含むオーディエンスフィルターの使用を避けるため、配信前にオーディエンスを確認することをお勧めします。たとえば、キャンバスのメッセージステップで配信バリデーションを使用して、メッセージ送信時にオーディエンスが配信基準を満たしているかどうかを追加で確認できます。また、キャンバスの離脱条件を活用して、ユーザージャーニー中の任意の時点で基準を満たしたユーザーを離脱させることもできます。
キャンペーンの場合、離脱イベントを使用して、トリガーイベント付きのキャンペーンが遅延中に離脱イベントを実行したユーザーへのメッセージを中止できるようにすることができます。
トリガーイベントに対して一意のフィルターを使用する
フィルターを設定する際、「念のため」冗長なフィルターを追加したくなることがあるかもしれません。しかし、この冗長性はさらなる問題につながる可能性があります。代わりに、可能な限りトリガーを含むフィルターの使用を避けてください。これが競合を回避する最も安全な方法です。
たとえば、キャンペーンのトリガーが「購入した」で、オーディエンスフィルターが「いずれかの購入をした」の場合、この冗長性が競合を引き起こす可能性があります。
トリガーイベントが更新済みであることを前提としたオーディエンスフィルターを避ける
このベストプラクティスは、トリガーイベントとの冗長なフィルターを避けることと同様です。通常、トリガーイベントがユーザープロファイルに更新されたことを前提とするフィルターは失敗します。
Liquid の中止を使用する（属性のみ）
キャンペーンおよびキャンバスステップでは、Liquidの中止を使用して、エントリスケジュールでトリガー属性を含むオーディエンスフィルターの使用を避けてください。たとえば、配列属性「お気に入りの色」があり、属性の配列を任意の値で更新したユーザーをターゲットにし、かつ更新完了後に配列に「青」がある場合を想定します。この例でオーディエンスフィルターを使用すると、競合が発生し、初めて「青」を配列に追加するユーザーを見逃してしまいます。
この場合、キャンペーンでトリガー遅延を実装するか、キャンバスで遅延ステップを使用してユーザープロファイルが一定時間更新されるのを待ち、次のLiquid中止ロジックを使用できます。
{%assign colors={{custom_attribute.$(Favorite Color)|split:”,”}}%}
{%unless colors contains ‘Blue’%}
{%abort_message(Blue not present)%}
{%endunless%}
ユーザーデータの管理方法を確認する
キャンバスのエントリ評価中に競合が発生した場合、ユーザーが本来エントリすべきでないキャンバスにエントリしてしまう可能性があります。たとえば、ユーザーのプロファイルがオーディエンスに含まれるように設定されており、キャンバスがユーザーをキューに入れた後に、オーディエンスの対象外となるよう更新される場合があります。
ユーザーが同じ秒内にキャンバスのエントリイベントを複数回トリガーした場合、Brazeはその秒に対して1回のエントリのみを許可します（再エントリが有効な場合でも）。これにより重複エントリが防止されるため、キャンバスの合計エントリ数は合計トリガーイベント数よりも少なくなる場合があります。
ユーザーデータがどのように管理・更新されているか、特にSDK、API、バッチAPI、その他の方法によって特定の属性がいつ、どのように更新されるかを確認することをお勧めします。これにより、ユーザーがキャンペーンまたはキャンバスにエントリした理由と、ユーザープロファイルが更新されたタイミングを特定し明確にすることができます。
シナリオ4:「ステップとのインタラクション」トリガーの使用
キャンバスにおいて、メッセージステップの直後にアクションパスステップが「ステップとのインタラクション」トリガーを使用して続く場合、競合が発生する可能性があります。ユーザーはメッセージが配信されるとすぐにインタラクションできるため、アクションパスステップに正式にエントリする前に、追跡対象のアクションを完了してしまう可能性があります。
この場合、アクションパスステップはステップへのエントリ後に発生したイベントのみを評価するため、そのインタラクションを登録しません。その結果、ユーザーが意図しないパスに誘導される可能性があります。
キャンバスがメッセージステップでプッシュ通知を送信し、その後にアクションパスステップでユーザーがそのプッシュ通知を開封したかどうかを確認するとします。ユーザーがプッシュ通知を受信してすぐに（アクションパスステップにエントリする前に）開封した場合、開封イベントがキャプチャされない可能性があります。その結果、ユーザーは実際にはメッセージに対してエンゲージメントしたにもかかわらず、「開封しなかった」パスに誤って誘導される可能性があります。
ベストプラクティス
カスタムイベントを使用してエンゲージメントを追跡する
ユーザーのインタラクションが迅速に発生することが予想される場合、メッセージステップの直後に「ステップとのインタラクション」に依存することは避けてください。代わりに、カスタムイベント（たとえば、インタラクション後にアプリやWebサイトからトリガーされるもの）を使用してエンゲージメントを追跡し、そのイベントを下流のステップで評価してください。これにより、ユーザーがステップにエントリした後にイベントが記録されることが保証されます。
インタラクションに依存するBranchを避ける
即時のインタラクションが捕捉されなくてもユーザー体験が損なわれないようにキャンバスを設計してください。たとえば、次のステップでインタラクションがキャプチャされたかどうかのみに依存する重要な分岐判断を避けるか、ユーザーのルートを修正できるフォローアップロジックを追加してください。