コンテキスト

コンテキストステップを使用すると、ユーザーがキャンバス内を移動するときに、ユーザーの変数を1つ以上作成、更新できます。例えば季節割引を管理するキャンバスでは、コンテキスト変数を使用して、ユーザーがキャンバスにエントリするたびに異なる割引コードを保存できます。

仕組み

コンテキストステップを使用すると、特定のキャンバスを経由したユーザーの移動中に一時データを作成して使用できます。このデータは、そのCanvas ジャーニー内にのみ存在し、異なるCanvase 間やセッション外では保持されません。

データ型、使用法、ベストプラクティスなどのコンテキスト変数の完全な参照については、コンテキスト変数参照を参照してください。

コンテキストステップ内では、最大10 個のコンテキスト変数を定義または更新できます。これらの変数を使用して、遅延をパーソナライズしたり、s ダイナミックなをアライアンスでSegment ユーザーしたり、キャンバス全体のメッセージングを豊かにしたりできます。たとえば、ユーザーのスケジュールされた飛行時間のコンテキスト変数を作成し、それを使用してパーソナライズされた遅延を設定し、リマインダーを送信できます。

コンテキスト変数は、次の2 つの方法で設定できます。

• キャンバスエントリで:イベントまたはAPI トリガーからのデータは、コンテキスト変数に自動的に入力できます。
• コンテキストステップで:コンテキストステップを追加して、コンテキスト変数を手動で定義または更新します。

各コンテキスト変数には、名前、データ型、および値(リキッドまたはカスタマイズの追加ツールを使用して設定)が必要です。定義すると、{{context.${flight_time}}} のように、Liquid を使用してキャンバス全体のコンテキスト変数を参照できます。

それぞれのキャンバスエントリは、最新のエントリデータとキャンバス設定に基づいてコンテキスト変数を再定義し、ユーザーが独自のコンテキストで複数のアクティブジャーニーを持つことを可能にします。たとえば、ある顧客に2 つの次のフライトがある場合、2 つの別々のジャーニーステートが同時に実行され、それぞれに、出発時刻や送信先などの独自のフライト固有のコンテキスト変数が含まれます。これにより、ニューヨーク行きの午後2時の飛行に関するパーソナライズされたのリマインダーを送る一方で、明日のロス・アンヘレス行きの午前8時の飛行に関する別々の更新を送ることができ、各々のメッセージは、具体的な予約に関連したものであり続けることができます。

ユーザー処理とバッチ処理

コンテキストステップs はユーザーをバッチで処理し、パフォーマンスを最適化します。ユーザーがコンテキストステップを入力すると、Braze は1000 ユーザーのバッチでデフォルトで処理します。これらのバッチは並行して処理されますが、各バッチ内ではユーザーが順番に処理されます。

つまり、

• 並列一括処理:1000個のユーザーが同時に複数回処理され、大きなオーディエンスを効率的に処理できます。
• バッチ内の順次処理:それぞれのバッチ内で、ユーザーsが次々に処理されます。コンテキストステップにConnected Content コールが含まれている場合、それぞれのユーザーのConnected Content リクエストが完了してから、そのバッチの次回のユーザーが処理されます。
• 独立したバッチ進行:それぞれのロットは独立系的に進行する。バッチが処理を完了すると、他のバッチがまだ処理中であっても、それらのユーザーは即座に次のステップに進みます。これは、異なったバッチからのユーザーが、異なった時点で、次のステップsに到達することを意味する。

例:3500 ユーザーが、1 ユーザーあたり650 ミリ秒を要する接続内容を持つコンテキストステップを入力する場合:

• Braze では、最大4 バッチのユーザー(612、802、1,000、880、および120 ユーザー s)のアプリが作成されます。
• 1回のバッチはユーザーを順番に処理するので、1000ユーザー秒のバッチは、ほぼ11分(1000×650ms)アプリを要します。
• バッチはさまざまな時間に完了するため、ユーザーはバッチの終了時に次回のステップにトリクルします。
• 最初のユーザーs は、バッチサイズと接続コンテンツのレスポンス時間に応じて、最後のユーザーs の数分前に次のステップに到達することがあります。

Connected Content がないと、待機する外部API 呼び出しがないため、Context ステップ s は非常に高速に処理されます。

考慮事項

• コンテキストステップごとに最大10 個のコンテキスト変数を定義できます。
• 各変数には一意の名前(文字、数字、アンダースコアのみ、最大100 文字) が必要です。
• ステップ内のすべての変数の総サイズは50KB を超えることはできません。
• API トリガーを使用して渡された変数は、コンテキストステップs で作成されたものと同じ名前空間を共有します。コンテキストステップで変数を再定義すると、API 値が上書きされます。

詳細および高度な使用方法については、コンテキスト変数参照を参照してください。

コンテキストステップの作成

ステップ1:ステップを追加する

キャンバスにステップを追加し、サイドバーからコンポーネントをドラッグアンドドロップするか、 plus ボタンを選択し、Context を選択します。

ステップ2: 変数の定義

コンテキスト変数を定義するには

1. コンテキスト変数にname を指定します。
2. データ型を選択します。
3. Liquid 式を手動で記述するか、Add Personalization を使用して既存の属性からLiquid スニペットを作成します。
4. コンテキスト変数の値を確認するには、プレビューを選択します。
5. (オプション) 追加の変数を追加するには、コンテキスト変数を追加 を選択し、ステップs 1～4 を繰り返します。
6. [完了] を選択します。

これで、[パーソナライズを追加する] を選択して、メッセージステップやユーザー更新ステップなど Liquid を使用する任意の場所で、コンテキスト変数を使用できます。フルウォークスルーについては、コンテキスト変数参照を参照してください。

コンテキスト変数フィルターs

フィルター s は、Audience Paths およびDecision Split ステップ s でコンテキスト変数を使用して作成できます。フィルター設定、比較ロジック、高度な例については、コンテキスト変数リファレンスを参照してください。

ユーザー パスのプレビュー

ユーザー パスs でテストと[ プレビューを実行して、メッセージが正しいオーディエンスに送信され、コンテキスト変数が期待される結果に評価されることを確認することをお勧めします。

無効なコンテキスト変数を作成する一般的なシナリオを必ず守ってください。ユーザー パスをプレビューするときに、コンテキスト変数、およびユーザーs と任意のコンテキスト変数を照合するオーディエンス、ディシジョン、またはアクションパス ステップの比較を使用して、パーソナライズされた遅延ステップs の結果を表示できます。

コンテキスト変数が有効な場合は、キャンバス全体で変数を参照できます。ただし、コンテキスト変数が正しく作成されていない場合、キャンバス内の将来のステップも正しく実行されません。たとえば、コンテキストステップを作成して、ユーザーにアプリの軟膏日時を割り当て、アプリの軟膏日時の値を過去の日に設定した場合、メッセージステップのリマインダーメールは送信されません。

接続されたコンテンツ文字列のJSON への変換

コンテキストステップでConnected Content call を作成すると、呼び出しから返されたJSON が整合性とエラー防御のための文字列データ型として評価されます。この文字列をJSON に変換する場合は、as_json_string を使用して変換します。以下に例を示します。

1
2
{% connected_content http://example.com :save product %}
{{ product | as_json_string }}

タイムゾーン整合性の標準化

タイムスタンプタイプを使用するほとんどのイベントプロパティはキャンバスですでにUTCになっていますが、いくつかの例外があります。キャンバスコンテキストの追加により、アクション ベースのキャンバスのすべてのデフォルトタイムスタンプイベントプロパティはUTC になります。この変更は、キャンバスステップやメッセージを編集する際に、より予測可能で一貫性のあるエクスペリエンスを確保するための、より幅広い作業の一部です。この変更は、特定のキャンバスがコンテキストステップを使用しているかどうかにかかわらず、すべてのアクションベースのキャンバスに影響を与えることに注意してください。

トラブルシューティング

無効なコンテキスト変数

以下の場合、コンテキスト変数は無効と見なされます。

• 埋め込み接続コンテンツへの呼び出しが失敗します。
• 実行時のLiquid 式は、データ型と一致しない値、または空(NULL) の値を返します。

たとえば、コンテキスト変数のデータ型がNumber であるが、Liquid 式が文字列を返す場合、これは無効です。

このような状況では次のようになります。

• ユーザーが次回のステップに進みます。
• キャンバスステップ 分析は、これを_更新されていません_と数えます。

トラブルシューティングの際には、_未更新_指標を監視して、コンテキスト変数が正しく更新されることを確認します。コンテキスト変数が無効な場合、ユーザーはコンテキストステップを過ぎてもキャンバスに留まることができますが、後のステップには適さない場合があります。

各データ型の設定例については、データ型を参照してください。

Connected Contentでの送信遅延

コンテキストステップで接続コンテンツが失敗した場合、成功したユーザーはすぐに次回のステップに進み、失敗したユーザーは別々に再試行されます。つまり、バッチは、すべてのユーザーが成功するのを待たずに、コネクテッドコンテンツの呼び出しが完了すると、進行中のユーザーが前進します。

再試行動作:コンテキストステップs(およびすべてのキャンバスステップs)は、標準の接続コンテンツ再試行ビヘイビアではなく、キャンバス固有の再試行メカニズムを使用します。接続内容の呼び出しに失敗した場合、Braze は、指数バックオフで最大13 回ステップ アプリを再試行します。すべての再試行が失敗すると、ユーザーはキャンバスを終了します。

Note:標準の接続コンテンツで使用される:retry タグは、Canvas ステップ s 内で行われる接続コンテンツコールにはアプリしません。キャンバスステップには、キャンバスワークフロー用に最適化された独自の再試行ロジックがあります。

処理時間:コンテキストステップを介してすべてのユーザーs を処理するのにかかる時間は、次の条件によって異なります。

• ステップに入るユーザーの個数
• 接続コンテンツが使用されているかどうか(およびその応答時間)
• ロットサイズ(1ロットにつきデフォルト1000ユーザー)

接続コンテンツエンドポイントにレート制限sがある場合は、コンテキストステップsが各バッチ内でレート制限を自然に尊重するのに役立つユーザーを順番に処理することを考慮してください。ただし、複数のバッチが並行して処理されるため、エンドポイントが複数のバッチからの同時リクエストを処理できるようにします。

よくある質問

キャンバスコンテキストが一般的に使用可能になると、どのような変更が行われますか?

キャンバスコンテキストが一般的に使用可能になると、次の情報がアプリされます。

• アクション ベースのキャンバスの datetime type が トリガーイベントプロパティ のすべてのタイムスタンプは、UTC にあります。
• この変更は、特定のキャンバスがコンテキストステップを使用しているかどうかに関係なく、すべてのアクションベースのキャンバスに影響します。

この変更の理由は何ですか?

この変更は、キャンバスステップやメッセージを編集するときに、より予測可能で一貫性のあるエクスペリエンスを作成するための、より幅広い作業の一部です。

この変更はいつ有効になりますか?

• キャンバスコンテキストの早期アクセスに参加している場合、この変更はすでにアプリ嘘になっています。
• キャンバスコンテキストの初期アクセスに参加していない場合、この変更アプリは、初期アクセスに参加したとき、またはキャンバスコンテキストが一般的に使用可能になったときに表示されます。

API-トリガーキャンバスまたはスケジュールされたキャンバスは、この変更の影響を受けますか?

いいえ。

この変更は、キャンバスのエントリプロパティーに影響しますか?

はい。これは、canvas_entry_propertyがアクションベースのキャンバスで使用されており、プロパティの種類がtimeの場合にcanvas_entry_propertiesに影響します。どのような状況でも、必要なタイムゾーンで表されるタイムスタンプには、リキッドtime_zone フィルターを使用することをお勧めします。

これを行う方法の例を次に示します。

新しいタイムスタンプの振る舞いが私のメッセージにどのように影響するかの実用的な例は何ですか?

たとえば、メッセージステップに次の内容を含むアクションベースのキャンバスがあるとします。

1
Your appointment is scheduled for {{canvas_entry_properties.${appointment_time} | date: "%Y-%m-%d %l:%M %p"}}, we'll see you then!

これにより、次のメッセージが表示されます。

1
Your appointment is scheduled for 2025-08-05 4:15pm, we’ll see you then!

Liquidを使用してタイムゾーンが指定されていないため、ここでのタイムスタンプはUTCです。

タイムゾーンを明確に指定するには、以下のようにリキッドtime_zone フィルターs を使用します。

1
Your appointment is scheduled for {{canvas_entry_properties.${appointment_time} | time_zone: "America/Los_Angeles" | date: "%Y-%m-%d %l:%M %p"}}, we'll see you then!

これにより、次のメッセージが表示されます。

1
Your appointment is scheduled for 2025-08-05 8:15am, we'll see you then!

America/Los アンヘレスタイムゾーンはLiquid を使用して指定されているため、ここでのタイムスタンプはPST です。

優先タイムゾーンは、イベントプロパティペイ読み込むで送信し、リキッドロジックで使用することもできます。

1
2
3
4
{
  "appointment_time": "2025-08-05T08:15:30:250-0800"
  "user_timezone": "America/Los_Angeles"
}

コンテキスト変数は、Canvas エントリプロパティとはどのように異なるのですか?

コンテキストステップの初期アクセスに参加している場合は、キャンバスエントリのプロパティがキャンバスのコンテキスト変数として含まれるようになりました。つまり、Liquid スニペットでコンテキスト変数を使用する場合と同様に、Braze API を使用してキャンバスエントリのプロパティを送信し、他のステップでこれらのプロパティを参照できます。

変数は、1つのコンテキストステップ内で相互に参照できますか?

はい。コンテキストステップ内のすべての変数はシーケンスで評価されます。つまり、以下のコンテキスト変数を設定できます。

これは、複数のコンテキストステップにも適用されます。例えば次のシーケンスを考えてみます。

1. 最初のコンテキストステップでは、JobInfo という変数を作成して値 job_title を設定します。
2. メッセージステップは {{context.${JobInfo}}} を参照し、job_title をユーザーに表示します。
3. その後、コンテキストステップによってコンテキスト変数が更新され、JobInfo の値がjob_description に変更されます。
4. JobInfo を参照する以降のすべてのステップは、更新d 値job_description を使用するようになりました。

コンテキスト変数は、キャンバス全体で最新の値を使用します。更新を行うたびに、その変数を参照する後続のすべてのステップに影響します。