コンテキスト変数
コンテキスト変数は、特定のキャンバスにおけるユーザーのジャーニー内で作成・使用できる一時的なデータです。コンテキスト変数を使用すると、ユーザーのプロファイル情報を恒久的に変更することなく、遅延のパーソナライズ、ユーザーのダイナミックなセグメント化、メッセージングの充実化が可能になります。コンテキスト変数はキャンバスセッション内にのみ存在し、異なるキャンバス間やセッション外では保持されません。
コンテキスト変数の仕組み
コンテキスト変数は2つの方法で設定できます。
- キャンバスエントリ時: ユーザーがキャンバスに入ると、イベントまたはAPIトリガーからのデータがコンテキスト変数に自動的に入力されます。
- コンテキストステップ内: コンテキストステップを追加することで、キャンバス内でコンテキスト変数を手動で定義または更新できます。
各コンテキスト変数には以下が含まれます。
- 名前（
flight_timeやsubscription_renewal_dateなど） - データ型（数値、文字列、時刻、配列など）
- Liquid またはパーソナライゼーションを追加ツールを使用して割り当てる値
定義すると、次の形式で参照することでキャンバス全体でコンテキスト変数を使用できます: {{context.${example_variable_name}}}
たとえば、{{context.${flight_time}}} はユーザーのスケジュールされたフライト時刻を返すことができます。
ユーザーがキャンバスに入るたびに（以前に入ったことがある場合でも）、コンテキスト変数は最新のエントリデータとキャンバスの設定に基づいて再定義されます。このステートフルなアプローチにより、各キャンバスエントリが独自の独立したコンテキストを維持できるため、ユーザーは同じジャーニー内で複数のアクティブな状態を持ちながら、各状態に固有のコンテキストを保持できます。
たとえば、顧客が2つの予定フライトを持っている場合、2つの別々のジャーニー状態が同時に実行され、それぞれが出発時刻や目的地などのフライト固有のコンテキスト変数を持ちます。これにより、午後2時のニューヨーク行きフライトについてパーソナライズされたリマインダーを送信しながら、翌日の午前8時のロサンゼルス行きフライトについては別の更新を送信でき、各メッセージがそれぞれの予約に関連した内容を維持できます。
考慮事項
コンテキストステップごとに最大10個のコンテキスト変数を定義できます。各変数名は最大100文字で、文字、数字、またはアンダースコアのみを使用する必要があります。
コンテキスト変数の定義は最大10,240文字です。APIトリガーのキャンバスにコンテキスト変数を渡す場合、それらはコンテキストステップで作成された変数と同じ名前空間を共有します。たとえば、/canvas/trigger/sendエンドポイントのコンテキストオブジェクトで変数purchased_itemを送信した場合、{{context.${purchased_item}}}として参照できます。コンテキストステップでその変数を再定義すると、新しい値がそのユーザーのジャーニーにおけるAPI値を上書きします。
コンテキストステップごとに最大50 KBを保存でき、最大10個の変数に分散されます。ステップ内のすべての変数の合計サイズが50 KBを超えた場合、制限を超える変数は評価も保存もされません。たとえば、コンテキストステップに3つの変数がある場合：
- 変数1：30 KB
- 変数2：19 KB
- 変数3：2 KB
前の変数の合計が50 KBを超えるため、変数3は評価も保存もされません。
データ型
ステップで作成または更新されるコンテキスト変数には、以下のデータ型を割り当てることができます。
コンテキスト変数は、イベントプロパティと同じデータ型の期待される形式を持ちます。
配列型を使用する場合、Brazeは値をJSONとして解析しようとするため、オブジェクトの配列を正常に作成できます。配列内のオブジェクトが有効なJSONでない場合、結果は単純な文字列の配列になります。
ネストされたオブジェクトやオブジェクトの配列には、as_json_string Liquidフィルターを使用してください。コンテキストステップで同じオブジェクトを作成する場合は、as_json_stringを使用してオブジェクトをレンダリングする必要があります。例: {{context.${object_array} | as_json_string }}
| データ型 | 変数名の例 | 値の例 |
|---|---|---|
| Boolean | loyalty_program | true |
| Number | credit_score | 740 |
| String | product_name | green_tea |
| Array | favorite_products | ["wireless_headphones", "smart_homehub", "fitness_tracker_swatch"] |
| Array (of objects) | pet_details | [ |
| Time (in UTC) | last_purchase_date | 2025-12-25T08:15:30:250-0800 |
| Object (flattened) | user_profile | { |
デフォルトでは、時刻データ型はUTCです。文字列データ型を使用して時刻の値を格納する場合は、PSTなどの別のタイムゾーンとして時刻を定義できます。
たとえば、ユーザーの誕生日の前日にメッセージを送信する場合、送信日の前日に関連するLiquidロジックがあるため、コンテキスト変数を時刻データ型として保存します。ただし、クリスマス（12月25日）にホリデーメッセージを送信する場合は、時刻をダイナミックな変数として参照する必要がないため、文字列データ型を使用する方が適しています。
オブジェクトデータ型の場合、ドット表記を使用してデータ内のパスを指定できます。たとえば、コンテキストステップでコンテキスト変数order_summaryを以下の構造で定義した場合:
{
"shipping": {
"carrier": "overnight"
}
}
オーディエンスパスまたは条件分岐フィルターで、ドット表記を使用してコンテキスト変数名としてパスを入力します（例: order_summary.shipping.carrier）。フィルターが評価されると、Brazeはそのパスを値overnightに解決します。
Liquid（メッセージステップなど）では、代わりに{{context.${order_summary}.shipping.carrier}}を使用してください。
コンテキスト変数の使用
コンテキスト変数は、キャンバスで Liquid を使用するあらゆる場所で使用できます。例えば、メッセージステップやユーザー更新ステップでパーソナライゼーションを追加を選択して使用できます。メッセージステップのアプリ内メッセージやバナーでは、コンテキスト変数を選択してメッセージの有効期限を決定できます。
例えば、今後のフライトに先立ち、VIPラウンジへのアクセスについて乗客に通知したいとします。このメッセージは、ファーストクラスのチケットを購入した乗客にのみ送信する必要があります。コンテキスト変数は、この情報を追跡する柔軟な方法です。
ユーザーは航空券を購入したときにキャンバスにエントリします。ラウンジアクセスの資格を判定するために、コンテキストステップで lounge_access_granted というコンテキスト変数を作成し、ユーザージャーニーの後続のステップでそのコンテキスト変数を参照します。
このコンテキストステップでは、{{custom_attribute.${purchased_flight}}} を使用して、購入したフライトの種類が first_class であるかどうかを判定します。
次に、{{context.${lounge_access_granted}}} が true であるユーザーをターゲットにするメッセージステップを作成します。このメッセージは、パーソナライズされたラウンジ情報を含むプッシュ通知になります。このコンテキスト変数に基づいて、資格のある乗客はフライト前に関連するメッセージを受け取ります。
- ファーストクラスの乗客は次のメッセージを受け取ります：「限定VIPラウンジアクセスをお楽しみください！」
- ビジネスクラスとエコノミークラスの乗客は次のメッセージを受け取ります：「フライトをアップグレードして、限定VIPラウンジアクセスをご利用ください。」
アクションパスと終了条件の場合
以下のトリガーアクションで、プロパティフィルターをコンテキスト変数またはカスタム属性と比較できます：カスタムイベントを実行および購入する。これらのアクショントリガーは、基本プロパティとネストされたプロパティの両方のプロパティフィルターもサポートしています。
- 基本プロパティと比較する場合、使用可能な比較はカスタムイベントで定義されたプロパティの型に一致します。例えば、文字列プロパティには完全一致や正規表現一致があります。ブールプロパティは true または false になります。
- ネストされたプロパティと比較する場合、型は事前定義されていないため、階層化カスタム属性の比較と同様に、ブール値、数値、文字列、時間、年の日付にわたる複数のデータ型の比較を選択できます。比較時にネストされたプロパティの実際のデータ型と一致しないデータ型を選択した場合、ユーザーはアクションパスステップまたは終了条件に一致しません。
アクションパスの例
カスタム属性の比較では、アクションが実行された時点でのカスタム属性の値を使用します。つまり、比較時にユーザーがこのカスタム属性を設定していない場合、またはカスタム属性の値が定義されたプロパティ比較に一致しない場合、ユーザーはアクショングループに一致しません。これは、ユーザーがアクションパスステップにエントリした時点では一致していたとしても同様です。
以下のアクションパスステップは、基本プロパティ source を持つカスタムイベント Account_Created を実行したユーザーを、コンテキスト変数 app_source_variable に基づいて分類するように設定されています。
以下のアクションパスステップは、特定の商品名 shoes の基本プロパティ brand をコンテキスト変数 promoted_shoe_brand に一致させるように設定されています。
終了条件の例
終了条件は、キャンバス内のユーザージャーニーの任意の時点で、以下の場合にユーザーがキャンバスから退出することを示しています：
- カスタムイベント Abandon Cart を実行し、かつ
- 基本プロパティ Item in Cart がコンテキスト変数
cart_item_thresholdの文字列値に一致する場合。
終了条件は、キャンバス内のユーザージャーニーの任意の時点で、以下の場合にユーザーがキャンバスから退出することを示しています：
- 商品名「book」の特定の購入を行い、かつ
- その購入のネストされたプロパティ「loyalty_program」がユーザーのカスタム属性「VIP」と等しい場合。
有効期限の設定
キャンバスのメッセージステップにおけるバナーとアプリ内メッセージでは、有効期限としてステップが利用可能になってからの期間を選択し、期間をパーソナライズをオンにすることで、コンテキスト変数から利用可能期間を制御できます。例えば、コンテキストステップのプロモーションや予約の期間に合わせることができます。
期間をパーソナライズは、その期間ベースの有効期限オプションに適用されます。代わりに特定の日時を選択した場合は、日時コントロールを使用して有効期限を設定します。
アクションパスの遅延
アクションパスステップの評価ウィンドウで、遅延をパーソナライズをオンにすると、コンテキスト変数からユーザーがステップに保持される期間を設定できます。ティアやリージョンなどの詳細に基づいて、ユーザーごとに待機期間を異なるものにしたい場合に使用します。
コンテキスト変数フィルター
オーディエンスパスステップや条件分岐ステップで、以前に宣言したコンテキスト変数を使用するフィルターを作成できます。
コンテキスト変数フィルターは、オーディエンスパスステップと条件分岐ステップでのみ使用できます。
コンテキスト変数はキャンバスのスコープ内でのみ宣言およびアクセスでき、セグメントでは参照できません。コンテキスト変数フィルターは、オーディエンスパスステップと条件分岐ステップで同様に機能します。オーディエンスパスステップは複数のグループを表し、条件分岐ステップはバイナリの判定を表します。
キャンバスのコンテキスト変数には事前定義された型があるのと同様に、コンテキスト変数と静的値の比較には一致するデータ型が必要です。コンテキスト変数フィルターは、階層化カスタム属性の比較と同様に、ブール値、数値、文字列、時間、年の日付にわたる複数のデータ型の比較を許可します。
以下は、コンテキスト変数 product_name を正規表現 /braze/ と比較するコンテキスト変数フィルターの例です。
日付コンテキスト変数の「年の日付」フィルターと「時間」フィルター
コンテキスト変数で年の日付または時間の比較フィルターを使用するには：
- カレンダーの日付（例：2025年10月23日）にコンテキスト変数を設定するコンテキストステップを追加します。
- コンテキストステップの後にオーディエンスパスステップを追加します。
- オーディエンスパスステップで、そのコンテキスト変数に基づいてユーザーを分割するフィルターを追加します。
- 年の日付または時間カテゴリから比較を選択します。
コンテキスト変数に宣言された型がない場合、Brazeはドロップダウンに年の日付と時間を含むすべての利用可能な比較型を表示します。変数がコンテキストステップで時間型として宣言されている場合は、年の日付と時間の比較のみが表示されます。既知の型を持つその他のデータ型（例：時間型の階層化カスタム属性）の場合は、その型に適用される比較のみが表示されます。
コンテキスト変数と比較には同じデータ型を使用してください。例えば、コンテキスト変数が時間データ型の場合は、時間の比較（「より前」や「より後」など）を使用します。一致しないデータ型の使用（時間コンテキスト変数に文字列比較を使用するなど）は、予期しない動作を引き起こす可能性があります。
「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日あることを考慮しないため、誤った一致が生じる可能性があります。
コンテキスト変数またはカスタム属性との比較
コンテキスト変数またはカスタム属性と比較トグルを選択すると、以前に定義されたコンテキスト変数やユーザーのカスタム属性と比較するコンテキスト変数フィルターを構築できます。これは、APIトリガーの context のようなユーザーごとにダイナミックな比較を実行する場合や、コンテキスト変数にわたって定義された複雑な比較ロジックを集約する場合に便利です。
ダイナミックな非アクティブ期間の後にユーザーにパーソナライズされたリマインダーを送信したいとします。過去3日間にアプリにログインしていないユーザーにメッセージを送信する必要があります。
コンテキスト変数 re_engagement_date は {{now | minus: 3 | append: ' days'}} として定義されています。3 days はユーザーのカスタム属性として保存される可変量でもあることに注意してください。したがって、re_engagement_date が last_login_date（ユーザープロファイルにカスタム属性として保存されている）より後の場合、メッセージが送信されます。
以下のフィルターは、コンテキスト変数 reminder_date がコンテキスト変数 appointment_deadline より前であることを比較します。これにより、オーディエンスパスステップでユーザーをグループ化し、予約期限前に追加のリマインダーを受け取るべきかどうかを判定できます。
タイムゾーンの一貫性の標準化
キャンバスでは、タイムスタンプ型を使用するほとんどのイベントプロパティはすでにUTCですが、一部例外があります。キャンバスコンテキストの追加により、アクションベースのキャンバスにおけるすべてのデフォルトのタイムスタンプイベントプロパティが一貫してUTCになります。この変更は、キャンバスのステップやメッセージを編集する際に、より予測可能で一貫性のある体験を確保するための広範な取り組みの一環です。この変更は、特定のキャンバスがコンテキストステップを使用しているかどうかに関係なく、すべてのアクションベースのキャンバスに影響することにご注意ください。
すべての状況において、タイムスタンプを目的のタイムゾーンで表示するために、Liquidのtime_zoneフィルターを使用することを強くお勧めします。例については、コンテキストステップの記事にあるよくある質問を参照してください。