コンテキスト

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

仕組み

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

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

ヒント

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

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

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

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

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

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

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

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

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

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

• 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: 変数を定義する

注

各コンテキストステップにつき、最大10個のコンテキスト変数を定義できます。

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

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

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

重要

コンテキスト変数を参照する際は、必ず{{context.${variable_name}}}の形式を使用してください。

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

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

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

エージェントがオブジェクトを返し、ネストされたプロパティでフィルタリングしたい場合は、トップレベルの変数名だけでなく、Context variable nameフィールドにドット記法でパスを入力します（例えば、personaがintent_agentの下にネストされている場合はintent_agent.persona）。

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

重要

「Day of year」と「Time」のフィルタータイプの選択について：日付を含むコンテキスト変数をフィルタリングする際は、その日付が毎年繰り返されるかどうかに基づいて、適切な比較タイプを選択してください。コンテキスト変数が生成する値に年が含まれていない場合にのみ、「Day of year」を使用してください。

• 毎年繰り返される日付（誕生日、記念日、クリスマスなどの祝日など）には「Day of year」を使用してください。この比較タイプは、年の要素を無視し、その年の日数（1〜365/366）に基づいて計算します。
• 繰り返されない絶対日付（契約終了日、予約日、購読の更新日など）には「Time」を使用してください。この比較タイプは、年を含む完全なタイムスタンプに基づいて計算します。

絶対日付に「Day of year」を使用すると、計算が年の要素を無視するため、誤った結果や予期しない結果が生じることがあります。例えば、4月の将来の契約終了日が63日以内かどうかを判断する場合、「Day of year」を使用すると、日付番号（119対359）のみを比較し、実際には4月まで188日あることを考慮しないため、誤った一致が生じる可能性があります。

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

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

注

エディターのプレビューとテスト送信セクションでキャンバスをプレビューしている場合、テストメッセージプレビューのタイムスタンプはUTCに標準化されません。これは、このパネルがプレビューを文字列として生成するためです。つまり、キャンバスがtimeオブジェクトを受け入れるように設定されている場合、メッセージプレビューはキャンバスがライブのときに発生する内容を正確にプレビューしません。キャンバスを最も正確にテストするには、代わりにユーザーパスをプレビューすることをお勧めします。

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

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

Connected Contentの文字列をJSONに変換する

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

1
2

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

トラブルシューティング

無効なコンテキスト変数

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

• 埋め込まれたConnected Contentの呼び出しが失敗した場合。
• ランタイム時にLiquid式がデータ型と一致しない値を返すか、空（null）の値を返した場合。

たとえば、コンテキスト変数のデータ型がNumberであるにもかかわらず、Liquid式が文字列を返した場合、無効と見なされます。

このような場合：

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

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

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

Connected Contentを使用した送信の遅延

バッチ内のすべてのユーザーが処理されてから、ユーザーが次に進みます。バッチ処理が完了すると、成功したユーザーは次のステップに移動し、失敗したユーザーは別途リトライされます。成功したユーザーは、リトライが成功するのを待たずに先に進みます。

リトライの動作

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

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

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

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

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

• ステップに入るユーザー数
• Connected Contentが使用されているかどうか（およびそのレスポンス時間）
• バッチサイズ（デフォルトはバッチあたり1,000ユーザー）

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

タイムゾーンの一貫性標準化

キャンバスコンテキストが一般提供されたことに伴い、アクションベースのキャンバスにおけるすべてのデフォルトのタイムスタンプイベントプロパティはUTCで表されます。この変更は、キャンバスのステップやメッセージを編集する際に、より予測可能で一貫した体験を確保するための取り組みの一環です。この変更は、特定のキャンバスがコンテキストステップを使用しているかどうかに関係なく、すべてのアクションベースのキャンバスに影響することにご注意ください。

重要

すべての状況において、タイムスタンプを目的のタイムゾーンで表示するために、Liquid time_zone フィルターの使用を強くお勧めします。例については、こちらのよくある質問を参照してください。

よくある質問

キャンバスコンテキストが一般公開されてから何が変わりましたか？

キャンバスコンテキストが一般公開されたことにより、以下の内容が適用されます。

• アクションベースのキャンバスにおけるトリガーイベントプロパティの日時型を持つすべてのタイムスタンプは、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:15 PM, 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:15 AM, 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"
}

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

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

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

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

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

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

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