コンテキスト

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

仕組み

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

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

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

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

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

各コンテキスト変数には、名前、データ型、値（Liquidまたは「パーソナライゼーションを追加」ツールで設定）が必要だ。定義されたコンテキスト変数は、キャンバス全体で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: ステップを追加する

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

ステップ2: 変数の定義

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

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

これで、[パーソナライズを追加する] を選択して、メッセージステップやユーザー更新ステップなど Liquid を使用する任意の場所で、コンテキスト変数を使用できます。完全な手順については、コンテキスト変数リファレンスを参照せよ。

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

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

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

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

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

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

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

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

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

トラブルシューティング

無効なコンテキスト変数

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

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

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

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

• ユーザーは次のステップに進む。
• Canvasステップ分析では、これを_「更新なし」_としてカウントする。

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

各データ型の設定例については、データ型を参照せよ。

コネクテッドコンテンツの送信遅延

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

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

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

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

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

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

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

よくある質問

キャンバス Contextが一般提供開始されてから、何が変わったのか？

キャンバス Contextが一般提供されたため、以下の詳細が適用される：

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

この変更の理由は何だ？

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

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

いいえ。

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

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

タイムゾーンを明確に指定するには、次のようにLiquidtime_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!

アメリカ/ロサンゼルス時間帯がLiquidで指定されているため、こちらのタイムスタンプはPST（太平洋標準時）である。

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

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された値job_descriptionを使用する。

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