コンテキスト

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

仕組み

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

コンテキスト変数は、その特定のキャンバスジャーニーにのみ存在します。ユーザーのプロファイルを恒久的に変更することはなく、他のキャンバスにも表示されません。これにより、特定のキャンペーンやワークフローにのみ関連する一時的な情報に最適です。

コンテキストステップ内では、最大10個のコンテキスト変数を定義または更新できます。これらの変数を使って、遅延をパーソナライズしたり、ユーザーをダイナミックにセグメント分けしたり、キャンバス全体でメッセージングを充実させたりできます。例えば、ユーザーのスケジュールされたフライト時刻用のコンテキスト変数を作成し、それを使ってパーソナライズされた遅延を設定し、リマインダーを送信できます。

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

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

各コンテキスト変数には、名前、データタイプ、値（LiquidまたはAdd Personalizationツールで設定）が必要です。定義されたコンテキスト変数は、キャンバス全体でLiquidを使用して参照できます（例：{{context.${flight_time}}}）。コンテキスト変数名フィールドでは、コンテキスト変数名を入力するか、ステップエディターのドロップダウンから選択することもできます。詳細については、コンテキスト変数リファレンスを参照してください。

各キャンバスエントリは、最新のエントリデータとキャンバス設定に基づいてコンテキスト変数を再定義するため、ユーザーはそれぞれ独自のコンテキストを持つ複数のアクティブなジャーニーを同時に実行できます。例えば、顧客が2つのフライトを予約している場合、2つの別々のジャーニー状態が同時に進行します。それぞれに、出発時刻や目的地といったフライト固有のコンテキスト変数が存在します。これにより、午後2時のニューヨーク行きのフライトについてはパーソナライズされたリマインダーを送信しつつ、明日の午前8時のロサンゼルス行きフライトについては別の更新情報を送信できます。こうして各メッセージが特定の予約に関連した内容となります。

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

コンテキストステップは、パフォーマンスを最適化するためにユーザーをバッチ処理します。ユーザーがコンテキストステップに入ると、Brazeはデフォルトで1,000ユーザー単位のバッチで処理を行います。これらのバッチは並列処理されますが、各バッチ内ではユーザーは順次処理されます。

これはつまり：

例：3,500人のユーザーが、ユーザーあたり650ミリ秒かかるコネクテッドコンテンツを含むコンテキストステップに入った場合：

• Brazeは4つのユーザーバッチを作成します（この例では1,000、1,000、1,000、500ユーザー）。
• 各バッチはユーザーを順次処理するため、1,000人のユーザーのバッチには約10.8分（650秒；1,000 × 650ミリ秒）かかります。
• バッチはそれぞれ異なる時間に完了するため、ユーザーは自分のバッチ処理が終わるにつれて、次のステップに少しずつ移行していきます。
• 最初のユーザーは、バッチサイズやコネクテッドコンテンツの応答時間によっては、最後のユーザーより数分早く次のステップに進むことがあります。

コネクテッドコンテンツがない場合、コンテキストステップの処理ははるかに速くなります。待機が必要な外部API呼び出しが存在しないためです。

考慮事項

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

詳細と高度な使用方法については、コンテキスト変数リファレンスを参照してください。

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

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

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

ステップ 2: 変数を定義する

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

1. コンテキスト変数に名前を付けます。
2. データタイプを選択します。
3. Liquid式を手動で記述するか、Add Personalizationを使用して既存の属性からLiquidスニペットを作成します。
4. コンテキスト変数の値を確認するには、プレビューを選択します。
5. （オプション）追加の変数を追加するには、Add Context variableを選択し、ステップ1～4を繰り返します。
6. 完了したら、Doneを選択します。

これで、Add Personalizationを選択して、メッセージステップやユーザー更新ステップなどLiquidを使用する任意の場所で、コンテキスト変数を使用できます。コンテキスト変数名フィールドでは、コンテキスト変数名を入力するか、ステップエディターのドロップダウンから選択することもできます。完全な手順については、コンテキスト変数リファレンスを参照してください。

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

オーディエンスパスと条件分岐ステップでは、コンテキスト変数を使ってフィルターを作成できます。フィルター設定、比較ロジック、および高度な例については、コンテキスト変数リファレンスを参照してください。

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

ユーザーパスをプレビューしてテストし、メッセージが適切なオーディエンスに送信され、コンテキスト変数が期待通りの結果に評価されることを確認することを推奨します。

無効なコンテキスト変数を生成する一般的なシナリオを必ず確認してください。ユーザーパスのプレビュー時には、コンテキスト変数を使用したパーソナライズされた遅延ステップの結果や、ユーザーをコンテキスト変数に照合するオーディエンスステップや条件分岐ステップの比較結果を確認できます。

コンテキスト変数が有効な場合は、キャンバス全体で変数を参照できます。ただし、コンテキスト変数が正しく作成されていない場合、キャンバスの後続のステップも正しく動作しません。例えば、ユーザーに予約時間を割り当てるコンテキストステップを作成し、その予約時間の値を過去の日付に設定した場合、メッセージステップのリマインダーメールは送信されません。

コネクテッドコンテンツ文字列のJSONへの変換

コンテキストステップでコネクテッドコンテンツ呼び出しを行う場合、呼び出しから返されるJSONは一貫性とエラー防止のため、文字列データタイプとして評価されます。この文字列をJSONに変換する場合は、as_json_stringを使用して変換します。例えば：

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

トラブルシューティング

無効なコンテキスト変数

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

• 埋め込みコネクテッドコンテンツへの呼び出しが失敗した場合。
• 実行時のLiquid式がデータタイプと一致しない値、または空（null）の値を返した場合。

例えば、コンテキスト変数のデータタイプが数値であるにもかかわらず、Liquid式が文字列を返す場合、これは無効です。

このような状況では：

• ユーザーは次のステップに進みます。
• キャンバスステップの分析では、これを_未更新_としてカウントします。

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

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

コネクテッドコンテンツによる送信遅延

バッチ内の全ユーザーは、いずれかのユーザーが先に進む前に処理されます。バッチ処理が完了すると、成功したユーザーは次のステップに進み、失敗したユーザーは別途再試行されます。成功したユーザーは再試行が成功するのを待たずに先に進みます。

再試行の動作：コンテキストステップ（およびすべてのキャンバスステップ）は、標準のコネクテッドコンテンツの再試行動作ではなく、キャンバス固有の再試行メカニズムを使用します。コネクテッドコンテンツの呼び出しが失敗した場合、Brazeはそのステップを指数関数的バックオフを用いて約13回再試行します。すべての再試行が失敗した場合、ユーザーはキャンバスを終了します。

処理時間：コンテキストステップで全ユーザーを処理するのにかかる時間は、以下の要因に依存します：

• ステップに入るユーザーの数
• コネクテッドコンテンツが使用されるかどうか（およびその応答時間）
• バッチサイズ（デフォルトは1バッチあたり1,000ユーザー）

コネクテッドコンテンツのエンドポイントにレート制限がある場合、コンテキストステップは各バッチ内でユーザーを順次処理するため、自然にレート制限を遵守できることを考慮してください。ただし、複数のバッチが並列で処理されるため、エンドポイントが複数のバッチからの同時リクエストを処理できることを確認してください。

タイムゾーンの一貫性に関する標準化

キャンバスでは、タイムスタンプ型を使用するイベントプロパティの大半は既にUTCで管理されていますが、例外も存在します。Canvas Contextの追加により、アクションベースのキャンバスにおけるデフォルトのタイムスタンプイベントプロパティはすべてUTCで設定されます。この変更は、キャンバスのステップやメッセージを編集する際の操作性をより予測可能で一貫性のあるものにするための、より広範な取り組みの一環です。この変更は、特定のキャンバスがコンテキストステップを使用しているかどうかに関わらず、すべてのアクションベースのキャンバスに影響することに注意してください。

よくある質問

Canvas Contextが一般提供開始されてから、何が変わりましたか？

Canvas Contextが一般提供されたため、以下の詳細が適用されます：

• アクションベースのキャンバスにおけるトリガーイベントプロパティから取得されるdatetime型のタイムスタンプはすべてUTCです。
• この変更は、特定のキャンバスがコンテキストステップを使用しているかどうかに関わらず、すべてのアクションベースのキャンバスに影響します。

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

この変更は、キャンバスのステップとメッセージを編集する際の体験をより予測可能で一貫性のあるものにするための、より広範な取り組みの一環です。

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

いいえ。

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

はい、これはアクションベースのキャンバスでcanvas_entry_propertyが使用されており、かつプロパティタイプがtimeの場合にcanvas_entry_propertiesに影響します。いかなる状況においても、タイムスタンプを希望のタイムゾーンで表現するには、Liquid 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です。

タイムゾーンを明確に指定するには、次のようにLiquid time_zoneフィルターを使用できます：

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 AngelesタイムゾーンがLiquidで指定されているため、このタイムスタンプはPST（太平洋標準時）です。

優先タイムゾーンはイベントプロパティのペイロードで送信し、Liquidロジックで使用することもできます：

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

コンテキスト変数は、キャンバスのエントリプロパティとはどのように異なりますか？

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

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

はい。コンテキストステップ内のすべての変数は順番に評価されます。つまり、次のようなコンテキスト変数を設定できます：

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

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

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