コネクテッドコンテンツのリトライロジックを使用する
このページでは、コネクテッドコンテンツの呼び出しにリトライを追加する方法について説明します。
再試行の仕組み
Connected Content は API からのデータ受信に依存しているため、Braze が呼び出しを行う際に API が一時的に利用できない場合があります。このような場合、Braze は指数バックオフを使用してリクエストを再試行するロジックをサポートしています。
Connected Content の :retry は、アプリ内メッセージやバナーでは使用できません。
キャンバスステップでの再試行動作
キャンバス内の Connected Content 呼び出しは、呼び出しに :retry が含まれている場合にのみ再試行されます。動作はステップの種類によって異なります。
- メッセージステップ:
:retryを含む Connected Content は、引き続きメッセージングパイプラインを使用します。Braze が呼び出しを最大 5 回再試行する間、受信者は送信キューで待機します。すべての再試行が失敗した場合、メッセージは中止され、ユーザーは次のステップに進みます。詳細については、API 呼び出しが失敗し、再試行が有効になっている場合を参照してください。 - コンテキストステップとユーザー更新ステップ: Braze はステップレベルで Connected Content の呼び出しを再試行します (最大 5 回)。すべての再試行が失敗した場合、ユーザーはキャンバスから退出します。
コンテキストステップとユーザー更新ステップでは、プロモーションコードの取得失敗や予期しないステップエラーなど、特定の再試行可能なステップエラーが発生すると、Braze がユーザーをキャンバスから退出させる前に、指数バックオフによる追加のステップレベルの再試行 (約 13 回) がトリガーされることがあります。
詳細については、再試行動作を参照してください。
再試行ロジックの使用
再試行ロジックを使用するには、次のコードスニペットのように、Connected Content 呼び出しに :retry タグを追加します。
{% connected_content https://yourwebsite.com/api/endpoint :retry %}
{% connected_content https://www.braze.com :save my_content :basic_auth auth_name :retry %}
Connected Content 呼び出しに :retry タグが含まれている場合、Braze は最大 5 回まで呼び出しを再試行します。
プレビュー時の動作
再試行ロジックが適用されるのは、ライブ送信 (テスト送信を含む) のみです。メッセージのプレビューやユーザーパスのプレビューには適用されません。:retry を含む Connected Content 呼び出しが失敗した場合、Braze は呼び出しを再試行しません。代わりに、次のようになります。
- メッセージのプレビュー中は、コンテンツがレンダリングされる代わりに、「This message would not have been shown because retry functionality was triggered」と表示されることがあります。
- ユーザーパスのプレビュー中は、メッセージステップに「Message aborted due to connected content retry failure」と表示されることがあります。
これは想定どおりの動作であり、Braze 内の問題を示すものではありません。
再試行の結果
再試行が成功した場合
再試行が成功すると、メッセージが送信され、そのメッセージに対してそれ以上の再試行は行われません。
API 呼び出しが失敗し、再試行が有効になっている場合
API 呼び出しが失敗し、この機能が有効になっている場合、Braze は再送信ごとに設定したレート制限を守りながら呼び出しを再試行します。Braze は失敗したメッセージをキューの最後に移動し、必要に応じて、メッセージの送信にかかる合計時間に分を追加します。
Connected Content 呼び出しで 5 回を超えてエラーが発生した場合、メッセージ中止タグがトリガーされた場合と同様に、メッセージは中止されます。
コネクテッドコンテンツの呼び出しにおける中止とリトライのロジック
コネクテッドコンテンツの呼び出しで、リトライロジックと同じ条件に対して中止ロジックを使用している場合、中止ロジックが優先されます。これにより、リトライが試行されなくなります。リトライロジックは、ステータスコードが失敗の場合、中止する前にすでに呼び出しを再送信しています。どちらも同じステータスコードの動作をターゲットにしているため、中止ロジックを削除しても、すべてのリトライが失敗した場合には呼び出しは中止されます。