コンテンツにスキップ

コンテキスト

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

仕組み

キャンバスの最初のステップとしてのコンテキストステップ。

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

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

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

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

  • キャンバスエントリ時:カスタムイベントまたはAPIトリガーからのプロパティが、コンテキスト変数として自動的に入力されます。
  • コンテキストステップ内:コンテキストステップを追加して、コンテキスト変数を手動で定義または更新します。

各コンテキスト変数には、名前、データタイプ、および値(Liquidまたは「パーソナライゼーションを追加」ツールを使用して設定)が必要です。定義すると、{{context.${flight_time}}}のようなLiquidを使用して、キャンバス全体でコンテキスト変数を参照できます。コンテキスト変数名フィールドでは、コンテキスト変数名を入力するか、ステップエディターのドロップダウンから選択することもできます。詳細については、コンテキスト変数リファレンスを参照してください。

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

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

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

つまり、次のようになります。

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

  • Brazeは4つのバッチ(この例では1,000、1,000、1,000、500ユーザー)を作成します。
  • 各バッチはユーザーを順次処理するため、1,000ユーザーのバッチには約10.8分(650秒、1,000 × 650ミリ秒)かかります。
  • バッチの完了タイミングはそれぞれ異なるため、バッチが完了するにつれてユーザーは順次次のステップに進みます。
  • バッチサイズやConnected Contentの応答時間に応じて、最初のユーザーは最後のユーザーよりも数分早く次のステップに到達する場合があります。

Connected Contentがない場合、外部APIコールを待つ必要がないため、コンテキストステップの処理は大幅に高速になります。

注意事項

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

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

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

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

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

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

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

  1. コンテキスト変数に名前を付けます。
  2. データ型を選択します。
  3. Liquid式を手動で記述するか、パーソナライゼーションを追加を使用して既存の属性からLiquidスニペットを作成します。
  4. プレビューを選択して、コンテキスト変数の値を確認します。
  5. (任意)変数を追加するには、コンテキスト変数を追加を選択し、ステップ1〜4を繰り返します。
  6. 完了したら、完了を選択します。

これで、メッセージやユーザー更新ステップなど、Liquidを使用できる場所であればどこでも、パーソナライゼーションを追加を選択してコンテキスト変数を使用できます。コンテキスト変数名フィールドに、コンテキスト変数名を入力するか、ステップエディターのドロップダウンから選択することもできます。詳しいウォークスルーについては、コンテキスト変数リファレンスを参照してください。

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

オーディエンスパスや条件分岐ステップで、コンテキスト変数を使用してフィルターを作成できます。

エージェントステップのレスポンスに基づいてユーザーをルーティングするには、オーディエンスパスまたは条件分岐ステップの前にエージェントステップを追加します。エージェントステップはその出力をキャンバスコンテキストに保存するため、それらの分岐ステップでコンテキスト変数フィルターを使用して評価できます。

エージェントがオブジェクトを返し、ネストされたプロパティでフィルタリングしたい場合は、コンテキスト変数名フィールドに、トップレベルの変数名だけでなく、ドット表記を使用してパスを入力します(例:personaがintent_agentの下にネストされている場合はintent_agent.persona)。

フィルターの設定、比較ロジック、および高度な例については、コンテキスト変数リファレンスを参照してください。

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

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

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

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

Connected Content文字列のJSONへの変換

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

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

トラブルシューティング

無効なコンテキスト変数

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

  • 埋め込まれたConnected Contentの呼び出しが失敗した場合。
  • Liquidエクスプレッションがランタイムでデータ型と一致しない値を返した場合、または空(null)の場合。
  • Liquidエクスプレッションが{% abort_message() %}を呼び出した場合。

例えば、コンテキスト変数のデータ型が数値であるにもかかわらず、Liquidエクスプレッションが文字列を返した場合、無効となります。

このような場合:

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

トラブルシューティングの際は、「未更新」メトリクスを監視して、コンテキスト変数が正しく更新されているか確認してください。コンテキスト変数が無効な場合、ユーザーはコンテキストステップを通過してキャンバス内を進み続けることができますが、後続のステップの条件を満たさない可能性があります。

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

コンテキスト変数は、abort_messageを使用して意図的にスキップすることもできます。コンテキスト変数でのabort_messageの使用を参照してください。

コンテキスト変数でのabort_messageの使用

abort_message Liquidタグをコンテキスト変数の値に使用することで、一部のユーザーに対してその変数をスキップできます。コンテキストステップにおいて、abort_messageはその変数にのみ影響します。ステップを停止させることも、ユーザーをキャンバスから退出させることもありません。

コンテキスト変数のLiquidがユーザーに対してabort_messageを呼び出した場合:

  • そのユーザーに対して変数は設定されません。以前のコンテキストステップでこの変数がすでに設定されている場合、ユーザーはその以前の値を保持します。
  • ステップ内の他の変数は引き続き評価・設定されます。
  • 同じステップ内の後続の変数がこの変数を参照している場合、その変数からの新しい値は受け取りません。
  • ユーザーは次のステップに進みます。
  • キャンバスステップの分析では、この変数は「未更新」としてカウントされます。

例えば、以下の変数はフランスのユーザーに対してはtrueに設定され、それ以外のユーザーに対してはスキップされます。

{% if ${country} == "France" %}
  true
{% else %}
  {% abort_message("Not in France") %}
{% endif %}

ユーザーパスをプレビューすると、スキップされた変数は「variable_nameはLiquidロジックが中止をトリガーしたため更新されませんでした」と表示されます。

後続のステップがこの変数に依存している場合、変数が設定されていないユーザーへの対応を計画してください。例えば、オーディエンスパスステップでルーティングすることができます。

Connected Content使用時の送信遅延

バッチ内のすべてのユーザーは、いずれかのユーザーが進む前に処理されます。バッチ処理が完了すると、成功したユーザーは次のステップに進み、失敗したユーザーは個別にリトライされます。成功したユーザーは、リトライが成功するのを待つことなく先に進みます。

リトライの動作

キャンバス内のConnected Content呼び出しは、呼び出しに:retryが含まれている場合にのみリトライされます。

  • コンテキストステップとユーザー更新ステップ: Brazeはステップレベルでのリトライを行います(最大5回)。すべてのリトライが失敗した場合、ユーザーはキャンバスから退出します。
  • メッセージステップ: :retry付きのConnected Contentは引き続きメッセージングパイプラインを使用します。Brazeが最大5回の呼び出しリトライを行う間、受信者は送信キューで待機します。すべてのリトライが失敗した場合、メッセージは中止され、ユーザーは次のステップに進みます。

コンテキストステップとユーザー更新ステップでは、リトライ可能な特定のステップエラー(プロモコードの取得失敗や予期しないステップエラーなど)により、Brazeがユーザーをキャンバスから退出させる前に、指数バックオフ付きの追加のステップレベルリトライ(約13回)がトリガーされることがあります。

:retryタグの詳細については、Connected Contentのリトライを参照してください。

コンテキストステップですべてのユーザーを処理するのにかかる時間は、以下の要因によって異なります。

  • ステップに入るユーザーの数
  • Connected Contentを使用しているかどうか(およびその応答時間)
  • バッチサイズ(デフォルトはバッチあたり1,000ユーザー)

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

タイムゾーンの一貫性

キャンバスコンテキストが有効なワークスペースでは、アクションベースのキャンバスにおけるすべてのデフォルトのタイムスタンプイベントプロパティはUTCで表示されます。この動作は、キャンバスがコンテキストステップを使用しているかどうかに関係なく適用されます。

よくある質問

キャンバスコンテキストはタイムスタンプにどのような影響を与えますか?

キャンバスコンテキストが有効なワークスペースの場合:

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

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

この変更は、キャンバスのステップやメッセージを編集する際に、より予測可能で一貫したエクスペリエンスを実現するための広範な取り組みの一環です。

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

いいえ、影響を受けません。

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

はい、canvas_entry_propertyがアクションベースのキャンバスで使用されており、プロパティの型がtimeの場合、canvas_entry_propertiesに影響します。すべての状況において、タイムスタンプを希望するタイムゾーンで表示するために、Liquidのtime_zoneフィルターを使用することをお勧めします。

以下はその方法の例です:

メッセージステップ内のLiquid 出力 これはLiquidでタイムゾーンを正しく表示する方法ですか?
{{canvas_entry_properties.${timestamp_property}}} 2025-08-05T08:15:30:250-0800 いいえ
{{canvas_entry_properties.${timestamp_property} | date: "%Y-%m-%d %l:%M %p"}} 2025-08-05 4:15pm いいえ
{{canvas_entry_properties.${timestamp_property} | time_zone: "America/Los_Angeles" | date: "%Y-%m-%d %l:%M %p"}} 2025-08-05 8:15am はい

新しいタイムスタンプの動作がメッセージにどのように影響するかの実例は何ですか?

メッセージステップに以下のコンテンツを含むアクションベースのキャンバスがあるとします:

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

これは次のメッセージになります:

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

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

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

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!

これは次のメッセージになります:

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

Liquidでアメリカ/ロサンゼルスのタイムゾーンが指定されているため、ここのタイムスタンプはPSTです。

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

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

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

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

1つのコンテキストステップ内で変数同士を参照できますか?

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

コンテキスト変数 値 説明
favorite_cuisine {{custom_attribute.${Favorite Cuisine}}} ユーザーのお気に入りの料理の種類。
promo_code EATFRESH ユーザーが利用可能な割引コード。
personalized_message "Enjoy a discount of" {{context.${promo_code}}} "on delivery from your favorite" {{context.${favorite_cuisine}}} restaurants!" 前の変数を組み合わせたパーソナライズされたメッセージ。メッセージステップでは、Liquidスニペット{{context.${personalized_message}}}を使用してコンテキスト変数を参照し、各ユーザーにパーソナライズされたメッセージを配信できます。また、コンテキストステップを使用してプロモーションコードの値を保存し、キャンバス全体の他のステップでテンプレートとして使用することもできます。

これは複数のコンテキストステップにわたっても適用されます。例えば、次のシーケンスを想像してください:

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

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

New Stuff!