コンテキスト変数

コンテキスト変数とは、ユーザーが特定のキャンバス内を移動する際に、一時的に作成し使用できるデータのことである。これにより、ユーザーのプロファイル情報を永続的に変更することなく、遅延のパーソナライゼーション、ダイナミックなユーザーのセグメンテーション、メッセージングの充実が可能になる。コンテキスト変数はキャンバス・セッション内にのみ存在し、異なるキャンバス間やセッション外では持続しない。

コンテキスト変数の仕組み

コンテキスト変数は2つの方法で設定できる：

• キャンバスエントリで:ユーザがキャンバスに入ると、イベントまたはAPI トリガのデータが自動的にコンテキスト変数に入力されます。
• コンテキストステップで:コンテキスト・ステップを追加することで、キャンバス内部でコンテキスト変数を手動で定義または更新することができる。

各コンテキスト変数には以下が含まれます。

• 名前 (flight_time やsubscription_renewal_date など)
• データ型（数値、文字列、時刻、配列など）。
• LiquidまたはAdd Personalizationツールを使用して割り当てる値。

定義したコンテキスト変数は、キャンバス全体で {{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値を上書きする。

コンテクスト・ステップごとに最大50KBまで保存でき、最大10変数に分散できる。ステップ内の全変数の合計サイズが50KBを超える場合、制限を超える変数は評価も保存もされない。例えば、コンテキストのステップに3つの変数があるとする：

• 変数1：30 KB
• 変数2：19 KB
• 変数3：2 KB

変数3は、前の変数の合計が50KBを超えるため、評価も保存もされない。

データ型

ステップで作成または更新されるコンテキスト変数には、次のデータ型を割り当てることができます。

データタイプ	変数名の例	値の例
ブール値	loyalty_program	true
数値	credit_score	740
string	product_name	green_tea
配列	favorite_products	["wireless_headphones", "smart_homehub", "fitness_tracker_swatch"]
オブジェクトの配列	pet_details	[_mem_lt_br>_mem_amp_emsp;{ "id": 1, "type": "dog", "breed": "beagle", "name": "Gus" }_mem_lt_br>_mem_amp_emsp;,_mem_lt_br>_mem_amp_emsp;{ "id": 2, "type": "cat", "breed": "calico", "name": "Gerald" }_mem_lt_br>]
時間（UTC）	last_purchase_date	2025-12-25T08:15:30:250-0800
オブジェクト (フラット化)	user_profile	{  "first_name": "{{user.first_name}}",  "last_name": "{{user.last_name}}",  "email": "{{user.email}}",  "loyalty_points": {{user.loyalty_points}},  "preferred_categories": {{user.preferred_categories}} }

デフォルトでは、時刻のデータ型はUTCである。文字列データ型を使って時間値を格納する場合、PSTのような異なるタイムゾーンとして時間を定義することができる。

例えば、ユーザーの誕生日の前日にメッセージを送信する場合、前日送信に関連するLiquidロジックがあるため、コンテキスト変数をtimeデータ型として保存する。しかし、クリスマス（12月25日）にホリデー・メッセージを送るのであれば、ダイナミックな変数として時刻を参照する必要はないだろうから、文字列データ型を使うのが望ましいだろう。

コンテキスト変数を使う

パーソナライゼーションを追加]を選択すると、メッセージや ユーザー更新ステップなど、キャンバスでリキッドを使用する任意の場所でコンテキスト変数を使用できる。

たとえば、次のフライトの前に、VIP ラウンジへのアクセスについて乗客に通知したいとします。このメッセージは、ファーストクラスのチケットを購入した乗客にのみ送信する必要があります。コンテキスト変数は、この情報を追跡する柔軟な方法です。

ユーザーは、飛行機のチケットを購入するときにキャンバスに入ります。ラウンジアクセスの適格性を判断するために、コンテキストステップでlounge_access_grantedというコンテキスト変数を作成し、その後のユーザージャーニーのステップでそのコンテキスト変数を参照します。

このコンテキストステップでは、{{custom_attribute.${purchased_flight}}} を使用して、購入したフライトのタイプがfirst_class かどうかを判断します。

次に、{{context.${lounge_access_granted}}} がtrue であるユーザーをターゲットにするメッセージステップを作成します。このメッセージは、パーソナライズされたラウンジ情報を含むプッシュ通知になる。このコンテキスト変数に基づいて、適格な乗客は、フライト前に関連するメッセージを受け取ります。

• ファーストクラスの乗客は次のメッセージを受け取ります:「Enjoy exclusive VIP lounge access!」
• ビジネスクラスとエコノミークラスの乗客は次のメッセージを受け取ります:「Upgrade your flight for exclusive VIP lounge access.」

アクションパスと終了基準について

これらのトリガーアクションでは、コンテキスト変数またはカスタム属性でプロパティフィルターを比較することができる：[カスタムイベントを実行] または [購入] のいずれかを選択できます。これらのアクショントリガーは、基本プロパティとネストされたプロパティの両方のプロパティフィルターにも対応している。

• 基本プロパティと比較する場合、利用可能な比較はカスタムイベントによって定義されたプロパティのタイプと一致する。例えば、文字列プロパティは、正規表現と完全に一致する。ブール型プロパティは真か偽になる。
• 階層化されたプロパティを比較する場合、型はあらかじめ定義されていないため、階層化されたカスタム属性の比較と同様に、真偽値、数値、文字列、時刻、曜日について、複数のデータ型にまたがる比較を選択することができる。比較時にネストされたプロパティの実際のデータ型と一致しないデータ型を選択した場合、ユーザーはアクションパスまたは終了基準に一致しない。

アクションパスの例

• perform custom event
• make purchase

終了基準の例

• perform custom event
• make purchase

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

オーディエンスパスと 条件分岐ステップで、以前に宣言したコンテキスト変数を使用するフィルターを作成できる。

つまり、セグメンテーションの中で参照することはできない。オーディエンスパスのステップは複数のグループを表し、条件分岐のステップは二値決定を表す。

キャンバスのコンテキスト変数があらかじめ定義された型を持っているのと同様に、コンテキスト変数とスタティック値の比較も、データ型が一致していなければならない。コンテキスト変数フィルターは、階層化されたカスタム属性の比較と同様に、ブーリアン、数値、文字列、時刻、曜日について、複数のデータ型にまたがる比較を可能にする。

以下は、コンテキスト変数product_name を正規表現/braze/ と比較するコンテキスト変数フィルターの例である。

コンテキスト変数やカスタム属性との比較

コンテキスト変数またはカスタム属性と比較するトグルを選択することにより、以前に定義されたコンテキスト変数またはユーザーカスタム属性と比較するコンテキスト変数フィルターを構築することができる。これは、APIトリガー（context ）のようにユーザーごとにダイナミックな比較を実行する場合や、コンテキスト変数にまたがって定義された複雑な比較ロジックを凝縮する場合に便利である。

• example 1
• example 2

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

タイムスタンプ・タイプを使用するほとんどのイベント・プロパティは、キャンバスではすでにUTCになっているが、いくつかの例外がある。キャンバス・コンテキストの追加により、アクションベースのキャンバスにおけるすべてのデフォルト・タイムスタンプ・イベント・プロパティは、一貫してUTCになる。この変更は、キャンバスのステップやメッセージを編集する際に、より予測しやすく一貫性のあるエクスペリエンスを保証するための幅広い取り組みの一環である。この変更は、特定のキャンバスがコンテキスト・ステップを使用しているかどうかにかかわらず、すべてのアクションベースのキャンバスに影響する。

関連記事

• コンテキストステップ
• Liquidによるパーソナライゼーションとダイナミックなコンテンツ